From warren@kumari.net Tue May 1 14:03:31 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACDA621E80F6; Tue, 1 May 2012 14:03:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw2solkldeGz; Tue, 1 May 2012 14:03:31 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 3A43B21E8053; Tue, 1 May 2012 14:03:31 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 7CFCF1B40098; Tue, 1 May 2012 17:03:30 -0400 (EDT) From: Warren Kumari Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 1 May 2012 17:03:28 -0400 Message-Id: To: draft-ietf-appsawg-about-uri-scheme.all@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Cc: IESG IESG , secdir@ietf.org Subject: [secdir] SecDir review of draft-ietf-appsawg-about-uri-scheme X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 21:03:31 -0000 Hi, Do not be alarmed... I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document codifies an existing mechanism, used by lots of browsers. = It creates a registry for specific about: tokens, where the = only (currently) defined token is "blank", which, surprisingly enough, = brings up a blank page... The "Security Considerations" section exists, and is well written. It = punts much of the security to the application -- IMO this is the correct = thing to do in this case. W= From kathleen.moriarty@emc.com Thu May 3 09:06:10 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E19121F85D3; Thu, 3 May 2012 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.559 X-Spam-Level: X-Spam-Status: No, score=-10.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rTYmfl41f7Th; Thu, 3 May 2012 09:06:08 -0700 (PDT) Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id 30EAB21F85D2; Thu, 3 May 2012 09:06:02 -0700 (PDT) Received: from hop04-l1d11-si01.isus.emc.com (HOP04-L1D11-SI01.isus.emc.com [10.254.111.54]) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q43G5vXe002498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 May 2012 12:05:58 -0400 Received: from mailhub.lss.emc.com (mailhub.lss.emc.com [10.254.222.130]) by hop04-l1d11-si01.isus.emc.com (RSA Interceptor); Thu, 3 May 2012 12:05:33 -0400 Received: from mxhub23.corp.emc.com (mxhub23.corp.emc.com [128.222.70.135]) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q43G5W6u018724; Thu, 3 May 2012 12:05:32 -0400 Received: from mx06a.corp.emc.com ([169.254.1.106]) by mxhub23.corp.emc.com ([128.222.70.135]) with mapi; Thu, 3 May 2012 12:05:32 -0400 From: To: , Date: Thu, 3 May 2012 12:05:31 -0400 Thread-Topic: Sec-dir review of draft-ietf-ledbat-congestion-09 Thread-Index: Ac0pRpBgKWUTU3/eScy/0moIJll/7Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EMM-MHVC: 1 Cc: jiyengar@fandm.edu, mirja.kuehlewind@ikr.uni-stuttgart.de, greg@bittorrent.com, shalunov@bittorrent.com Subject: [secdir] Sec-dir review of draft-ietf-ledbat-congestion-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 16:06:10 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. Security risks should be minimized since it is designed to back off to stan= dard TCP behavior in congestion situations. It can be used in transport or= in applications by design. The Security considerations section says it re= lies on 'authenticating' time stamps, so the security relies upon the appli= cation or protocol at the higher level to have a method to do this. The draft is written more like a whitepaper than a typical RFC, so it made = it tough to follow the flow of the algorithm. NITS: Section 2, 3rd line in second paragraph: typo Change from: avoidoing To: avoiding Section 2.1: the section ends with a ',' at the end of #3 Thanks, Kathleen From weiler+secdir@watson.org Fri May 4 08:51:37 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E35E21F8622 for ; Fri, 4 May 2012 08:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF-5B9pLVj-P for ; Fri, 4 May 2012 08:51:34 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id C05B521F8624 for ; Fri, 4 May 2012 08:51:32 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q44FpVZ5047782 for ; Fri, 4 May 2012 11:51:31 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q44FpVQa047777 for ; Fri, 4 May 2012 11:51:31 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 4 May 2012 11:51:30 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 04 May 2012 11:51:31 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:51:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Tim Polk is next in the rotation. For telechat 2012-05-10 Reviewer LC end Draft Jeffrey Hutzelman T 2012-03-21 draft-betts-itu-oam-ach-code-point-04 Stephen Kent T 2012-05-07 draft-ietf-appsawg-mime-default-charset-03 Sandy Murphy T - draft-ietf-avtext-splicing-for-rtp-07 Carl Wallace T - draft-ietf-roll-minrank-hysteresis-of-10 For telechat 2012-05-24 Radia Perlman TR2012-03-21 draft-ietf-pwe3-redundancy-08 Last calls and special requests: Alan DeKok 2012-04-17 draft-claise-export-application-info-in-ipfix-06 Jeffrey Hutzelman 2012-04-16 draft-ietf-manet-nhdp-mib-12 Matt Lepinski 2012-05-02 draft-ietf-mboned-64-multicast-address-format-01 Russ Mundy 2012-05-09 draft-ietf-netext-access-network-option-10 Yoav Nir 2012-05-14 draft-ietf-ccamp-assoc-info-03 Magnus Nystrom 2012-05-10 draft-ietf-codec-opus-12 Hilarie Orman 2012-05-28 draft-polk-ipr-disclosure-03 Radia Perlman 2012-05-31 draft-levine-application-gzip-02 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-07 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From vincent.roca@inria.fr Fri May 4 15:34:54 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 580AC21E8015; Fri, 4 May 2012 15:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.96 X-Spam-Level: X-Spam-Status: No, score=-109.96 tagged_above=-999 required=5 tests=[AWL=0.245, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSMjeMRVfb38; Fri, 4 May 2012 15:34:53 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id AFF2B21E8012; Fri, 4 May 2012 15:34:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,533,1330902000"; d="scan'208";a="156826646" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.0.11]) ([82.236.155.50]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 05 May 2012 00:34:50 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <4F8BF405.5030708@ericsson.com> Date: Fri, 4 May 2012 20:45:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <535AB069-720A-4F0F-8E7A-3DFD6EBDBC1A@inria.fr> References: <51DE5E2E-1D51-4025-B55C-4B09EFA62468@inria.fr> <4F8BF405.5030708@ericsson.com> To: Miguel A. Garcia X-Mailer: Apple Mail (2.1084) Cc: "draft-ietf-simple-chat.all@tools.ietf.org" , IESG IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-simple-chat-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:34:54 -0000 Hello Miguel, Sorry for the delay in answering your email. Otherwise I've replied = below and removed items where we agree. >> General: >>=20 >> The authors, in section 11, discuss several simple security issues. >> However I have the feeling that there aren't enough details on how to >> avoid/mitigate them. Additionally, I'm not sure the section provides = a >> comprehensive analysis of security aspects. What about intelligent, >> more elaborate attacks? >>=20 >>=20 >> Details for section 11 "Security considerations" >> --------------------------------------------------------------- >>=20 >> ** The second paragraph explains several situations where a message = can >> be sent to several recipients without the sender knowing. It's a good >> point to identify this problem, but I'd like to know how it can be >> avoided (if possible). >=20 > Effort was made to lower the barrier of endpoints, so that = conference-unaware participants were able to join and still have some = basic chat functionality. If possible, we would like to keep this = feature. >=20 > I see a couple of immediate possible solutions: >=20 > 1) We forbid conference-unaware participants to join the chat room, = for example, by accepting the session to a virtual chat room where the = only participants is the MSRP switch itself, which sends a message = indicating that the client does not support the required features, and = disconnects it. This forbids conference-unaware participants joining the = chat room, and it is not desirable. >=20 > 2) We force the MSRP switch to send one or more messages to = conference-unaware participants, indicating that this is a chat room, = their client does not support all the features, we send the roster as = text, and indicate that all messages will be further distributed to the = whole chat room. Basically, we tell the user (and not its software) that = this is a chat room. >=20 > If 2 is acceptable, I will go for it. I think that 2) is fine, but I'm not an expert, I don't understand the = protocol, and I don't want you to introduce new features at this stage of the process if there = are risks of breaking anything. My comment was an open one. >> ** It is said: >> "It's up to the policy of the MSRP >> switch if the messages are forwarded to the other participant's in >> the chat room using TLS [RFC5246] transport." >>=20 >> I'm surprised to see that a participant has no way to enforce a = secure >> end-to-end connection. At a minimum, can the participant know the >> situation in order to take a decision? >=20 > A participant can control if TLS is used between his endpoint and the = MSRP switch. But this participant cannot control if the MSRP switch uses = TLS to deliver messages to the rest of the participant. This is because = each pair of endpoint-MSRPswitch session is independent of each other, = so, it is possible for the chat room to have a mixture of secure and = non-secure MSRP session. >=20 > It is possible for an MSRP switch to have a local policy enforcing = that TLS will be required for sending/receiving MSRP messages. Since = this does not affect interoperability, we haven't mentioned anything, = but if you guys feel more comfortable indicating this fact, we can = always add a paragraph. So it seems to be a intrinsic limitation that directly derives from this = endpoint-MSRP independency. You can probably explain this in the section. I can = understand that a protocol has limitations derived for design choices. Otherwise your proposal is fine in the sense it can help in some = situations where this policy is acceptable. >> ** It is said: >> "To avoid takeovers the MSRP switch MUST make sure that a nickname = is >> unique inside a chat room." >>=20 >> Do you mean the protocol does not guaranty by design that a nickname = is >> unique at some point of time in a chat room? If this is the case it's >> clearly a flaw that should be addressed within the protocol = description, >> not in the security considerations section. >=20 >=20 > Yes, the selection of a nickname guaranties that a nickname is unique = in the chat room. This is described in Section 7.1: >=20 > The reservation of a nickname can also fail if the value of the > Use-Nickname header field of the NICKNAME request is a reserved word > (not to be used as a nickname by any user) or that particular value > is already in use by another user. In this case the MSRP switch = MUST > answer the NICKNAME request with a 425 response code. >=20 > That paragraph you quoted is just implicitly referring to the = paragraph that I just quoted. Okay. I suggest you add a reference to section 7.1 in that case. >> Another remark: it's not sufficient to guaranty the uniqueness of the >> nickname. Phishing attacks show us that two close URLs can mislead a >> user, even if the URLs differ by at least one character. It would be >> wiser to recommend that nicknames be significantly different (the = MSRP >> can probably check the distance between a proposed nickname and those >> already registered in the chat session). >=20 > We can add such paragraph. However, there has been some e-mail = discussion on the topic, in conjunction with the internationalization of = characters in nicknames. I will point you to a couple of interesting = e-mails. >=20 > Peter Saint-Andre mention here that avoiding confusable nicknames = should be optional: > http://www.ietf.org/mail-archive/web/simple/current/msg09894.html >=20 > And in this other e-mail, Peter indicates the confusion that different = (but still similar) characters can create > http://www.ietf.org/mail-archive/web/simple/current/msg09887.html >=20 > I believe it is hard, if not impossible, to fight the latter. So I suggest a small sentence summarizing this to remind implementers that there is still a risk, even if nicknames are different. >> ** General: >> Several threats are missing in this document. In particular, >> what about attacks where some traffic is intercepted and modified >> on-the-fly by the attacker? >=20 > If TLS is used for delivering MSRP messages, then this attack should = not be possible. Yes but it's perhaps worth mentioning it (it was the goal of my = comment). >> What about faked messages sent by an >> attacker to the MSRP? >=20 > TLS will also prevent this attack. If TLS is used to transport MSRP = messages, then an attacker could not impersonate a participant and = inject false messages. Same answer.=20 >> Can a participant use some integrity service? >> This is not discussed. >=20 > Here the solution should either be TLS or S/MIME. >=20 > For all the threats, remember that this draft builds on MSRP. = Therefore, the security considerations of RFC 4975 apply. TLS and S/MIME = is discussed in there, and they apply to this draft. I must confess I haven't looked at RFC4975. So, if this is discussed = there, it's just sufficient to refer to the RFC. >> I'd like to see guidelines on how a participant or MSRP administrator >> can define a secure mode of operation. If not possible, I'd like to >> see a detailed discussion of existing risks. >=20 > Can you please elaborate what else on top of RFC 4975 we need to = discuss? Are you referring to indicating that it is RECOMMENDED that the = MSRP switch only accepts TLS-protected MSRP sessions or is it something = else? No, see just above. Cheers, Vincent From jhutz@cmu.edu Fri May 4 16:51:32 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E9521F84B9 for ; Fri, 4 May 2012 16:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3o9uHoiK1sE for ; Fri, 4 May 2012 16:51:31 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB8521F849D for ; Fri, 4 May 2012 16:51:31 -0700 (PDT) Received: from [192.168.202.155] (pool-98-111-232-78.pitbpa.fios.verizon.net [98.111.232.78]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q44NpR4T012201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 May 2012 19:51:27 -0400 (EDT) From: Jeffrey Hutzelman To: secdir-secretary@mit.edu In-Reply-To: <32642_1336146700_q44Fpdl3006563_alpine.BSF.2.00.1205041148580.65556@fledge.watson.org> References: <32642_1336146700_q44Fpdl3006563_alpine.BSF.2.00.1205041148580.65556@fledge.watson.org> Content-Type: text/plain; charset="UTF-8" Date: Fri, 04 May 2012 19:51:27 -0400 Message-ID: <1336175487.3244.101.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: secdir@ietf.org, jhutz@cmu.edu Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 23:51:32 -0000 On Fri, 2012-05-04 at 11:51 -0400, Samuel Weiler wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > Tim Polk is next in the rotation. > > For telechat 2012-05-10 > > Reviewer LC end Draft > Jeffrey Hutzelman T 2012-03-21 draft-betts-itu-oam-ach-code-point-04 I'm not sending this to all the usual places, because I don't think it's necessary in this case and to keep the effort level low enough that I can do it right now. This document requests IANA assignment of a code point in a space whose allocation policy is "IETF Review", for use by an external IEEE specification. It specifies no protocol or operational practice, and so introduces no security considerations. However, it does reiterate the requirement that such considerations be included in the actual protocol specification and reminds the IEEE to do so. I don't see anything here to get excited about. -- Jeff From new-work-bounces@ietf.org Tue May 1 09:36:23 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D055F21E830E; Tue, 1 May 2012 09:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1335890183; bh=gZ8BfzbwJ8dcjjGgYOk7xOuo5S5SddkBZcCm0llQ+h8=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=ui8pJhCVA1WmupCsvoxO2iMjSxa6YQuQjG2d6BN8OMKyxfcTmbgOteLXVlooL+dqk tODPe5RHh+dHZtraEyoRknX27rnSYxC/VuEuCdB8H9kDM+nC5DUKTat6C2WyQjzU8t y/PnDYL+HnhhLvPiXK9CDpX/Bf899QbF8qe41iD4= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9521E8303; Tue, 1 May 2012 09:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDN6ALEZ4afW; Tue, 1 May 2012 09:36:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BDB21E82CC; Tue, 1 May 2012 09:36:21 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120501163621.10324.98511.idtracker@ietfa.amsl.com> Date: Tue, 01 May 2012 09:36:21 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Mon, 07 May 2012 08:20:32 -0700 Subject: [secdir] [new-work] WG Review: Web Extensible Internet Registration Data Service (weirds) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:36:24 -0000 A new IETF working group has been proposed in the Applications Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 8, 2012. Web Extensible Internet Registration Data Service (weirds) ---------------------------------------------------------- Status: Proposed Working Group Last updated: 2012-04-24 Chairs: TBD Applications Area Directors: Barry Leiba Pete Resnick Mailing List: Address: weirds@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/weirds Archive: http://www.ietf.org/mail-archive/web/weirds/ Description of Working Group: Internet registries for both number resources and names have historically maintained a lookup service to permit public access to some portion of the registry database. Most registries offer the service via WHOIS (RFC 3912), with additional services being offered via world wide web pages, bulk downloads, and other services, such as RPSL (RFC 2622). WHOIS has never been internationalized. In the absence of formal specification, ad hoc solutions to signal internationalized registration data have been adopted and deployed. Providing a standards-based solution that scales well could minimize further proliferation of ad hoc solutions. WHOIS also has no data model: replies are basically just free-form text. This means that processing of WHOIS output amounts to "screen scraping", with specialized handlers for every service. While many of the domain name registries share a basic common output format, the addition of data elements changes the output and causes problems for parsers of the data. The WHOIS protocol does not offer any differential service; it cannot differentiate among clients to offer different subsets of information or to allow different access rates to it. Various attempts to solve the limitations of WHOIS have met with mixed success. The most recent of these was IRIS (RFC 3891). IRIS has not been a successful replacement for WHOIS. The primary technical reason for this appears to be the complexity of IRIS, the fact that it builds upon many available technologies that in the aggregate form a complex system. There may also exist non-technical reasons, but they lie in areas upon which the IETF does not pass judgement. In recent years, ARIN and RIPE NCC have fielded production RESTful web services to serve WHOIS data, and each has met with success. It is widely believed that this simpler re-use of Web technologies familiar to modern web developers has enabled this success. The purpose of this working group is to broaden the use of RESTful web services by achieving simple and common URI patterns and responses amenable to all number resource and domain name registries. This Working Group shall determine the general needs of such a service, and standardize a single data framework. That framework shall be used to encapsulate objects that could form part of an answer. The framework shall be for data to be delivered via a RESTful data service using HTTP (optionally using TLS), and may use standard features of HTTP to support differential service levels to different classes of user. The data shall have one mandatory format, though the working group may consider other optional formats. The overall effort will be broadly aligned with a subset of the Cross Registry Internet Service Protocol (CRISP) Requirements (RFC 3707), but with the explicit additional goals of producing a simple, easy-to-implement protocol, supporting internationalized registration data and, specifically for name registries, capturing the needs of internationalized domain names in the data model. As the number registries have more experience with these services and have found common ground, with their dissimilarities resulting in more complete working group input documents, the goals of the working group are to produce standards-track specifications for both number and name registries using the fashion and pattern of the number registry input documents, draft-newton-et-al-weirds-rir-query and draft-newton-et-al-weirds-rir-json-response, as an initial basis. Work to specify the query for domain name registration data will be based on draft-sheng-weirds-icann-rws-dnrd. The Working Group shall determine the general requirements of such a service, using draft-kucherawy-weirds-requirements as an input document, and standardize a single data framework. The working group will likely not seek publication of this draft. Should the Working Group reach a point where it determines that the problem of producing a grand unified specification for both numbers and names appears to be intractable, it will be permitted to divide the problem into separate tasks and amend its milestones accordingly. Milestones: Nov 2012 Draft specifying the common infrastructure document to the IESG for approval as a Proposed Standard. Feb 2013 Draft specifying the RESTful URL query format for RIRs to the IESG for approval as a Proposed Standard. Mar 2013 Draft specifying the format for responses to RIR queries to the IESG for approval as a Proposed Standard. Jul 2013 Draft specifying the RESTful URL query format for domain name registration data to the IESG for approval as a Proposed Standard. Aug 2013 Draft(s) specifying the format(s) for responses to domain name registration data queries to the IESG for approval as a Proposed Standard. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From radiaperlman@gmail.com Thu May 10 21:01:39 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8CAD21F84BF; Thu, 10 May 2012 21:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uhC2VaQG6KiN; Thu, 10 May 2012 21:01:39 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id E7A8721F84B6; Thu, 10 May 2012 21:01:38 -0700 (PDT) Received: by eekd4 with SMTP id d4so885643eek.31 for ; Thu, 10 May 2012 21:01:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QGrsrnlwJm2PjJR3t6Qh8JhBQ9f0cy3GBigr3xQPM0w=; b=tHxRKT7zdNEjlIehFOQQAIQmEBcs9nrUjnrceH9nfUqghvJmJi3xx+fX5M1AD3Jzco vfnd6KrMMcOef26JxJcqE/GEvEdwhmF4LhBH9fXHmSpTHwuyIgLJfCQ6j1HpEjGUHDpJ /N8qLYCxogPMROogNonrIm3UzW7hm2tmrsALF2oIEAnGmZHchA0rgijAEzWGIYxXRDfd mM/iJDSgp57+UeVDLXhjDmRxWSUPED6Af2l1F2dDmMWuDSPLb5mEyBPuBDvUD26UZl/g AUFwU1GzNGO3hlJ73G3l3wuD+keM3RoZtRB01vgzRl2rPIawaN5QcqVnyrp9Wmqxya/+ frgA== MIME-Version: 1.0 Received: by 10.213.17.1 with SMTP id q1mr2025212eba.29.1336708898104; Thu, 10 May 2012 21:01:38 -0700 (PDT) Received: by 10.213.34.78 with HTTP; Thu, 10 May 2012 21:01:38 -0700 (PDT) Date: Thu, 10 May 2012 21:01:38 -0700 Message-ID: From: Radia Perlman To: IESG IESG , secdir@ietf.org, draft-levine-application-gzip@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] Secdir review of draft-levine-application-gzip X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 04:01:39 -0000 Hello, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. No problems with this document, security or otherwise. Compliments to the authors for even being able to figure out what to write in a security considerations section for a document that is just assigning a code point. Radia From radiaperlman@gmail.com Thu May 10 21:11:46 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0ED21F84DE; Thu, 10 May 2012 21:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eh3zerTCZ6p7; Thu, 10 May 2012 21:11:46 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A2B5A21F84DD; Thu, 10 May 2012 21:11:45 -0700 (PDT) Received: by eekd4 with SMTP id d4so887105eek.31 for ; Thu, 10 May 2012 21:11:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=q6JlZWH9BTM2kWLvvSuYp4fcDHikvB9eZyytxlkXI0M=; b=dEvs23VS47DOax4tJ/7NO2blvGFDjnkR9FMmZASTPWa4zP3zTbrvrFfy7lpApKRIs+ 2i21Xsqxahu8s58QqlUC9f2IeePIK652E8C3T3sijTdcRBLn5TVwxDtoF7jiiuzW5jFT KryRkyie0nrRlh0V8lEvubER8xm/Y0B+rjOqtDR48QqfYqWDmabgJ+1GYgjjLVrUb9D1 VK2TcGn+GF33hnYJ0hB6dpUPrI3qxhrSFS2MrNpHg5lqOGEB/mxn163asq6/akFTRPJW 3V3Xulm3L95R/G6MVhjrBqOw9Zoub6tkK2CTrtsUcraRR++W6TB2Acrs1vGa8ZojeHPd fuvA== MIME-Version: 1.0 Received: by 10.14.198.8 with SMTP id u8mr475592een.58.1336709504822; Thu, 10 May 2012 21:11:44 -0700 (PDT) Received: by 10.213.34.78 with HTTP; Thu, 10 May 2012 21:11:44 -0700 (PDT) Date: Thu, 10 May 2012 21:11:44 -0700 Message-ID: From: Radia Perlman To: IESG IESG , secdir@ietf.org, draft-ietf-pwe3-redundancy@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] Fwd: Secdir review of draft-ietf-pwe3-redundancy-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 04:11:46 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. =A0These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. No security issues with this document. Radia From weiler+secdir@watson.org Fri May 11 12:40:25 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8F721F874A for ; Fri, 11 May 2012 12:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWt68gEjFicP for ; Fri, 11 May 2012 12:40:25 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 41DFF21F8749 for ; Fri, 11 May 2012 12:40:25 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4BJeNOq058022 for ; Fri, 11 May 2012 15:40:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4BJeNaZ058019 for ; Fri, 11 May 2012 15:40:23 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 11 May 2012 15:40:23 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 11 May 2012 15:40:24 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:40:26 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Yaron Sheffer is next in the rotation. For telechat 2012-05-24 Reviewer LC end Draft Alan DeKok T 2012-04-17 draft-claise-export-application-info-in-ipfix-07 Jeffrey Hutzelman T 2012-04-16 draft-ietf-manet-nhdp-mib-13 Eric Rescorla T 2012-05-21 draft-ietf-pkix-cmp-transport-protocols-18 Last calls and special requests: Matt Lepinski 2012-05-02 draft-ietf-mboned-64-multicast-address-format-01 Russ Mundy 2012-05-09 draft-ietf-netext-access-network-option-10 Yoav Nir 2012-05-14 draft-ietf-ccamp-assoc-info-03 Magnus Nystrom 2012-05-10 draft-ietf-codec-opus-12 Hilarie Orman 2012-05-28 draft-polk-ipr-disclosure-03 Tim Polk 2012-03-21 draft-ietf-pwe3-redundancy-bit-07 Tim Polk 2012-06-04 draft-farrresnickel-ipr-sanctions-05 Vincent Roca 2012-05-21 draft-ietf-appsawg-media-type-regs-07 Joe Salowey 2012-06-04 draft-kucherawy-marf-source-ports-03 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From acmorton@att.com Sat May 12 16:38:48 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFD221F859F; Sat, 12 May 2012 16:38:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.455 X-Spam-Level: X-Spam-Status: No, score=-103.455 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynnTXZ8EOGD3; Sat, 12 May 2012 16:38:48 -0700 (PDT) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id E834021F859B; Sat, 12 May 2012 16:38:47 -0700 (PDT) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-8) over TLS secured channel with ESMTP id 784feaf4.0.82689.00-466.213914.nbfkord-smmo08.seg.att.com (envelope-from ); Sat, 12 May 2012 23:38:48 +0000 (UTC) X-MXL-Hash: 4faef4882f9e48c7-1cba9ec55cf5e774b3214857f6bcc7b6d3c35c35 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4CNclLq019754; Sat, 12 May 2012 19:38:47 -0400 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q4CNcjpO019751 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 12 May 2012 19:38:45 -0400 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor); Sat, 12 May 2012 19:38:23 -0400 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4CNcLjR004287; Sat, 12 May 2012 19:38:22 -0400 Received: from dns.maillennium.att.com (mailgw1.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q4CNcE54004136; Sat, 12 May 2012 19:38:15 -0400 Message-Id: <201205122338.q4CNcE54004136@alpd052.aldc.att.com> Received: from acmt.att.com (vpn-135-70-76-152.vpn.swst.att.com[135.70.76.152](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20120512233446gw10060l34e>; Sat, 12 May 2012 23:34:49 +0000 X-Originating-IP: [135.70.76.152] X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 12 May 2012 19:39:24 -0400 To: Stephen Farrell , "Murphy, Sandra" From: Al Morton In-Reply-To: <4F8700F8.4060709@cs.tcd.ie> References: <20120406144445.4188.3196.idtracker@ietfa.amsl.com> <201204061553.q36FrBRV007699@alpd052.aldc.att.com> <07e001cd14e0$41b408c0$c51c1a40$@olddog.co.uk> <201204080018.q380I1VK007743@alpd052.aldc.att.com> <099701cd15b1$fc18c990$f44a5cb0$@olddog.co.uk> <201204091344.q39Di1rK002725@alpd052.aldc.att.com> <0bea01cd168a$7ed8ae80$7c8a0b80$@juniper.net> <4F8578DE.1020808@cisco.com> <4F85C96C.4050705@mti-systems.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F6F2DD0@Hermes.columbia.ads.sparta.com> <4F8700F8.4060709@cs.tcd.ie> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=1.0 c=1 a=5eIHOXXyF6EA:10 a=ZswZ2TFLv48A:10 a=ofMgfj31e3] X-AnalysisOut: [cA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=ZRNLZ4dFUbCvG8] X-AnalysisOut: [UMqPvVAA==:17 a=48vgC7mUAAAA:8 a=-Cb5Q1N6AAAA:8 a=OUXY8nFu] X-AnalysisOut: [AAAA:8 a=AEDFM0qtAAAA:8 a=Z1rYrKf4OG4p9fYrxzAA:9 a=th8_0in] X-AnalysisOut: [fIyJceI3zIosA:7 a=CjuIK1q_8ugA:10 a=czfYQaGQYtkA:10 a=peF9] X-AnalysisOut: [eE_zjQwA:10 a=jqlaW5bC1iAA:10 a=lZB815dzVvQA:10 a=J4IfIaeN] X-AnalysisOut: [E9Zpx8TY:21 a=TVbLTcCWtvzaL9Cn:21] Cc: "secdir@ietf.org" , Wesley Eddy , "afarrel@juniper.net" , 'Samuel Weiler' , "ippm-chairs@tools.ietf.org" , 'The IESG' , Benoit Claise , "adrian@olddog.co.uk" , 'Dan Frost' , "draft-ietf-ippm-rt-loss@tools.ietf.org" Subject: Re: [secdir] Adrian Farrel's Discuss on draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 23:38:48 -0000 Sandy, To thoroughly close discussion on the additional point you raised: >There's one question I'm not adequate to address, and I leave it to >the authors and ADs to address: > > Although this metric MAY be applicable in > passive measurement as well, discussion of additional considerations > for the passive scenario are beyond the normative scope of this memo. > >Does that "MAY" mean "optional" in the 2119 sense, or >"might"/"could" in normal English usage sense? We do mean it's optional in the 2119 sense, and the additional considerations would need to be determined by the passive measurement designer. A draft I just reviewed http://tools.ietf.org/html/draft-akhter-opsawg-perfmon-method-02 gives many of these considerations (for passive one-way loss). regards, Al At 12:21 PM 4/12/2012, Stephen Farrell wrote: >Thanks Sandy, > >I've cleared. > >S > >On 04/12/2012 05:19 PM, Murphy, Sandra wrote: >>Dan Frost and I brought up some of the same comments, wrt the >>active or passive use of the metric and the suggestion of >>cryptographic hashes to solve security considerations. >> >>The latest revision satisfies me. >> >>There's one question I'm not adequate to address, and I leave it to >>the authors and ADs to address: >> >> Although this metric MAY be applicable in >> passive measurement as well, discussion of additional considerations >> for the passive scenario are beyond the normative scope of this memo. >> >>Does that "MAY" mean "optional" in the 2119 sense, or >>"might"/"could" in normal English usage sense? >> >>It sounds like this is saying "there are considerations if this >>metric is used in a passive scenario, which we aren't going to >>discuss, but even so you have the option to use this". >> >>I don't know what the "additional considerations" would be. If >>they are considerations that a measurement implementer should heed, >>that's not much of a worry. If they are considerations that impact >>others, that's more of a worry. (Section 9.2's discussion of >>keeping info confidential (for passive measurements) is an example >>of considerations that impact others.) >> >>So I'll leave it to those who know whether that "MAY" is OK or not. >> >>--Sandy >> >>________________________________________ >>From: Wesley Eddy [wes@mti-systems.com] >>Sent: Wednesday, April 11, 2012 2:11 PM >>To: Benoit Claise >>Cc: afarrel@juniper.net; 'Al Morton'; adrian@olddog.co.uk; 'Samuel >>Weiler'; 'The IESG'; ippm-chairs@tools.ietf.org; >>draft-ietf-ippm-rt-loss@tools.ietf.org; 'Dan Frost'; Murphy, >>Sandra; secdir@ietf.org >>Subject: Re: Adrian Farrel's Discuss on >>draft-ietf-ippm-rt-loss-03: (with DISCUSS and COMMENT): new (temp) draft? >> >>On 4/11/2012 8:28 AM, Benoit Claise wrote: >>>Al, Wes >>> >>>I want to review this draft before the IESG telechat tomorrow. >>>However, it's getting difficult to keep track of the all the changes >>>between >>> - the posted version 3 >>> - the diff-03-04 you sent >>> - the extra proposal. >>> >>>What is the best way to proceed? >>> - Al, have you kept a temp version with all the changes? >>> - Are we shooting for "revised-ID" at the telechat? I could start my >>>review from there >>> - Do we want to have a version 4 posted now? >>> >>>What is the best way to proceed? >> >> >>I noticed Al sent a copy with updates that have been suggested >>so far. >> >>Please feel free to hit the "Defer" button if you don't feel >>there's adequate time to review this one; it looks like a busy >>telechat agenda this week! >> >>-- >>Wes Eddy >>MTI Systems From ynir@checkpoint.com Sat May 12 23:46:38 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7FE121F85D3; Sat, 12 May 2012 23:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.411 X-Spam-Level: X-Spam-Status: No, score=-10.411 tagged_above=-999 required=5 tests=[AWL=0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-bJIF8pQeO0; Sat, 12 May 2012 23:46:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C96C521F85A5; Sat, 12 May 2012 23:46:37 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q4D6kYM3005131; Sun, 13 May 2012 09:46:34 +0300 X-CheckPoint: {4FAF660F-1-1B221DC2-2FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 13 May 2012 09:46:34 +0300 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sun, 13 May 2012 09:46:32 +0300 From: Yoav Nir To: "ietf@ietf.org list" , "secdir@ietf.org" , "draft-ietf-ccamp-assoc-info@tools.ietf.org" Date: Sun, 13 May 2012 09:46:39 +0300 Thread-Topic: SecDir review of draft-ietf-ccamp-assoc-info-03 Thread-Index: Ac0w1CH59UUTwht/T5yyQqZVlWAu/w== Message-ID: <329567CB-2EC4-4D9A-8E52-5D9D22C24417@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled X-KSE-Antivirus-Interceptor-Info: scan successful X-KSE-Antivirus-Info: Clean Subject: [secdir] SecDir review of draft-ietf-ccamp-assoc-info-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 06:46:38 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like any= other last call comments. The document does not define any new procedures or mechanisms, and mentions= this fact three times throughout the document. It formalizes an email by A= drian Farrel clarifying the procedures for processing an ASSOCIATION object= on a path message.=20 The security considerations section repeats that the document does not defi= ne new procedures, and concludes that no security considerations are added.= This is not a valid deduction, as clarification often involves prohibiting= non-functional or insecure interpretation of the original document text. H= owever, in this case the clarification is not about such insecure configura= tions, so the document is fine. One textual comment, though: section 2.2 near the bottom of page #5 lists 3= possible values for association ID. The second option is "The LSP ID of th= e LSP protecting an LSP". This is not clear. I suggest rewording as "The LS= P ID of the protecting LSP" without an indefinite "an LSP". Yoav= From adrian@olddog.co.uk Sun May 13 14:08:49 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66EF121F84DE; Sun, 13 May 2012 14:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dj4bDR+C7eno; Sun, 13 May 2012 14:08:49 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id A475421F84A5; Sun, 13 May 2012 14:08:48 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4DL8Z46000494; Sun, 13 May 2012 22:08:39 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4DL8YiW000480 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 13 May 2012 22:08:34 +0100 From: "Adrian Farrel" To: "'Yoav Nir'" , , , References: <329567CB-2EC4-4D9A-8E52-5D9D22C24417@checkpoint.com> In-Reply-To: <329567CB-2EC4-4D9A-8E52-5D9D22C24417@checkpoint.com> Date: Sun, 13 May 2012 22:08:34 +0100 Message-ID: <007d01cd314c$8f990c60$aecb2520$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFQj/2ZSa0yZlPsIw/HdQ+ygAHEMZfBePeQ Content-Language: en-gb Subject: Re: [secdir] SecDir review of draft-ietf-ccamp-assoc-info-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 21:08:49 -0000 Thanks Yoav, RFC Editor note entered for your observation. Adrian > -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.org] On Behalf Of Yoav > Nir > Sent: 13 May 2012 07:47 > To: ietf@ietf.org list; secdir@ietf.org; draft-ietf-ccamp-assoc-info@tools.ietf.org > Subject: SecDir review of draft-ietf-ccamp-assoc-info-03 > > Hi, > > I have reviewed this document as part of the security directorate's ongoing effort > to review all IETF documents being processed by the IESG. These comments > were written primarily for the benefit of the security area directors. Document > editors and WG chairs should treat these comments just like any other last call > comments. > > The document does not define any new procedures or mechanisms, and > mentions this fact three times throughout the document. It formalizes an email > by Adrian Farrel clarifying the procedures for processing an ASSOCIATION object > on a path message. > > The security considerations section repeats that the document does not define > new procedures, and concludes that no security considerations are added. This is > not a valid deduction, as clarification often involves prohibiting non-functional or > insecure interpretation of the original document text. However, in this case the > clarification is not about such insecure configurations, so the document is fine. > > One textual comment, though: section 2.2 near the bottom of page #5 lists 3 > possible values for association ID. The second option is "The LSP ID of the LSP > protecting an LSP". This is not clear. I suggest rewording as "The LSP ID of the > protecting LSP" without an indefinite "an LSP". > > Yoav= From hartmans@mit.edu Mon May 14 10:56:24 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5940911E8095; Mon, 14 May 2012 10:56:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.747 X-Spam-Level: X-Spam-Status: No, score=-102.747 tagged_above=-999 required=5 tests=[AWL=-0.482, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08fZtSKAFBaU; Mon, 14 May 2012 10:56:23 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DB38C11E8096; Mon, 14 May 2012 10:56:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5FBFD203C0; Mon, 14 May 2012 13:52:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 16B4B44B6; Mon, 14 May 2012 13:56:02 -0400 (EDT) From: Sam Hartman To: Joe Salowey References: Date: Mon, 14 May 2012 13:56:02 -0400 In-Reply-To: (Joe Salowey's message of "Mon, 23 Apr 2012 14:06:38 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Sam Hartman , draft-ietf-emu-chbind@tools.ietf.org, IETF-Discussion list , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-emu-chbind-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:56:24 -0000 >>>>> "Joe" == Joe Salowey writes: Hi. I'm responding where I'm not able to just take Steve's changes. Joe> Hi Steve, Thanks for taking time to perform a detailed review >> In the Introduction, the second paragraph says that the problem >> "results when the same credentials are used to access multiple >> services that differ in some interesting property". Do you mean >> client or server credentials? I think you mean EAP server >> credentials. Please be more explicit to make this clearer, since >> many people will assume that you mean client (EAP peer) >> credentials. If I'm correct and you do mean EAP server >> credentials, I suggest that you say so in the first sentence of >> this paragraph and also in the last sentence. >> [Joe] The case here is both client and server credentials. If different credentials are required for each type of service then the authenticator will not be able to lie about the type of service it is representing to the client because the client credentials are bound to the service. There are a couple of things going on. first, not all EAP methods distinguish server and client credentials. Generally, you can fix the problem either way: use different server credentials or have access to disjoint service sets from different client credentials. Lots of factors affect whether that's an adequate defense. For example using different server credentials for accessing different services provides no defense for peers who do not validate server credentials. I've added a sentence indicating that generally either type of credential can be used as a defense but I have not gone into the full details. That's not appropriate for the introduction and may not be appropriate for this document. >> In the first paragraph of the Problem Statement, the second >> sentence says "However, when operating in pass-through mode, the >> EAP server can be far removed from the authenticator." While >> this is true, I think the more relevant statement here is that >> the EAP server can be far removed from the EAP peer. This >> paragraph is all about problems that can arise when parties >> between the EAP peer and the EAP server (including the >> authenticator) are malicious or compromised. So the important >> thing to point out at the start of the paragraph is the large >> number of parties that may come between the EAP server and the >> EAP peer. >> [Joe] I think I see your point, but I'm not sure. Traditionally, we have often thought of the path between EAP peer and EAP authenticator as being vulnerable to having multiple parties able to insert themselves into the conversation. However it may be the case that the authenticator the peer is talking to isn't the one it thinks it is and the "real" authenticator may be somewhere in the path as well. The conversation between the EAP peer and EAP server will not be compromised, however the result of the conversation may not have its intended effect. I think Steve's clarification makes the text worse. Conceptually/trust wise, the peer and EAP server are very close. There's a protected path between them. I've added both in terms of network distance and number of entities who need to be trusted in order to establish trusted communication I'm also happy with the original text. >> In the second bullet of section 3 (on page 7), the EAP GSS-API >> mechanism is a good example. However, I wonder if this attack >> might take a slightly different form. Could the IM server pretend >> to be the mail server? I think so. That's just one specific >> example of a relatively untrusted service pretending to be a >> relatively trusted service. I suggest that you add an example >> like that since the current language is quite abstract. >> [Joe] I agree having a more concrete example would be helpful. The reason I didn't do that is that trust is relative. Apparently in Steve's environments mail servers are more trusted than IM servers. In my environments I think the opposite may be true, although both are relatively untrusted. I added "For example, the instant messaging service could impersonate the mail server." I think there is a WG consensus to keep that text, and would push back against a change at this point. I'm fairly sure this issue was discussed in the WG and keeping that text was part of a compromise to move forward with a specific approach. Like Joe, if there are clarity issues surrounding what's normative I'd like to make sure those are fixed. >> In the first paragraph of section 5.1, you say that "the EAP >> server needs to be able to access information from the AAA server >> that is utilized during the EAP session and a local >> database". Which information? A parenthetical example (an e.g.) >> would help with understanding what you mean. >> [Joe] OK I added (i2 below) to the sentence. There's a fair bit of detail around this information in the following text. >> the EAP lower layer in use. But you say in the first sentence of >> that section that this attribute is defined to "carry the EAP >> lower layer". That sounds like all the lower layer traffic will >> be encapsulated in this attribute and carried in it. I think you >> should change the word "carry" in that text to "identify". >> Unless I misunderstood you. >> [Joe] OK Thanks for this catch! >> As I read section 8, I wonder whether include the User-Name >> attribute in i2 could open the system up to attacks where an >> authenticator or intermediate proxy could remove the anonymity of >> a user who's using a pseudonym for the username by changing the >> value of the User-Name attribute to the username of the user >> suspected of being responsible for this authentication. If the >> channel bindings checks fail, the authenticator will know they >> were wrong but if the channel bindings checks succeed, the >> authenticator will have confirmation of the user's identity. >> [Joe] Perhaps, on the one hand I would think the system would not behave this way, the server would be expecting a pseudonym or token and fail if it got something else. On the other hand, I don' think the text for the user-name check or the test itself are that useful. We could either warn against the possible identity disclosure or remove the user-name check. >> I didn't understand that sending i2 from the server to the peer >> is optional until I got to section 9.1. In section 5.3, you said >> that "For success, the server returns the attributes that were >> considered by the server in making the determination that channel >> bindings are successfully validated". Which of these is right? >> [Joe] The server is required to return the channel-binding attributes it verified because the client may require certain attributes to be checked. This list of verified attributes is not equivalent to i2. i2 is what attributes are sent in the AAA protocol and I don't think it should be referenced here. Instead it should probably say: Joe> "sending the result from server to peer over Joe> integrity-protected channel" Good tactch; made a similar change. >> At the top of page 23, you say that "In many EAP deployments >> today attacks where one NAS can impersonate another are out of >> scope." Do you mean that these attacks are generally not >> considered but they are a potential problem? Or that they are not >> a problem? I think they are always a possible problem. Even when >> all the NASes are owned and managed by the same organization that >> runs the AAA server and no proxies are used, there's still the >> potential for a NAS to become compromised. So I think you should >> say these attacks are "not considered although a real concern" >> not that they are "out of scope". Joe> [Joe] As EAP is deployed in most cases today the authenticator Joe> is not identified, it is merely authorized as being part of the Joe> network. The peer does not expect differentiated service based Joe> on the NAS it is connected to. Since the service is the same Joe> it does not matter to the peer if one authenticator Joe> impersonates another. When we start discussing use case such Joe> as ABFAB where different services are being provided did the Joe> identity of the authenticator really become an issue. Joe> Perhaps the following text is better Joe> "In many EAP deployments today attacks where one authenticator Joe> can impersonate another not a real concern since different Joe> authenticators provide the same service. In these situations Joe> an authenticator does not gain significant advantage in Joe> impersonating another authenticator. " >> And then the following sentence says that "Channel bindings >> brings these attacks into scope". Again, I think those attacks >> are always a potential issue. Channel bindings provide a good way >> to address them, whereas there were few ways to do so >> before. Maybe it would be better to say that. >> [Joe] I see your point here, how about: Joe> "The use of EAP in situations where different authenticators Joe> provide different services makes the ability to authorize Joe> different authenticators more important. The system as a whole Joe> needs to be analyzed to evaluate cases where one authenticator Joe> may impersonate another and to evaluate the impact of this Joe> impersonation. Channel bindings provides a way to address Joe> these issues. " >> In the next paragraph, you say that when cryptographic binding is >> used in a tunnel method, the MSK is disclosed to the NAS. I >> don't think that's right. The MSK that's disclosed to the NAS is >> the one generated by the outer method. The MSK that's used in >> cryptographic binding is the one that's generated by the inner >> method. I don't think there's a problem there. >> [Joe] OK, this test is referring to where there is separate between the terminating server of the inner and outer methods. Maybe it would be clearer if the text said the following: Joe> "Even when cryptographic binding does attempt to confirm that Joe> the inner and outer server are the same, the Master Session Key Joe> (MSK) from the inner method is typically used to protect the Joe> binding. However, if the outer method tunnel terminates on the Joe> authenticator the inner MSK is disclosed to the authenticator, Joe> which can attack cryptographic binding." >> Later in that paragraph, you say that an attack where the NAS >> terminates an EAP tunnel method is not in scope for existing >> models for cryptographic binding. I think that's wrong also. EAP >> tunnel methods protect against just this sort of attack. The >> first step in these methods is for the EAP peer and the EAP >> server to build a TLS tunnel. This requires the EAP peer to >> authenticate the EAP server and decide whether it's trusted. If >> the NAS has credentials that will cause the EAP peer to trust it >> as an EAP server, a MITM attack is possible. Of course, that's >> true for any secure communications and it's a very bad >> situation. That's why the EAP peer must be very careful about who >> it trusts and how it authenticates them and the EAP server (and >> any CAs or other TTPs) must also be similarly careful. I don't >> see that any of this has much to do with channel bindings. Am I >> missing something here? If so, please explain it. And maybe you >> can clarify the text so that other folks get it also. >> [Joe] The issue is when you have different services the client may not have enough information to determine what an authenticator is authorized for based on its identity alone. In this case it would like help from the server that terminates the inner method. However current crypto binding is based on the MSK so the authenticator can generate whatever channel binding quantities it wants because the authenticator has all the necessary key material. In order for channel bindings to determine if the authenticator is authorized or not, the method needs protect the channel bindings with a key generated from the inner method EMSK that the authenticator does not possess. Here is some text that may help: Joe> "If the authenticator controls the cryptographic binding then Joe> it also controls the channel binding parameters and results. Joe> If the channel binding process is used to differentiate one Joe> authenticator from another then the authenticator can claim to Joe> support services that it was not authorized to. This attack Joe> was not in scope for existing threat models for cryptographic Joe> binding because differentiated authenticators was not a Joe> consideration. Thus, existing cryptographic binding does not Joe> typically provide mutual authentication of the inner method Joe> server required for channel binding." >> In section 9.2, this paragraph appears: >> >> Dishonest peers can only manipulate the first message i1 of the >> channel binding protocol. In this scenario, a peer sends i1' to >> the server. If i1' is invalid, the channel binding validation >> will fail. On the other hand if i1' passes the validation, >> either the original i1 was wrong and i1' corrected the problem or >> both i1 and i1' constitute valid information. A peer could >> potentially gain an advantage in auditing or charging if both are >> valid and information from i1 is used for auditing or charging. >> Such peers can be detected by including the information in i2 and >> checking i1 against i2. >> >> In the penultimate sentence, I think you mean "information from >> i1' is used for auditing or charging." There's no problem if >> information from i1 is used for auditing. If that happens, the >> bad peer's information is being ignored. >> [Joe] I think you are correct. >> That paragraph does make me wonder about another attack that >> could be enabled by channel bindings. What if a malicious peer >> gets perfectly good i1 from a NAS but then sends bad i1' to the >> EAP server with a goal of damaging the reputation of the NAS? The >> EAP peer could be working for a competitor of the organization >> that runs the NAS or just be malicious. Is that a valid concern? >> If so, maybe you should cite it and suggest a countermeasure. >> [Joe] I think this is a valid concern for some environments. I think we should add a section for that. >> In section 9.4, you refer to "the optional result message". I >> didn't know before this that the result message was optional. >> Could you make that clear earlier? >> [Joe] The result message is not intended to be optional. This text needs to be fixed. >> In the IANA Considerations, you talk about creating a new "EAP >> Channel Binding Parameters" top level registry. That's fine. But >> then you talk about a "Channel Binding Codes" registry. Didn't >> you mean a "sub registry"? If you want the Channel Binding Codes >> registry to be in the EAP Channel Binding Paramters registry, I >> think the first one is really a sub registry. Joe> [Joe] Yes >> Also, you say that "Early allocation is allowed" for that >> registry. What does that mean? I don't see any description of >> "early allocation" in RFC 5226. I expect that IANA will want to >> know what they need to do to provide "early allocation". How >> early? Etc. >> [Joe] OK, I need to check if there is any convention here. >> In the definition of the "Channel Binding Namespaces" registry, >> did you want to include a reference column as you did in the >> "Channel Binding Codes" registry? If so, maybe you should say >> so. >> [Joe] OK >> At the end of section 11.1, a sentence says that "Values skipped >> in the above table are available for assignment." I don't think >> any values were skipped so I don't think you need that sentence. >> [Joe] Yup, left over from previous version. >> Appendix A is pretty similar to section 1. Might you be able to >> merge them somehow? >> [Joe] I think the authors attempted to do this and then decided it was better to keep them separate. >> In section A.3, you describe downgrading attacks and how channel >> bindings can prevent them. However, I think this will only work >> if the EAP peer rejects all methods that don't include channel >> bindings. Otherwise, the NAS can just offer an unauthorized EAP >> method that permits it to obtain the user's credentials and off >> to the bank. >> [Joe] I believe you are correct. From new-work-bounces@ietf.org Tue May 15 10:53:21 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3458E21F8732; Tue, 15 May 2012 10:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1337104401; bh=TeL0K4hyCzSXUMFE86/8/Y3cNYzCSdE6r7xPSsJFty8=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=j+rUgS3xOn+UAm3HE2lMLLxygIt58UinLlrOr6rDu85fl3oj8w6BTh+rcmn84mKlt e4uzFcGk2IAE/iTnKXnoXUxGHtjHWn5cMI78IHbjjbJLMn+y6f0kFYTxXigt2i+Lu4 awaTAqkpQibp2Gu7D8N86Pb32lu+gcOcQpGn7tN0= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D6521F873D; Tue, 15 May 2012 10:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.264 X-Spam-Level: X-Spam-Status: No, score=-102.264 tagged_above=-999 required=5 tests=[AWL=-0.265, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agsSI+a-nPIU; Tue, 15 May 2012 10:53:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65E5221F872E; Tue, 15 May 2012 10:53:19 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515175319.13879.23149.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 10:53:19 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 15 May 2012 12:24:09 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Behavior Engineering for Hindrance Avoidance (behave) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 17:53:21 -0000 A modified charter has been submitted for the Behavior Engineering for Hindrance Avoidance (behave) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 22, 2012. Behavior Engineering for Hindrance Avoidance (behave) ----------------------------------------------------- Current Status: Active Last updated: 2012-05-10 Chairs: Dan Wing Dave Thaler Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Wesley Eddy Mailing Lists: General Discussion: behave@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/behave Archive: http://www.ietf.org/mail-archive/web/behave Description of Working Group The working group creates documents to enable IPv4/IPv4 and IPv6/IPv4 NATs to function in as deterministic a fashion as possible. To support deployments where communicating hosts require using different address families (IPv4 or IPv6), address family translation is needed to establish communication. In BEHAVE's specification work on this topic it will coordinate with the V6ops WG on requirements and operational considerations. "An IPv4 network" or "an IPv6 network" in the descriptions below refer to a network with a clearly identifiable administrative domain (e.g., an enterprise campus network, a mobile operator's cellular network, a residential subscriber network, etc.). It will also be that network that deploys the necessary equipment for translation. BEHAVE will finish four scenarios: (1) An IPv6 network to IPv4 Internet, (2) an IPv6 Internet to an IPv4 network, (3) an IPv6 network to an IPv4 network, and (4) an IPv4 network to an IPv6 network. Specifically, BEHAVE will update the NAT MIB (RFC 4008) to be consistent with the management aspects of its IPv6/IPv4 NAT solutions, and specify IPFIX information elements to meet logging requirements, reusing existing elements, if possible. In addition, when a NAT (such as a NAT64 in the "An IPv6 network to IPv4 Internet" scenario) serves multiple subscribers, inter-subscriber fairness issues arise. As such, BEHAVE will complete its work on Carrier Grade NAT requirements for such scenarios, and update the NAT MIB as needed to meet such requirements. BEHAVE will not, however, standardize IPv4-specific behavioral mechanisms. The following scenarios remain in scope for discussion, but will not be solved by BEHAVE: * An IPv4 network to IPv6 Internet, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv4 network using either public or private IPv4 address space. * IPv4 Internet to an IPv6 network, i.e. perform translation between IPv4 and IPv6 for packets in uni- or bi-directional flows that are initiated from an IPv4 host towards an IPv6 host. The translator function is intended to service a specific IPv6 network where selected IPv6 hosts and services are to be reachable. This group will also provide reviews of any work by the MBoneD WG on multicast translation, including control traffic (IGMP and MLD), Single Source Multicast (SSM) and Any Source Multicast (ASM). If the WG deems it necessary, BEHAVE will revise RFCs previously published by BEHAVE. Goals and Milestones Done Submit BCP that defines unicast UDP behavioral requirements for NATs to IESG Done Submit a BCP that defines TCP behavioral requirements for NATs to IESG Done Submit a BCP that defines ICMP behavioral requirements for NATs to IESG Done Submit informational that discusses current NAT traversal techniques used by applications Done Submit BCP that defines multicast UDP Done Submit revision of RFC 3489 to IESG behavioral requirements for NATs to IESG Done Submit informational document for rfc3489bis test vectors Done Submit experimental document that describes how an application can determine the type of NAT it is behind Done Submit BCP document for DCCP NAT behavior Done Determine relative prioritization of the four translation cases. Documented in IETF74 minutes. Done Determine what solutions(s) and components are needed to solve each of the four cases. Create new milestones for the solution(s) and the components. Documented in IETF74 minutes. Done Submit to IESG: relaying of a TCP bytestream (std) Done Submit to IESG: relay protocol (std) Done Submit to IESG: TURN-URI document (std) Done Submit to IESG: IPv6 relay protocol (std) Done Submit to IESG: framework for IPv6/IPv4 translation (info) Done Submit to IESG: stateless IPv6/IPv4 translation (std) Done Submit to IESG: stateful IPv6/IPv4 translation (std) Done Submit to IESG: DNS rewriting for IPv6/IPv4 translation (std) Done Submit to IESG: IPv6 prefix for IPv6/IPv4 translator (std) Done Determine need and scope of multicast 6/4 translation Done Submit to IESG: FTP ALG for IPv6/IPv4 translation (std) Jul 2012 Submit to IESG: large scale NAT requirements (BCP) Done Submit to IESG: Analysis of NAT-PT considerations with IPv6/IPv4 translation (info) Jul 2012 Submit to IESG: avoiding NAT64 with dual-stack host for local networks (std) Done Submit to IESG: host-based NAT46 translation for IPv4-only applications to access IPv6-only servers (std) Nov 2012 Submit to IESG: updates to NAT MIB for NAT64 (std) Nov 2012 Submit to IESG: updates to NAT MIB for CGNs (std) Nov 2012 Submit to IESG: IPFIX information elements (std) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue May 15 11:22:55 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8E921F884A; Tue, 15 May 2012 11:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1337106175; bh=pU9aiEPQW1OQKRWZ8S97i/Au1gyOXrHxpAjVS5t82Vw=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=w44DCtg9OrDO8lCy2khgJLBAPnkLCtU7ZOW4e/LaQGg1FHg09Sznpkwi8A2SYbcRT YqaXa1xK1mDxhL1MX3V/Ki0HxEnSBbA+xbJ6T5pxiCAkq6I12AIKCXZHTIxJVgGbVM IDB0oD1eXj/P12/774CI60ItBdhMD+Pol4tIxf8s= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C706621F885D; Tue, 15 May 2012 11:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id botOm6msMYZ3; Tue, 15 May 2012 11:22:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8E5521F8858; Tue, 15 May 2012 11:22:54 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515182254.22256.83602.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 11:22:54 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 15 May 2012 12:24:09 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Multipath TCP (mptcp) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:22:55 -0000 QSBtb2RpZmllZCBjaGFydGVyIGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgdGhlIE11bHRpcGF0aCBU Q1AgKG1wdGNwKSAKd29ya2luZyBncm91cCBpbiB0aGUgVHJhbnNwb3J0IEFyZWEgb2YgdGhlIElF VEYuICBUaGUgSUVTRyBoYXMgbm90IG1hZGUgCmFueSBkZXRlcm1pbmF0aW9uIGFzIHlldC4gIFRo ZSBtb2RpZmllZCBjaGFydGVyIGlzIHByb3ZpZGVkIGJlbG93IGZvciAKaW5mb3JtYXRpb25hbCBw dXJwb3NlcyBvbmx5LiAgUGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgSUVTRyAKbWFp bGluZyBsaXN0IChpZXNnQGlldGYub3JnKSBieSBUdWVzZGF5LCBNYXkgMjIsIDIwMTIuCgpNdWx0 aXBhdGggVENQIChtcHRjcCkKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpTdGF0dXM6IEFjdGl2ZSBXb3JraW5nIEdyb3VwCkxhc3QgdXBk YXRlZDogMjAxMi0wNS0xMAoKQ2hhaXJzOgogICAgUGhpbGlwIEVhcmRsZXkgPHBoaWxpcC5lYXJk bGV5QGJ0LmNvbT4KICAgIFlvc2hpZnVtaSBOaXNoaWRhIDxuaXNoaWRhQHNmYy53aWRlLmFkLmpw PgoKVHJhbnNwb3J0IEFyZWEgRGlyZWN0b3JzOgogICAgV2VzbGV5IEVkZHkgPHdlc0BtdGktc3lz dGVtcy5jb20+CiAgICBNYXJ0aW4gU3RpZW1lcmxpbmcgPG1hcnRpbi5zdGllbWVybGluZ0BuZWNs YWIuZXU+CgpUcmFuc3BvcnQgQXJlYSBBZHZpc29yOgogICAgV2VzbGV5IEVkZHkgPHdlc0BtdGkt c3lzdGVtcy5jb20+CgpNYWlsaW5nIExpc3Q6IAogQWRkcmVzczoJbXVsdGlwYXRodGNwQGlldGYu b3JnCiBUbyBTdWJzY3JpYmU6CWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXVsdGlwYXRodGNwCiBBcmNoaXZlOglodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvbXVsdGlwYXRodGNwLwoKRGVzY3JpcHRpb24gb2YgV29ya2luZyBHcm91cDoKClRoZSBNdWx0 aXBhdGggVENQIChNUFRDUCkgd29ya2luZyBncm91cCBkZXZlbG9wcyBtZWNoYW5pc21zIHRoYXQg YWRkIHRoZQpjYXBhYmlsaXR5IG9mIHNpbXVsdGFuZW91c2x5IHVzaW5nIG11bHRpcGxlIHBhdGhz IHRvIGEgcmVndWxhciBUQ1AKc2Vzc2lvbi4gIEtleSBnb2FscyBmb3IgTVBUQ1AgYXJlOiB0byBi ZSBkZXBsb3lhYmxlIGFuZCB1c2FibGUgd2l0aG91dApzaWduaWZpY2FudCBjaGFuZ2VzIHRvIGV4 aXN0aW5nIEludGVybmV0IGluZnJhc3RydWN0dXJlOyB0byBiZSB1c2FibGUgYnkKdW5tb2RpZmll ZCBhcHBsaWNhdGlvbnM7IGFuZCB0byBiZSBzdGFibGUgYW5kIGNvbmdlc3Rpb24tc2FmZSBvdmVy IHRoZQp3aWRlIHJhbmdlIG9mIGV4aXN0aW5nIEludGVybmV0IHBhdGhzLCBpbmNsdWRpbmcgTkFU IGludGVyYWN0aW9ucy4gIE1QVENQCmFzc3VtZXMgdGhhdCBib3RoIHBlZXJzIGFyZSBtb2RpZmll ZCBhbmQgdGhhdCBvbmUgb3IgYm90aCBwZWVycyBoYXZlCm11bHRpcGxlIGFkZHJlc3Nlcywgd2hp Y2ggb2Z0ZW4gcmVzdWx0cyBpbiBkaWZmZXJlbnQgbmV0d29yayBwYXRocyB0aGF0CmFyZSBhdCBs ZWFzdCBwYXJ0aWFsbHkgZGl2ZXJnZW50IChob3dldmVyLCBub3RlIHRoZXJlIGlzIG5vIGd1YXJh bnRlZQp0aGF0IHRoZSBwYXRocyBhcmUgZGl2ZXJnZW50IGF0IGFsbCkuCgpJbiBpdHMgaW5pdGlh bCBjaGFydGVyIHRoZSBXRyBwcm9kdWNlZCBleHBlcmltZW50YWwgb3IgaW5mb3JtYXRpb25hbApk b2N1bWVudHMgdGhhdCBkZWZpbmVkOgoKYS4gQW4gYXJjaGl0ZWN0dXJhbCBmcmFtZXdvcmsgZm9y IGNvbmdlc3Rpb24tZGVwZW5kZW50IG11bHRpcGF0aAp0cmFuc3BvcnQgcHJvdG9jb2xzLiBJdCBk ZXNjcmliZXMgdGhlIG1vdGl2YXRpb25zIGFuZCB0aGUgZ2VuZXJhbAphcHByb2FjaCB0aGF0IHNo b3VsZCBiZSBmb2xsb3dlZCB0byBlbmFibGUgY29uZ2VzdGlvbi1kZXBlbmRlbnQKbXVsdGlwYXRo IHRyYW5zcG9ydC4KCmIuIEEgc2VjdXJpdHkgdGhyZWF0IGFuYWx5c2lzIGZvciBtdWx0aXBhdGgg VENQLgoKYy4gQSBjb3VwbGVkIG11bHRpcGF0aC1hd2FyZSBjb25nZXN0aW9uIGNvbnRyb2wgYWxn b3JpdGhtLiBUaGlzCmFsZ29yaXRobSBpcyB0aGUgbXVsdGlwYXRoIGVxdWl2YWxlbnQgb2YgU0FD Sy9OZXdSZW5vIGNvbmdlc3Rpb24KY29udHJvbC4KCmQuIEV4dGVuc2lvbnMgdG8gY3VycmVudCBU Q1AgdG8gc3VwcG9ydCBtdWx0aS1hZGRyZXNzZWQgbXVsdGlwYXRoIFRDUC4KVGhpcyBjb3ZlcnMg YWxsIG9uLXRoZS13aXJlIGNoYW5nZXMgcmVxdWlyZWQgdG8gY3JlYXRlIGEgdHdvLWVuZGVkIE1Q VENQCnNvbHV0aW9uIHVzaW5nIG11bHRpcGxlIElQIGFkZHJlc3NlcyBhdCBvbmUgb3IgYm90aCBl bmRzLiBJdCBpbmNsdWRlcyBhCmJhc2ljIHNlY3VyaXR5IHNvbHV0aW9uLiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgCgplLiBBcHBsaWNhdGlvbiBJbnRlcmZhY2UgQ29uc2lk ZXJhdGlvbnMuIEl0IHN1bW1hcmlzZXMgdGhlIGltcGFjdCB0aGF0Ck1QVENQIG1heSBoYXZlIG9u IGFwcGxpY2F0aW9ucywgc3VjaCBhcyBjaGFuZ2VzIGluIHBlcmZvcm1hbmNlLiAgQWxzbywKaXQg ZGVzY3JpYmVzIGFuIG9wdGlvbmFsLCBiYXNpYyBhcHBsaWNhdGlvbiBpbnRlcmZhY2UgZm9yIE1Q VENQLWF3YXJlCmFwcGxpY2F0aW9ucyB0aGF0IHByb3ZpZGVzIGFjY2VzcyB0byBtdWx0aXBhdGgg YWRkcmVzcyBpbmZvcm1hdGlvbiBhbmQgYQpsZXZlbCBvZiBjb250cm9sIGVxdWl2YWxlbnQgdG8g cmVndWxhciBUQ1AuCgoKVGhlIHdvcmtpbmcgZ3JvdXAgbm93IHJlLWNoYXJ0ZXJzIHRvIHByb2dy ZXNzIHZhcmlvdXMgYXNwZWN0cyBvZiBNUFRDUC4KClRoZSBwcmltYXJ5IGdvYWwgb2YgdGhlIHdv cmtpbmcgZ3JvdXAgaXMgdG8gY3JlYXRlIGEgYmlzIHZlcnNpb24gb2YgdGhlCnByb3RvY29sIGRv Y3VtZW50IG9uIHRoZSBTdGFuZGFyZHMgdHJhY2suIFRoaXMgZGV2ZWxvcHMgdGhlIGN1cnJlbnQK RXhwZXJpbWVudGFsIGRvY3VtZW50IChpdGVtIGQgYWJvdmUpLCBpbmNvcnBvcmF0aW5nIGV4cGVy aWVuY2UgZnJvbSAoZm9yCmV4YW1wbGUpIGltcGxlbWVudGF0aW9ucywgaW50ZXJvcGVyYWJpbGl0 eSBldmVudHMsIGV4cGVyaW1lbnRzLCB1c2FnZQpzY2VuYXJpb3MsIHByb3RvY29sIGNvcm5lciBj YXNlcywgYW5kIGZlZWRiYWNrIGZyb20gVENQTS4gIFRoZXJlIGFscmVhZHkKZXhpc3RzIGEgcmVm ZXJlbmNlIExpbnV4IGltcGxlbWVudGF0aW9uIGFuZCBvdGhlciBpbXBsZW1lbnRhdGlvbiBhbmQK ZXhwZXJpbWVudGFsIGFjdGl2aXR5IGlzIG9uLWdvaW5nIGFuZCB3aWxsIGNvbnRpbnVlIGR1cmlu ZyAyMDEyLCB3aXRoCnRoZSBvYmplY3RpdmUgb2YgcHJvZ3Jlc3NpbmcgdGhlIHByb3RvY29sIHRv IFN0YW5kYXJkcyBUcmFjayBkdXJpbmcKMjAxMy4KClRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZG9j dW1lbnQgaW1wbGVtZW50YXRpb24gYWR2aWNlLiBUaGUgY3VycmVudApkb2N1bWVudHMgaGF2ZSBz ZXZlcmFsIHBvaW50cyB3aGVyZSBhbiBpbXBsZW1lbnRlciBtYXkgYmVuZWZpdCBmcm9tCmd1aWRh bmNlLCBmb3IgZXhhbXBsZSBhYm91dCBoZXVyaXN0aWNzIHN1Y2ggYXMgYnVmZmVyIHNpemluZywg b3IgZnJvbQphZHZpY2UgYWJvdXQgYWx0ZXJuYXRpdmUgaW1wbGVtZW50YXRpb25zIHN1Y2ggYXMg YnVtcC1pbi10aGUtc3RhY2suCgpUaGUgd29ya2luZyBncm91cCB3aWxsIGFsc28gZXhwbG9yZSBh bmQgZG9jdW1lbnQgcmVzdWx0cyB3aXRoIHNldmVyYWwKb2YgdGhlIHByb3Bvc2VkIHVzZSBjYXNl cyBmb3IgTVBUQ1AgaW4gbW9yZSBkZXRhaWwsIHRvIGVuc3VyZSB0aGF0Ck1QVENQIHdvcmtzIHdl bGwgaW4gcHJhY3RpY2UgYW5kIHRoYXQgb3BlcmF0aW9uYWwgZXhwZXJpZW5jZXMgYW5kCmlzc3Vl cyBhcmUgdW5kZXJzdG9vZCBhbmQgY2FwdHVyZWQuICBMaWtlbHkgdXNlIGNhc2VzIGFyZSB0byBv ZmZsb2FkCnRyYWZmaWMgZnJvbSAzRyB0byBXaUZpLCBhbmQgdG8gbWFuYWdlIHRyYWZmaWMgd2l0 aGluIGEgZGF0YSBjZW50cmUuCkFub3RoZXIgc2NlbmFyaW8gaXMgdG8gZW5hYmxlLCB3aXRob3V0 IGNoYW5naW5nIHRoZSBNUFRDUCBwcm90b2NvbCwKb3BlcmF0aW9uIG9mIGEgc2luZ2xlLWhvbWVk LCBNUFRDUCBlbmQgaG9zdCBvbiBhIGNhbXB1cyBuZXR3b3JrIHRoYXQgaGFzCm11bHRpcGxlIHBy b3ZpZGVycy4KCkZpbmFsbHksIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgZXhwbG9yZSB3aGV0aGVy IGFuIE1QVENQLWF3YXJlCm1pZGRsZWJveCB3b3VsZCBiZSB1c2VmdWwsIHdoZXJlIGF0IGxlYXN0 IG9uZSBlbmQgaG9zdCBpcyBNUFRDUC1lbmFibGVkLgpGb3IgZXhhbXBsZSwgcG90ZW50aWFsbHkg aGVscGluZyBNUFRDUMOVcyBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IGJ5CmFsbG93aW5nIG9ubHkg b25lIGVuZCBob3N0IHRvIGJlIE1QVENQLWVuYWJsZWQgYW5kIHRoZSBtaWRkbGVib3ggYWN0cyBh cwphbiBNUFRDUCBwcm94eSBmb3IgdGhlIG90aGVyIGVuZCBob3N0LCB3aGljaCBydW5zIFRDUDsg YW5kIHBvdGVudGlhbGx5CmhlbHBpbmcgc29tZSBtb2JpbGl0eSBzY2VuYXJpb3MsIHdoZXJlIHRo ZSBtaWRkbGVib3ggYWN0cyBhcyBhbiBhbmNob3IKYmV0d2VlbiB0d28gTVBUQ1AtZW5hYmxlZCBo b3N0cy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBkZXRhaWwgd2hhdCByZWFsCnByb2JsZW1zIGFu IE1QVENQLWVuYWJsZWQgbWlkZGxlYm94IG1pZ2h0IHNvbHZlLCBob3cgaXQgd291bGQgaW1wYWN0 IHRoZQpNdWx0aXBhdGggVENQIGFyY2hpdGVjdHVyZSAoUkZDNjE4MiksIHdoYXQgcHJveHkgYXBw cm9hY2ggbWlnaHQgYmUKanVzdGlmaWVkIGFzIGNvbXBhcmVkIGFnYWluc3QgYWx0ZXJuYXRpdmUg c29sdXRpb25zIHRvIHRoZSBwcm9ibGVtcywgYW5kCnRoZSBsaWtlbHkgZmVhc2liaWxpdHkgb2Yg c29sdmluZyB0aGUgdGVjaG5pY2FsIGFuZCBzZWN1cml0eSBpc3N1ZXMuCgpHb2FscyBhbmQgTWls ZXN0b25lczoKCkRlYyAyMDEyICBDb25zZW5zdXMgb24gd2hhdCBoaWdoLWxldmVsIGNoYW5nZXMg YXJlIG5lZWRlZCB0byB0aGUKY3VycmVudCBNUFRDUCBFeHBlcmltZW50YWwgZG9jdW1lbnQgaW4g b3JkZXIgdG8gcHJvZ3Jlc3MgaXQgb24gdGhlCnN0YW5kYXJkcyB0cmFjawoKQXByaWwgMjAxMyAg SW1wbGVtZW50YXRpb24gYWR2aWNlIChJbmZvcm1hdGlvbmFsKSB0byBJRVNHCgpBdWd1c3QgMjAx MyBVc2UgY2FzZXMgKEluZm9ybWF0aW9uYWwpIHRvIElFU0cKCkRlYyAyMDEzIE1QVENQLWVuYWJs ZWQgbWlkZGxlYm94ZXMgKEluZm9ybWF0aW9uYWwpIHRvIElFU0cKCkRlYyAyMDEzICBNUFRDUCBz dGFuZGFyZHMgdHJhY2sgcHJvdG9jb2wgdG8gSUVTRwoKSmFuIDIwMTQgUmUtY2hhcnRlciBvciBj bG9zZQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXct d29yayBtYWlsaW5nIGxpc3QKbmV3LXdvcmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9uZXctd29yawo= From new-work-bounces@ietf.org Tue May 15 11:39:41 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8D621F871A; Tue, 15 May 2012 11:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1337107181; bh=q2sl1vslC1ZpZIdsvl3mRq1rt6krdUbvI0SlSa7Rprw=; h=MIME-Version:From:To:Message-ID:Date:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=SCxfnIDF/zCiCWbttSWF2eJHs1vtUnHofTWQcSWbHVq2qs0/UIuq19om7sp4OBNY8 uRT4NH+8HvSAoTx/PjBB0IOly1fjf3OxhT1piaJ35V0hieiaLJ+Erto0fZQXkE0j92 e78ZBzhgB6ODYLZ8hns90XjaXri6BJJoKV75yTwE= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC721F8772; Tue, 15 May 2012 11:39:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTZ9XGBqMskw; Tue, 15 May 2012 11:39:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0049221F8709; Tue, 15 May 2012 11:39:39 -0700 (PDT) MIME-Version: 1.0 From: IESG Secretary To: new-work@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120515183938.26669.70506.idtracker@ietfa.amsl.com> Date: Tue, 15 May 2012 11:39:38 -0700 X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Tue, 15 May 2012 12:24:09 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Network File System Version 4 (nfsv4) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 18:39:41 -0000 A modified charter has been submitted for the Network File System Version 4 (nfsv4) working group in the Transport Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, May 22, 2012. Network File System Version 4 (nfsv4) ------------------------------------- Current Status: Active Last updated: 2012-05-10 Chairs: Spencer Shepler Brian Pawlowski Transport Area Directors: Wesley Eddy Martin Stiemerling Transport Area Advisor: Martin Stiemerling Tech Advisor: Leif Johansson Mailing Lists: General Discussion: nfsv4@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/nfsv4 Archive: http://www.ietf.org/mail-archive/web/nfsv4/ Description of Working Group: NFS Version 4 is the IETF standard for file sharing. To maintain NFS Version 4's utility and currency, the working group is chartered to maintain the existing NFSv4, NFSv4.1, Federated Namespace, and related specifications. The working group will also consider a new NFSv4 minor version in the form of NFSv4.2 and supporting protocols. Finally, best practices will be formed for deployment for the NFSv4 FedFS implementations and their interaction with integration with new user authentication models. Maintenance The working group has found that as NFSv4 implementations mature and deployments continue, clarifications to existing RFCs are needed. These clarifications assist vendors in delivering quality and interoperable implementations. The working group is chartered with the vetting of the issues and determining correctness of submitted errata. In the case that the needed changes are inappropriate for the errata system, the working group will assist in publication of RFCs that provide either editorial modification to original RFCs or best practices RFCs. The completion of RFC3530bis is the first work item. RFCs expected to generate the most discussion or activity are: RFC 5661, RFC 5662, RFC 5663, and RFC 5664. RFC5664bis The NFSv4.1 Objects Layout needs some additional clarification that is planned for a bis update. The working group will work final issues and deliver an RFC for the clarifications. NFSv4.2 For some time, the working group has been discussing the requirements for the next NFSv4 minor version. A consensus has formed within the working group for an NFSv4.2 that contains the following: - Server Side Copy - Sparse Files - Seek Hole/Data - Space Reservations - Application Data Blocks - Labeled NFS - Simple IO hinting (modeled from posix IO_ADVISE) - Change Attribute Behaviors This is a limited set of functionality that can be effectively documented as an "addition" to the base NFSv4.1 protocol (RFC 5661). Two of the items in this list, Server Side Copy and Labeled NFS, require a new version of the RPCSEC_GSS security abstraction layer. Thus two documents will be developed by the working group. NFSv4 Multi-Domain Access for FedFS As NFSv4 FedFS deployment models are discussed/planned, a significant issue related to conflicting user identification spaces exists. User identification collisions can occur when an NFSv4 server exports non-domain aware POSIX file systems with separate name (NIS/LDAP) services. These collisions can block proper FedFS operation in large corporations or Universities with multiple naming services, or in being a solution to join NFS name spaces in corporate acquisitions or across University domains. To assist in resolving these issues, the working group will deliver three items. First, there are a number of constraints and clarifications to the current NFSv4.0 and NFSv4.1 protocols to fully enable cross domain FedFS. Second, there is a best practices deliverable describing methods to work around the common current situation of non-domain aware POSIX file systems, and in managing naming services to cooperate in resolving remote domain POSIX UIDs and GIDs for remote user file access. Third, we need to track the new work in the GSS-API authentication and authorization space (KRB WG, KITTEN WG, ABFAB WG) to ensure NFS can take advantage of the new features that address cross domain authentication and authorization issues. Goals and Milestones: Done - Issue strawman Internet-Draft for v4 Done - Submit Initial Internet-Draft of requirements document Done - Submit Final Internet-Draft of requirements document Done - AD reassesses WG charter Done - Submit v4 Internet-Draft sufficient to begin prototype implementations Done - Begin Interoperability testing of prototype implementations Done - Submit NFS version 4 to IESG for consideration as a Proposed Standard. Done - Conduct final Interoperability tests Done - Conduct full Interoperability tests for all NFSv4 features Done - Update API advancement draft Done - Form core design team to work on NFS V4 migration/replication requirements and protocol Done - Submit revised NFS Version 4 specification (revision to RFC 3010) to IESG for consideration as a Proposed Standard Done - Strawman NFS V4 replication/migration protocol proposal submitted as an ID Done - WG Last Call for RPC and NFS RDMA drafts Done - WG Last Call for rfc1831bis (RPC version 2) Done - WG Last Call for NFSv4.1 Object-based layout Done - WG Last Call for NFSv4 minor version 1 Done - WG Last Call for NFSv4.1 block/volume layout Done - Submit NFS Minor Version 1 to IESG for publication as a Proposed Standard Done - Submit Object-based pNFS Operations to IESG for publication as a Proposed Standard Done - Submit pNFS Block/Volume Layout to IESG for publication as a Proposed Standard Done - WG Last Call for Requirements for Federated File Systems draft-ietf-nfsv4-federated-fs-reqts-01 Done - WG Last Call for Administration Protocol for Federated Filesystems draft-ietf-nfsv4-federated-fs-admin-00.txt Done - WG Last Call for NSDB Protocol for Federated Filesystems draft-ietf-nfsv4-federated-fs-protocol-00.txt May 2012 Submit RFC3530bis to IESG (Standards Track) May 2012 WG Last Call for Labeled NFS Requirements Jun 2012 Submit Labeled NFS Requirements to IESG (Informational) Jun 2012 Submit RFC5664bis to IESG (Standards Track) Aug 2012 WG Last Call NFSv4.2 Nov 2012 WG last Call for the two Multi-domain Access documents Oct 2012 Submit NFSv4.2 to IESG (Standards Track) Dec 2012 Submit Multi-domain Access documents to IESG (Standards Track) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From hilarie@purplestreak.com Thu May 17 12:58:09 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999C621F87C8; Thu, 17 May 2012 12:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfWG2fVChj7X; Thu, 17 May 2012 12:58:09 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by ietfa.amsl.com (Postfix) with ESMTP id 22EC121F87C7; Thu, 17 May 2012 12:58:09 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1SV6ps-00027j-FC; Thu, 17 May 2012 13:58:08 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=sylvester.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SV6pp-0001jJ-MJ; Thu, 17 May 2012 13:58:08 -0600 Received: from sylvester.rhmr.com (localhost [127.0.0.1]) by sylvester.rhmr.com (8.14.4/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4HJv7Zf023357; Thu, 17 May 2012 13:57:07 -0600 Received: (from hilarie@localhost) by sylvester.rhmr.com (8.14.4/8.14.4/Submit) id q4HJv79J023351; Thu, 17 May 2012 13:57:07 -0600 Date: Thu, 17 May 2012 13:57:07 -0600 Message-Id: <201205171957.q4HJv79J023351@sylvester.rhmr.com> From: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org X-XM-SPF: eid=; ; ; mid=; ; ; hst=mx03.mta.xmission.com; ; ; ip=166.70.57.249; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-DomainKey: sender_domain=purplestreak.com; ; ; sender=hilarie@purplestreak.com; ; ; status=error X-SA-Exim-Connect-IP: 166.70.57.249 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa06 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;iesg@ietf.org, secdir@ietf.org X-Spam-Relay-Country: X-SA-Exim-Version: 4.2.1 (built Fri, 06 Aug 2010 16:31:04 -0600) X-SA-Exim-Scanned: Yes (on mx03.mta.xmission.com) Subject: [secdir] Secdir review: draft-polk-ipr-disclosure-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Hilarie Orman List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 19:58:09 -0000 Security-relate comments re Promoting Compliance with Intellectual Property Rights (IPR) Disclosure Rules Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes strategies for promoting compliance with the IETF's IPR disclosure rules. I tried hard to find a security angle. Perhaps sensitive IPR disclosures could be public-key encoded and placed under a timed release system? Otherwise, I found no security concerns. Hilarie From weiler@watson.org Fri May 18 06:25:32 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A059A21F8650 for ; Fri, 18 May 2012 06:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hy+0fFr9cMrk for ; Fri, 18 May 2012 06:25:32 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 0A06121F8657 for ; Fri, 18 May 2012 06:25:31 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4IDPURY005382 for ; Fri, 18 May 2012 09:25:30 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4IDPUQ2005379 for ; Fri, 18 May 2012 09:25:30 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 18 May 2012 09:25:30 -0400 (EDT) From: Samuel Weiler To: secdir@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 18 May 2012 09:25:30 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 13:25:32 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Nico Williams is next in the rotation. For telechat 2012-05-24 Reviewer LC end Draft Alan DeKok T 2012-04-17 draft-claise-export-application-info-in-ipfix-07 Jeffrey Hutzelman T 2012-04-16 draft-ietf-manet-nhdp-mib-13 Russ Mundy T 2012-05-09 draft-ietf-netext-access-network-option-10 Tim Polk T 2012-03-21 draft-ietf-pwe3-redundancy-bit-07 Eric Rescorla T 2012-05-21 draft-ietf-pkix-cmp-transport-protocols-19 For telechat 2012-06-07 Reviewer LC end Draft Tina TSOU T 2012-05-25 draft-ietf-dccp-udpencap-10 Carl Wallace T 2012-05-30 draft-ietf-mile-iodef-xmlreg-01 Sam Weiler T 2012-05-30 draft-ietf-mile-template-04 Last calls and special requests: Reviewer LC end Draft Matt Lepinski 2012-05-02 draft-ietf-mboned-64-multicast-address-format-01 Magnus Nystrom 2012-05-10 draft-ietf-codec-opus-14 Tim Polk 2012-06-04 draft-farrresnickel-ipr-sanctions-05 Vincent Roca 2012-05-21 draft-ietf-appsawg-media-type-regs-08 Joe Salowey 2012-06-04 draft-kucherawy-marf-source-ports-03 Yaron Sheffer 2012-06-11 draft-camarillo-rai-media-policy-dataset-01 Ondrej Sury 2012-05-31 draft-ietf-dnsext-dnssec-bis-updates-18 Sam Weiler 2012-03-23 draft-sakane-dhc-dhcpv6-kdc-option-14 Brian Weis 2012-05-29 draft-ietf-mpls-ldp-gtsm-06 Klaas Wierenga 2012-05-30 draft-ietf-tcpm-tcpmss-04 Nico Williams - draft-ietf-httpbis-p5-range-19 Tom Yu - draft-ietf-httpbis-p6-cache-19 Glen Zorn - draft-ietf-httpbis-p7-auth-19 From weiler+secdir@watson.org Fri May 18 07:01:05 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F03C21F8650; Fri, 18 May 2012 07:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hQ-+8YyaICmb; Fri, 18 May 2012 07:01:05 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id E939521F864E; Fri, 18 May 2012 07:01:04 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4IE13QC013878; Fri, 18 May 2012 10:01:03 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4IE130H013873; Fri, 18 May 2012 10:01:03 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 18 May 2012 10:01:03 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: draft-ietf-mile-template.all@tools.ietf.org, secdir@ietf.org, iesg@ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Fri, 18 May 2012 10:01:03 -0400 (EDT) Subject: [secdir] secdir review of draft-ietf-mile-template-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 14:01:05 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This doc provides a template for other i-d's describing IODEF extensions. The template reminds authors that they need a security considerations section and cites 3552. The surrounding document has no security considerations of note. I'm fine with the doc moving forward as-is. Minor: The doc title and abstract use "IODEF" without expansion, but I think it's an uncommon enough term that expansion is needed. This doc's security considerations section says: "This document defines a template for extensions to IODEF; the security considerations for IODEF [RFC5070] apply." I might instead say "This document raises no security issues. Extensions defined using the template in Appendix A need to provide an analysis of security issues they may raise. See A.5 for more details." From shanna@juniper.net Fri May 18 15:10:49 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2AB21F85F1; Fri, 18 May 2012 15:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oH4uhsP9CzOK; Fri, 18 May 2012 15:10:49 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 816F321F85ED; Fri, 18 May 2012 15:10:48 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKT7bI5/jbxGJGM/l/+O0I/EVnjsyuF7+l@postini.com; Fri, 18 May 2012 15:10:49 PDT Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 May 2012 15:10:21 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 18 May 2012 18:10:20 -0400 From: Stephen Hanna To: Sam Hartman , "emu@ietf.org" Date: Fri, 18 May 2012 18:10:19 -0400 Thread-Topic: Updated secdir review of draft-ietf-emu-chbind-15.txt Thread-Index: Ac0yBUYMaadU2/1USxesme5e9bVqqQDOFijw Message-ID: References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "secdir@ietf.org" Subject: [secdir] Updated secdir review of draft-ietf-emu-chbind-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 22:10:50 -0000 The changes in draft-ietf-emu-chbind-15.txt satisfactorily address almost all of the comments in my April 13, 2012 secdir review. I do have one remaining substantive comment on this latest draft and two non-substantive ones. Substantive Comment ------------------- The last paragraph of section 9.1 points out a security problem with implementing channel bindings using EAP tunnel methods. If the EAP tunnel method terminates on the authenticator, the channel bindings can easily be defeated by the authenticator. While that's true, nobody terminates the EAP tunnel method on the authenticator today. In the EAP model, the authenticator is not trusted so terminating the EAP tunnel method on the authenticator is a bad idea for many reasons. For example, the authenticator would then have the ability to bypass protected result indications and to bypass all the cryptographic protections provided by the tunnel. Sometimes there is value in having the inner and outer methods terminate on different servers but both servers must be trusted. The authenticator is not. So there is no big security hole here, unless you have already opened an enormous security hole. It's ironic that this document which attempts to close vulnerabilities caused by malicious authenticators ends up subtly suggesting that people open a much larger vulnerability! I would recommend deleting the end of this paragraph, starting with the sentence that starts "Even when cryptographic binding". If you choose to keep this strange text, I suggest that you at least note that terminating an EAP tunnel method on the authenticator is unusual. For example, you could add a parenthetical comment like "(rare)" after the clause "if the outer method tunnel terminates on the authenticator". Non-Substantive Comments ------------------------ In the first paragraph of section 3, an extraneous numeral 3 was somehow added to the end of the second sentence. T. Charles Clancy's address in the Authors' Addresses section now reads: T. Charles Clancy Virginia Tech Virginia Tech Arlington, VA 22203 USA The duplication of Virginia Tech should be removed from this address. I appreciate the hard work of the document editors to address my many earlier comments. I hope that these new comments will also be useful. Thanks, Steve From zhou.sujing@zte.com.cn Fri May 18 18:48:46 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 333CE21F863E; Fri, 18 May 2012 18:48:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oAy2CkJTgyuZ; Fri, 18 May 2012 18:48:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id B40F121F863C; Fri, 18 May 2012 18:48:44 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 286203063883180; Sat, 19 May 2012 09:04:15 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 61163.4283112824; Sat, 19 May 2012 09:48:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q4J1mVee009060; Sat, 19 May 2012 09:48:31 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Stephen Hanna MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Sat, 19 May 2012 09:48:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-05-19 09:48:32, Serialize complete at 2012-05-19 09:48:32 Content-Type: multipart/alternative; boundary="=_alternative 0009F8CB48257A03_=" X-MAIL: mse02.zte.com.cn q4J1mVee009060 X-Mailman-Approved-At: Sat, 19 May 2012 08:07:54 -0700 Cc: emu-bounces@ietf.org, "secdir@ietf.org" , Sam Hartman , "emu@ietf.org" , "ietf@ietf.org" Subject: [secdir] =?gb2312?b?tPC4tDogW0VtdV0gVXBkYXRlZCBzZWNkaXIgcmV2aWV3?= =?gb2312?b?IG9mIGRyYWZ0LWlldGYtZW11LWNoYmluZC0xNS50eHQ=?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 01:48:46 -0000 This is a multipart message in MIME format. --=_alternative 0009F8CB48257A03_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ZW11LWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDEyLTA1LTE5IDA2OjEwOjE5Og0KDQo+IFRoZSBs YXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDkuMSBwb2ludHMgb3V0IGEgc2VjdXJpdHkgcHJvYmxl bQ0KPiB3aXRoIGltcGxlbWVudGluZyBjaGFubmVsIGJpbmRpbmdzIHVzaW5nIEVBUCB0dW5uZWwg bWV0aG9kcy4gSWYNCj4gdGhlIEVBUCB0dW5uZWwgbWV0aG9kIHRlcm1pbmF0ZXMgb24gdGhlIGF1 dGhlbnRpY2F0b3IsIHRoZSBjaGFubmVsDQo+IGJpbmRpbmdzIGNhbiBlYXNpbHkgYmUgZGVmZWF0 ZWQgYnkgdGhlIGF1dGhlbnRpY2F0b3IuIFdoaWxlIHRoYXQncw0KPiB0cnVlLCBub2JvZHkgdGVy bWluYXRlcyB0aGUgRUFQIHR1bm5lbCBtZXRob2Qgb24gdGhlIGF1dGhlbnRpY2F0b3INCj4gdG9k YXkuIEluIHRoZSBFQVAgbW9kZWwsIHRoZSBhdXRoZW50aWNhdG9yIGlzIG5vdCB0cnVzdGVkIHNv DQo+IHRlcm1pbmF0aW5nIHRoZSBFQVAgdHVubmVsIG1ldGhvZCBvbiB0aGUgYXV0aGVudGljYXRv ciBpcyBhIGJhZA0KPiBpZGVhIGZvciBtYW55IHJlYXNvbnMuIEZvciBleGFtcGxlLCB0aGUgYXV0 aGVudGljYXRvciB3b3VsZCB0aGVuDQo+IGhhdmUgdGhlIGFiaWxpdHkgdG8gYnlwYXNzIHByb3Rl Y3RlZCByZXN1bHQgaW5kaWNhdGlvbnMgYW5kIHRvDQo+IGJ5cGFzcyBhbGwgdGhlIGNyeXB0b2dy YXBoaWMgcHJvdGVjdGlvbnMgcHJvdmlkZWQgYnkgdGhlIHR1bm5lbC4NCj4gU29tZXRpbWVzIHRo ZXJlIGlzIHZhbHVlIGluIGhhdmluZyB0aGUgaW5uZXIgYW5kIG91dGVyIG1ldGhvZHMNCj4gdGVy bWluYXRlIG9uIGRpZmZlcmVudCBzZXJ2ZXJzIGJ1dCBib3RoIHNlcnZlcnMgbXVzdCBiZSB0cnVz dGVkLg0KPiBUaGUgYXV0aGVudGljYXRvciBpcyBub3QuIFNvIHRoZXJlIGlzIG5vIGJpZyBzZWN1 cml0eSBob2xlIGhlcmUsDQo+IHVubGVzcyB5b3UgaGF2ZSBhbHJlYWR5IG9wZW5lZCBhbiBlbm9y bW91cyBzZWN1cml0eSBob2xlLiBJdCdzDQo+IGlyb25pYyB0aGF0IHRoaXMgZG9jdW1lbnQgd2hp Y2ggYXR0ZW1wdHMgdG8gY2xvc2UgdnVsbmVyYWJpbGl0aWVzDQo+IGNhdXNlZCBieSBtYWxpY2lv dXMgYXV0aGVudGljYXRvcnMgZW5kcyB1cCBzdWJ0bHkgc3VnZ2VzdGluZyB0aGF0DQo+IHBlb3Bs ZSBvcGVuIGEgbXVjaCBsYXJnZXIgdnVsbmVyYWJpbGl0eSENCj4gDQo+IEkgd291bGQgcmVjb21t ZW5kIGRlbGV0aW5nIHRoZSBlbmQgb2YgdGhpcyBwYXJhZ3JhcGgsIHN0YXJ0aW5nDQo+IHdpdGgg dGhlIHNlbnRlbmNlIHRoYXQgc3RhcnRzICJFdmVuIHdoZW4gY3J5cHRvZ3JhcGhpYyBiaW5kaW5n Ii4NCj4gSWYgeW91IGNob29zZSB0byBrZWVwIHRoaXMgc3RyYW5nZSB0ZXh0LCBJIHN1Z2dlc3Qg dGhhdCB5b3UgYXQNCj4gbGVhc3Qgbm90ZSB0aGF0IHRlcm1pbmF0aW5nIGFuIEVBUCB0dW5uZWwg bWV0aG9kIG9uIHRoZQ0KPiBhdXRoZW50aWNhdG9yIGlzIHVudXN1YWwuIEZvciBleGFtcGxlLCB5 b3UgY291bGQgYWRkIGENCj4gcGFyZW50aGV0aWNhbCBjb21tZW50IGxpa2UgIihyYXJlKSIgYWZ0 ZXIgdGhlIGNsYXVzZSAiaWYgdGhlDQo+IG91dGVyIG1ldGhvZCB0dW5uZWwgdGVybWluYXRlcyBv biB0aGUgYXV0aGVudGljYXRvciIuDQoNCkNhbm4ndCBiZSBtb3JlIGFncmVlLg0KVGhlIGxvZ2lj IGFuZCBnb2FsIG9mIHRoZSBsYXN0IHBhcmFncmFwaCBpcyBzdXNwaWNpb3VzLg0KSXQgZ2l2ZXMg YW4gaW1wcmVzc2lvbiB0aGF0IGNoYW5uZWwgYmluZGluZyBvbiB0dW5uZWwgbWV0aG9kIGlzIA0K bm90IGFwcGxpY2FibGUganVzdCBiZWNhdXNlIHRoZSBzcGVjaWZpYyAocmFyZSkgZXhhbXBsZSAg c2hvd24gaXMgDQpubyBnb29kLg0KV2hhdCBhYm91dCBhIGdvb2QgY3J5cHRvIGJpbmRpbmcgaW4g dHVubmVsIG1ldGhvZD8NCg0KDQo= --=_alternative 0009F8CB48257A03_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5lbXUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTItMDUt MTkgMDY6MTA6MTk6PGJyPg0KPGJyPg0KJmd0OyBUaGUgbGFzdCBwYXJhZ3JhcGggb2Ygc2VjdGlv biA5LjEgcG9pbnRzIG91dCBhIHNlY3VyaXR5IHByb2JsZW08YnI+DQomZ3Q7IHdpdGggaW1wbGVt ZW50aW5nIGNoYW5uZWwgYmluZGluZ3MgdXNpbmcgRUFQIHR1bm5lbCBtZXRob2RzLiBJZjxicj4N CiZndDsgdGhlIEVBUCB0dW5uZWwgbWV0aG9kIHRlcm1pbmF0ZXMgb24gdGhlIGF1dGhlbnRpY2F0 b3IsIHRoZSBjaGFubmVsPGJyPg0KJmd0OyBiaW5kaW5ncyBjYW4gZWFzaWx5IGJlIGRlZmVhdGVk IGJ5IHRoZSBhdXRoZW50aWNhdG9yLiBXaGlsZSB0aGF0J3M8YnI+DQomZ3Q7IHRydWUsIG5vYm9k eSB0ZXJtaW5hdGVzIHRoZSBFQVAgdHVubmVsIG1ldGhvZCBvbiB0aGUgYXV0aGVudGljYXRvcjxi cj4NCiZndDsgdG9kYXkuIEluIHRoZSBFQVAgbW9kZWwsIHRoZSBhdXRoZW50aWNhdG9yIGlzIG5v dCB0cnVzdGVkIHNvPGJyPg0KJmd0OyB0ZXJtaW5hdGluZyB0aGUgRUFQIHR1bm5lbCBtZXRob2Qg b24gdGhlIGF1dGhlbnRpY2F0b3IgaXMgYSBiYWQ8YnI+DQomZ3Q7IGlkZWEgZm9yIG1hbnkgcmVh c29ucy4gRm9yIGV4YW1wbGUsIHRoZSBhdXRoZW50aWNhdG9yIHdvdWxkIHRoZW48YnI+DQomZ3Q7 IGhhdmUgdGhlIGFiaWxpdHkgdG8gYnlwYXNzIHByb3RlY3RlZCByZXN1bHQgaW5kaWNhdGlvbnMg YW5kIHRvPGJyPg0KJmd0OyBieXBhc3MgYWxsIHRoZSBjcnlwdG9ncmFwaGljIHByb3RlY3Rpb25z IHByb3ZpZGVkIGJ5IHRoZSB0dW5uZWwuPGJyPg0KJmd0OyBTb21ldGltZXMgdGhlcmUgaXMgdmFs dWUgaW4gaGF2aW5nIHRoZSBpbm5lciBhbmQgb3V0ZXIgbWV0aG9kczxicj4NCiZndDsgdGVybWlu YXRlIG9uIGRpZmZlcmVudCBzZXJ2ZXJzIGJ1dCBib3RoIHNlcnZlcnMgbXVzdCBiZSB0cnVzdGVk Ljxicj4NCiZndDsgVGhlIGF1dGhlbnRpY2F0b3IgaXMgbm90LiBTbyB0aGVyZSBpcyBubyBiaWcg c2VjdXJpdHkgaG9sZSBoZXJlLDxicj4NCiZndDsgdW5sZXNzIHlvdSBoYXZlIGFscmVhZHkgb3Bl bmVkIGFuIGVub3Jtb3VzIHNlY3VyaXR5IGhvbGUuIEl0J3M8YnI+DQomZ3Q7IGlyb25pYyB0aGF0 IHRoaXMgZG9jdW1lbnQgd2hpY2ggYXR0ZW1wdHMgdG8gY2xvc2UgdnVsbmVyYWJpbGl0aWVzPGJy Pg0KJmd0OyBjYXVzZWQgYnkgbWFsaWNpb3VzIGF1dGhlbnRpY2F0b3JzIGVuZHMgdXAgc3VidGx5 IHN1Z2dlc3RpbmcgdGhhdDxicj4NCiZndDsgcGVvcGxlIG9wZW4gYSBtdWNoIGxhcmdlciB2dWxu ZXJhYmlsaXR5ITxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdvdWxkIHJlY29tbWVuZCBkZWxldGlu ZyB0aGUgZW5kIG9mIHRoaXMgcGFyYWdyYXBoLCBzdGFydGluZzxicj4NCiZndDsgd2l0aCB0aGUg c2VudGVuY2UgdGhhdCBzdGFydHMgJnF1b3Q7RXZlbiB3aGVuIGNyeXB0b2dyYXBoaWMgYmluZGlu ZyZxdW90Oy48YnI+DQomZ3Q7IElmIHlvdSBjaG9vc2UgdG8ga2VlcCB0aGlzIHN0cmFuZ2UgdGV4 dCwgSSBzdWdnZXN0IHRoYXQgeW91IGF0PGJyPg0KJmd0OyBsZWFzdCBub3RlIHRoYXQgdGVybWlu YXRpbmcgYW4gRUFQIHR1bm5lbCBtZXRob2Qgb24gdGhlPGJyPg0KJmd0OyBhdXRoZW50aWNhdG9y IGlzIHVudXN1YWwuIEZvciBleGFtcGxlLCB5b3UgY291bGQgYWRkIGE8YnI+DQomZ3Q7IHBhcmVu dGhldGljYWwgY29tbWVudCBsaWtlICZxdW90OyhyYXJlKSZxdW90OyBhZnRlciB0aGUgY2xhdXNl ICZxdW90O2lmDQp0aGU8YnI+DQomZ3Q7IG91dGVyIG1ldGhvZCB0dW5uZWwgdGVybWluYXRlcyBv biB0aGUgYXV0aGVudGljYXRvciZxdW90Oy48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkNhbm4ndCBiZSBtb3JlIGFncmVlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+VGhlIGxvZ2ljIGFuZCBnb2FsIG9mIHRoZSBsYXN0IHBhcmFncmFwaCBpcyBzdXNw aWNpb3VzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SXQgZ2l2ZXMgYW4gaW1w cmVzc2lvbiB0aGF0IGNoYW5uZWwgYmluZGluZyBvbiB0dW5uZWwNCm1ldGhvZCBpcyA8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPm5vdCBhcHBsaWNhYmxlIGp1c3QgYmVjYXVzZSB0 aGUgc3BlY2lmaWMgKHJhcmUpIGV4YW1wbGUNCiZuYnNwO3Nob3duIGlzIDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+bm8gZ29vZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPldoYXQgYWJvdXQgYSBnb29kIGNyeXB0byBiaW5kaW5nIGluIHR1bm5lbCBtZXRob2Q/ PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo= --=_alternative 0009F8CB48257A03_=-- From hartmans@mit.edu Mon May 21 14:51:13 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 178B621F84D9; Mon, 21 May 2012 14:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5NvhxAskfQy; Mon, 21 May 2012 14:51:12 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7954721F8493; Mon, 21 May 2012 14:51:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [217.28.191.162]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 2982420463; Mon, 21 May 2012 17:51:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E1BC44151; Mon, 21 May 2012 17:50:57 -0400 (EDT) From: Sam Hartman To: Stephen Hanna References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2012 17:50:57 -0400 In-Reply-To: (Stephen Hanna's message of "Fri, 18 May 2012 18:10:19 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "ietf@ietf.org" , Sam Hartman , "emu@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Updated secdir review of draft-ietf-emu-chbind-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 21:51:13 -0000 >>>>> "Stephen" == Stephen Hanna writes: Stephen> The changes in draft-ietf-emu-chbind-15.txt satisfactorily Stephen> address almost all of the comments in my April 13, 2012 Stephen> secdir review. I do have one remaining substantive comment Stephen> on this latest draft and two non-substantive ones. Stephen> Substantive Comment ------------------- Stephen> The last paragraph of section 9.1 points out a security Stephen> problem with implementing channel bindings using EAP tunnel Stephen> methods. If the EAP tunnel method terminates on the Stephen> authenticator, the channel bindings can easily be defeated Stephen> by the authenticator. While that's true, nobody terminates Stephen> the EAP tunnel method on the authenticator today. In the Stephen> EAP model, the authenticator is not trusted so terminating Stephen> the EAP tunnel method on the authenticator is a bad idea Stephen> for many reasons. For example, the authenticator would then Stephen> have the ability to bypass protected result indications and Stephen> to bypass all the cryptographic protections provided by the Stephen> tunnel. Sometimes there is value in having the inner and Stephen> outer methods terminate on different servers but both Stephen> servers must be trusted. The authenticator is not. So Stephen> there is no big security hole here, unless you have already Stephen> opened an enormous security hole. It's ironic that this Stephen> document which attempts to close vulnerabilities caused by Stephen> malicious authenticators ends up subtly suggesting that Stephen> people open a much larger vulnerability! Stephen> I would recommend deleting the end of this paragraph, Stephen> starting with the sentence that starts "Even when Stephen> cryptographic binding".> I disagree very strongly with this proposed change. It's possible that the text is not clear and I'd be happy to work for a round or two to see if we can clarify the text, but ending the paragraph as you propose would defeate the point of text we added after a WG consensus call. I agree with you that authenticators are not trusted. The issue is that you cannot trust attackers to act within a specification. If an attacker can gain benefit from doing something, they may do so. So, if an attacker can create a tunnel terminating at an authenticator and gain advantage from doing so, then they will do so. Remember that we're talking about crypto binding. If crypto binding is relevant for confirming there are no extra servers, then we're in a threat model space where we're trusting the inner method to authenticate the server, not the outer method. You can't say "you should only establish trusted tunnels," because we're hoping that crypto binding will give us that trust. So, the issue here is that once you add channel bindings and the associated changes to the threat model to EAP, an authenticator can gain advantage through convincing a client to trust a tunnel that terminates at an authenticator. That is, an authenticator can mount an attack. Yes, the authenticator needs to convince the peer to trust the extra tunnel. However, as I discuss in draft-hartman-emu-mutual-crypto-binding and in my presentation at last IETF, that's often fairly easy. So, how can we make the text more clear? From carl@redhoundsoftware.com Mon May 21 15:07:02 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197921F84D9 for ; Mon, 21 May 2012 15:07:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPJf+cp4gCuq for ; Mon, 21 May 2012 15:07:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0CCF21F84B2 for ; Mon, 21 May 2012 15:07:01 -0700 (PDT) Received: by qcsq13 with SMTP id q13so4365663qcs.31 for ; Mon, 21 May 2012 15:07:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=user-agent:date:subject:from:to:message-id:thread-topic :mime-version:content-type:content-transfer-encoding :x-gm-message-state; bh=X49TSEUGHc5S58hkZxOJl5qDNV334pHJFXiRgoXnxyQ=; b=ZaUfezva3SOp1hU7fAYuSwURuLz5QOS2CMK76dswlJRcEHAy2aLzD1WArXdUEo9DSL /Mnb73yu1BiyXU0iR4VhmGA35QtWyjn5xojxqpH/YOczy/mspJiEsVdOfLNqYD8sChhi fM9pJkW43hd/ffEa619FptrXSRbQnVUp7Qm2tietZnGantpgawtQ1udYZFhIjes1HLxH /ADi24eBMVV2u3YhAjH7m+p+edX+2QDBK3tD6prh0D0+yX0OqGXcT5Djp698cR5vlrdq OxD6MDOEuQIUnpRHoBbG4JVRqsXpKlgRR3MAcJXakgNRU5vAL5+FmTghpicU7VjDrf4k pyKw== Received: by 10.229.135.211 with SMTP id o19mr8596705qct.3.1337638021241; Mon, 21 May 2012 15:07:01 -0700 (PDT) Received: from [192.168.1.6] (pool-71-127-46-3.washdc.east.verizon.net. [71.127.46.3]) by mx.google.com with ESMTPS id s20sm41425492qap.16.2012.05.21.15.06.57 (version=SSLv3 cipher=OTHER); Mon, 21 May 2012 15:06:59 -0700 (PDT) User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 21 May 2012 18:06:49 -0400 From: Carl Wallace To: , , Message-ID: Thread-Topic: secdir review of draft-ietf-mile-iodef-xmlreg-01 Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Gm-Message-State: ALoCoQlzZJhyIIaRBRbqDNVu+scKoK0fPpkMT/HK+GIpYi0qK/u81PZLN0aqaxY/vKqQZFtNYclC Subject: [secdir] secdir review of draft-ietf-mile-iodef-xmlreg-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:07:02 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies restrictions on additions to the subset of the IANA XML Namespace and Schema registries, to require Expert Review for extensions to IODEF. I see no issues with this one pager. From shanna@juniper.net Tue May 22 13:03:55 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B589421F869E; Tue, 22 May 2012 13:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.252 X-Spam-Level: X-Spam-Status: No, score=-105.252 tagged_above=-999 required=5 tests=[AWL=1.347, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkDmDKxL08d2; Tue, 22 May 2012 13:03:55 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 44F0D21F86A3; Tue, 22 May 2012 13:03:52 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKT7vxJ+TDYVW/wC+63FzmvM056h/Z6qAp@postini.com; Tue, 22 May 2012 13:03:53 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 22 May 2012 13:00:21 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Tue, 22 May 2012 16:00:20 -0400 From: Stephen Hanna To: Sam Hartman Date: Tue, 22 May 2012 16:00:19 -0400 Thread-Topic: Updated secdir review of draft-ietf-emu-chbind-15.txt Thread-Index: Ac03m9Vz0ExW5KUcShO4ogGhcZvyUgAAFxvw Message-ID: References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Updated secdir review of draft-ietf-emu-chbind-15.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 20:03:56 -0000 Sam, I see now that you are concerned not with circumstances where the NAS terminates the tunnel by design but rather with times when the NAS is maliciously terminating the tunnel. I'm glad that we both agree that having the NAS terminate the tunnel is highly undesirable. That did not come through in the draft. I'm much relieved to learn that nobody is suggesting this as a desirable outcome. I agree that it's an attack scenario that must be considered and carefully addressed. Maybe we can resolve this issue by clarifying the text to say more clearly that we're dealing with an attack scenario here. For example, we could add a sentence before the words "Tunnel methods sometimes use" saying something like "However, this is not secure if the NAS can terminate the tunnel (a highly undesirable situation)." Then you can mention several countermeasures against such an attack: mutual cryptographic bindings (still just a -00 individual draft), carefully checking the EAP server's identity, etc. We might also take this opportunity to split this long paragraph into two: one that includes the first three sentences (describing how EAP tunnel methods can support channel binding) and another describing the attack scenario and countermeasures. Thanks, Steve > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > Sent: Monday, May 21, 2012 5:51 PM > To: Stephen Hanna > Cc: Sam Hartman; emu@ietf.org; secdir@ietf.org; ietf@ietf.org > Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt > Importance: High >=20 > >>>>> "Stephen" =3D=3D Stephen Hanna writes: >=20 > Stephen> The changes in draft-ietf-emu-chbind-15.txt satisfactorily > Stephen> address almost all of the comments in my April 13, 2012 > Stephen> secdir review. I do have one remaining substantive comment > Stephen> on this latest draft and two non-substantive ones. >=20 > Stephen> Substantive Comment ------------------- >=20 > Stephen> The last paragraph of section 9.1 points out a security > Stephen> problem with implementing channel bindings using EAP > tunnel > Stephen> methods. If the EAP tunnel method terminates on the > Stephen> authenticator, the channel bindings can easily be defeated > Stephen> by the authenticator. While that's true, nobody terminates > Stephen> the EAP tunnel method on the authenticator today. In the > Stephen> EAP model, the authenticator is not trusted so terminating > Stephen> the EAP tunnel method on the authenticator is a bad idea > Stephen> for many reasons. For example, the authenticator would > then > Stephen> have the ability to bypass protected result indications > and > Stephen> to bypass all the cryptographic protections provided by > the > Stephen> tunnel. Sometimes there is value in having the inner and > Stephen> outer methods terminate on different servers but both > Stephen> servers must be trusted. The authenticator is not. So > Stephen> there is no big security hole here, unless you have > already > Stephen> opened an enormous security hole. It's ironic that this > Stephen> document which attempts to close vulnerabilities caused by > Stephen> malicious authenticators ends up subtly suggesting that > Stephen> people open a much larger vulnerability! >=20 > Stephen> I would recommend deleting the end of this paragraph, > Stephen> starting with the sentence that starts "Even when > Stephen> cryptographic binding".> >=20 > I disagree very strongly with this proposed change. It's possible that > the text is not clear and I'd be happy to work for a round or two to > see > if we can clarify the text, but ending the paragraph as you propose > would defeate the point of text we added after a WG consensus call. >=20 > I agree with you that authenticators are not trusted. > The issue is that you cannot trust attackers to act within a > specification. > If an attacker can gain benefit from doing something, they may do so. >=20 > So, if an attacker can create a tunnel terminating at an authenticator > and gain advantage from doing so, then they will do so. >=20 > Remember that we're talking about crypto binding. If crypto binding is > relevant for confirming there are no extra servers, then we're in a > threat model space where we're trusting the inner method to > authenticate > the server, not the outer method. You can't say "you should only > establish trusted tunnels," because we're hoping that crypto binding > will give us that trust. So, the issue here is that once you add > channel bindings and the associated changes to the threat model to EAP, > an authenticator can gain advantage through convincing a client to > trust > a tunnel that terminates at an authenticator. That is, an > authenticator > can mount an attack. Yes, the authenticator needs to convince the peer > to trust the extra tunnel. However, as I discuss in > draft-hartman-emu-mutual-crypto-binding and in my presentation at last > IETF, that's often fairly easy. >=20 > So, how can we make the text more clear? From Tina.Tsou.Zouting@huawei.com Wed May 23 14:26:34 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8DC11E80C6; Wed, 23 May 2012 14:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.065 X-Spam-Level: X-Spam-Status: No, score=-6.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLsx1nSH9M6a; Wed, 23 May 2012 14:26:33 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07C11E80C5; Wed, 23 May 2012 14:26:33 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AGL92102; Wed, 23 May 2012 17:26:33 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 23 May 2012 14:24:44 -0700 Received: from dfweml513-mbx.china.huawei.com ([169.254.3.80]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Wed, 23 May 2012 14:24:47 -0700 From: Tina TSOU To: "secdir@ietf.org" Thread-Topic: SecDir review of draft-ietf-dccp-udpencap-10 Thread-Index: Ac05Knod2pQ4T3OTQOuds2kZi2JLeA== Date: Wed, 23 May 2012 21:24:46 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-ietf-dccp-udpencap@tools.ietf.org" , The IESG Subject: [secdir] SecDir review of draft-ietf-dccp-udpencap-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 21:26:34 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. I find one case which can be a small disadvantage: both sides have to be up= dated to use tunneling, even if only one side is blocked by NAT. Can we han= dle this case? Tina Sent from my IPv6 address 2001:0:4137:9e76:20f1:518:f56e:f6a5 From new-work-bounces@ietf.org Wed May 23 15:05:37 2012 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DBA11E80B3; Wed, 23 May 2012 15:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1337810737; bh=jpRmA4oBtJbK7vM+AheweFjDMcIIvTbvsr1qBsEhSR0=; h=From:Date:To:Message-Id:Mime-Version:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=tw3V0lkh0GvweBYpm8kSuuDcpgZJnBt3yV4U+SPMvS8vTBmWzKxZzsh5gjwCJNev8 phC6b6QDrTV1hvdoHgScs9ojJyBfkj/v1oKr5w26eJMlcFWZaakUAsNq7BJ19Wi4Of 4tORJSc8gESv7Os97LHP0rk/l/hb5NyAk0sqbz5Y= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA2E011E80B3 for ; Wed, 23 May 2012 15:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmxDO8ZrdLQR for ; Wed, 23 May 2012 15:05:36 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by ietfa.amsl.com (Postfix) with ESMTP id 5644B11E8098 for ; Wed, 23 May 2012 15:05:36 -0700 (PDT) Received: from localhost ([127.0.0.1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1SXJgV-0003Yd-36; Wed, 23 May 2012 18:05:35 -0400 From: Ian Jacobs Date: Wed, 23 May 2012 17:05:33 -0500 To: new-work@ietf.org Message-Id: <2EC27948-FD17-4C43-91DB-11CB465B4F98@w3.org> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Wed, 23 May 2012 15:10:30 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: XML Processing Model Working Group (until 2012-06-24) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:05:37 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the XML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the XML Processing Model Working Group: http://www.w3.org/XML/2012/05/xproc-charter As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2012-06-24 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [2], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Liam Quin, XML Activity Lead . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/XML/ [1] http://www.w3.org/2005/10/Process-20051014/activities#ActivityCreation [2] http://www.w3.org/Consortium/Member/List -- Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs/ Tel: +1 718 260 9447 _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From weiler+secdir@watson.org Wed May 23 16:12:20 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F69411E8072; Wed, 23 May 2012 16:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ouNN4g+fyEJk; Wed, 23 May 2012 16:12:19 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 897D121F8603; Wed, 23 May 2012 16:12:19 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4NNCItk072501; Wed, 23 May 2012 19:12:18 -0400 (EDT) (envelope-from weiler+secdir@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4NNCHjx072494; Wed, 23 May 2012 19:12:17 -0400 (EDT) (envelope-from weiler+secdir@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 23 May 2012 19:12:17 -0400 (EDT) From: Samuel Weiler X-X-Sender: weiler@fledge.watson.org To: secdir@ietf.org, ietf@ietf.org, draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Wed, 23 May 2012 19:12:18 -0400 (EDT) Subject: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:12:20 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This doc specifies several DHCPv6 options for carrying Kerberos config info. There are obvious risks to doing this, but they're discussed reasonably well in this and similar cited docs (e.g. RFC3634, which specifies a much more limited option for DHCPv4). The doc explains by DNS service discovery isn't ideal for some environments. With that said, there are some things that need clarification, and the doc sorely needs an editorial pass. As-is, the doc is not ready for publication. I will be happy to review the doc again once it's been thoroughly edited. Things that need clarification or consideration: For the transport type field, would it be better to use a bitmask? Then one could use a single DHCPv6 option to specify a KDC that's reachable over both TCP and UDP, rather than needing two DHCPv6 options. Section 7 uses the term "TGT" without expansion. In the Kerberos world I can't imagine someone not knowing what this is, but it's not clear to the layman. It probably needs to be expanded. The algorithm in section 4.1 needs work. The obvious thing is to read it linearly. Doing that, one would prefer DHCP over DNS SVR info (per step 2), which is not what step 6 and the graphic say. Saying "no answer from the DNS server" is probably not the desired semantic. In 3.4, the option-len field is ambiguous. It says "24-octet + the length of the realm-name field in octets." But it looks to me like this option is 27 octets + length of realm name. Perhaps it would be better to just count the length of the realm name? And here are some examples of wording that needs work. There are many more -- I quit copying them into this review after the first few: 3.2 "This option informs a DHCPv6 server of which realm the client want to access, ..." 7 "... a rogue KDC that does not know the client access." What is "the client access"? "The incorrect KDC is not be able to proceed any further state of the client." "The considerable situation is that the support of an unconfigured workstation used by multiple users, which obtains its KDC information and default realm via DHCP." From shanna@juniper.net Thu May 24 06:10:03 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC28121F852A; Thu, 24 May 2012 06:10:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.701 X-Spam-Level: X-Spam-Status: No, score=-105.701 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toA1ntr12YBi; Thu, 24 May 2012 06:10:03 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 6AF3B21F8523; Thu, 24 May 2012 06:10:01 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKT74zKPRnXvty282Gmexf/Q9g1Y89DavE@postini.com; Thu, 24 May 2012 06:10:02 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 24 May 2012 06:07:35 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Thu, 24 May 2012 09:07:35 -0400 From: Stephen Hanna To: Sam Hartman Date: Thu, 24 May 2012 09:07:33 -0400 Thread-Topic: Updated secdir review of draft-ietf-emu-chbind-16.txt Thread-Index: Ac03m9Vz0ExW5KUcShO4ogGhcZvyUgAAFxvwAIQuNxA= Message-ID: References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ietf@ietf.org" , "emu@ietf.org" , "secdir@ietf.org" Subject: [secdir] Updated secdir review of draft-ietf-emu-chbind-16.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:10:04 -0000 Sam, Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt. I'm happy with this version. All my substantive concerns are addressed. I do see two non-substantive issues. These can be addressed in some future version or not at all. 1) The word "subvert" is misspelled as "subvirt" in the new text. 2) Editing Charles Clancy's address in the Authors' Addresses section has apparently caused the list of authors in the top right corner of the first page to revert to this suboptimal form: EMU Working Group S. Hartman, Ed. Internet-Draft Painless Security Intended status: Standards Track T. Clancy Expires: November 25, 2012 Department of Electrical Engineering and Computer Science K. Hoeper Motorola Solutions, Inc. As you can see, Dr. Clancy's affiliation has now changed back to "Department of Electrical Engineering and Computer Science". I guess that whatever tool you're using to create the draft must insist on placing the second line of each author's address on the first page. If that's the case, you might want to change Dr. Clancy's address to T. Charles Clancy Virginia Tech Department of Electrical Engineering and Computer Science Arlington, VA 22203 USA Or perhaps you'll just have to surrender to the flawed tool and leave the credit for Dr. Clancy on the first page as nonsensical. Thanks for your patience in addressing the issues that I raised. I think the document is much better for this attention. Take care, Steve > -----Original Message----- > From: Stephen Hanna > Sent: Tuesday, May 22, 2012 4:00 PM > To: 'Sam Hartman' > Cc: emu@ietf.org; secdir@ietf.org; ietf@ietf.org > Subject: RE: Updated secdir review of draft-ietf-emu-chbind-15.txt >=20 > Sam, >=20 > I see now that you are concerned not with circumstances where > the NAS terminates the tunnel by design but rather with times > when the NAS is maliciously terminating the tunnel. I'm glad > that we both agree that having the NAS terminate the tunnel > is highly undesirable. That did not come through in the draft. > I'm much relieved to learn that nobody is suggesting this > as a desirable outcome. I agree that it's an attack scenario > that must be considered and carefully addressed. >=20 > Maybe we can resolve this issue by clarifying the text to > say more clearly that we're dealing with an attack scenario > here. For example, we could add a sentence before the words > "Tunnel methods sometimes use" saying something like "However, > this is not secure if the NAS can terminate the tunnel (a > highly undesirable situation)." Then you can mention several > countermeasures against such an attack: mutual cryptographic > bindings (still just a -00 individual draft), carefully > checking the EAP server's identity, etc. We might also take > this opportunity to split this long paragraph into two: > one that includes the first three sentences (describing how > EAP tunnel methods can support channel binding) and another > describing the attack scenario and countermeasures. >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: Sam Hartman [mailto:hartmans-ietf@mit.edu] > > Sent: Monday, May 21, 2012 5:51 PM > > To: Stephen Hanna > > Cc: Sam Hartman; emu@ietf.org; secdir@ietf.org; ietf@ietf.org > > Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt > > Importance: High > > > > >>>>> "Stephen" =3D=3D Stephen Hanna writes: > > > > Stephen> The changes in draft-ietf-emu-chbind-15.txt > satisfactorily > > Stephen> address almost all of the comments in my April 13, 2012 > > Stephen> secdir review. I do have one remaining substantive > comment > > Stephen> on this latest draft and two non-substantive ones. > > > > Stephen> Substantive Comment ------------------- > > > > Stephen> The last paragraph of section 9.1 points out a security > > Stephen> problem with implementing channel bindings using EAP > > tunnel > > Stephen> methods. If the EAP tunnel method terminates on the > > Stephen> authenticator, the channel bindings can easily be > defeated > > Stephen> by the authenticator. While that's true, nobody > terminates > > Stephen> the EAP tunnel method on the authenticator today. In the > > Stephen> EAP model, the authenticator is not trusted so > terminating > > Stephen> the EAP tunnel method on the authenticator is a bad idea > > Stephen> for many reasons. For example, the authenticator would > > then > > Stephen> have the ability to bypass protected result indications > > and > > Stephen> to bypass all the cryptographic protections provided by > > the > > Stephen> tunnel. Sometimes there is value in having the inner > and > > Stephen> outer methods terminate on different servers but both > > Stephen> servers must be trusted. The authenticator is not. So > > Stephen> there is no big security hole here, unless you have > > already > > Stephen> opened an enormous security hole. It's ironic that this > > Stephen> document which attempts to close vulnerabilities caused > by > > Stephen> malicious authenticators ends up subtly suggesting that > > Stephen> people open a much larger vulnerability! > > > > Stephen> I would recommend deleting the end of this paragraph, > > Stephen> starting with the sentence that starts "Even when > > Stephen> cryptographic binding".> > > > > I disagree very strongly with this proposed change. It's possible > that > > the text is not clear and I'd be happy to work for a round or two to > > see > > if we can clarify the text, but ending the paragraph as you propose > > would defeate the point of text we added after a WG consensus call. > > > > I agree with you that authenticators are not trusted. > > The issue is that you cannot trust attackers to act within a > > specification. > > If an attacker can gain benefit from doing something, they may do so. > > > > So, if an attacker can create a tunnel terminating at an > authenticator > > and gain advantage from doing so, then they will do so. > > > > Remember that we're talking about crypto binding. If crypto binding > is > > relevant for confirming there are no extra servers, then we're in a > > threat model space where we're trusting the inner method to > > authenticate > > the server, not the outer method. You can't say "you should only > > establish trusted tunnels," because we're hoping that crypto binding > > will give us that trust. So, the issue here is that once you add > > channel bindings and the associated changes to the threat model to > EAP, > > an authenticator can gain advantage through convincing a client to > > trust > > a tunnel that terminates at an authenticator. That is, an > > authenticator > > can mount an attack. Yes, the authenticator needs to convince the > peer > > to trust the extra tunnel. However, as I discuss in > > draft-hartman-emu-mutual-crypto-binding and in my presentation at > last > > IETF, that's often fairly easy. > > > > So, how can we make the text more clear? From jhutz@cmu.edu Thu May 24 10:50:41 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7621F8595; Thu, 24 May 2012 10:50:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2IiD-2Ivl0cG; Thu, 24 May 2012 10:50:40 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by ietfa.amsl.com (Postfix) with ESMTP id 7A9FC21F847D; Thu, 24 May 2012 10:50:40 -0700 (PDT) Received: from [128.2.210.96] (destiny.pc.cs.cmu.edu [128.2.210.96]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id q4OHoc3l014311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 24 May 2012 13:50:38 -0400 (EDT) From: Jeffrey Hutzelman To: Samuel Weiler In-Reply-To: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org> References: <21762_1337814743_q4NNCMPh008981_alpine.BSF.2.00.1205231837020.9762@fledge.watson.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 24 May 2012 13:50:37 -0400 Message-ID: <1337881837.3279.45.camel@destiny.pc.cs.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: draft-sakane-dhc-dhcpv6-kdc-option@tools.ietf.org, secdir@ietf.org, ietf@ietf.org, jhutz@cmu.edu Subject: Re: [secdir] secdir review of draft-sakane-dhc-dhcpv6-kdc-option X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 17:50:41 -0000 On Wed, 2012-05-23 at 19:12 -0400, Samuel Weiler wrote: > With that said, there are some things that need clarification, and the > doc sorely needs an editorial pass. As-is, the doc is not ready for > publication. I will be happy to review the doc again once it's been > thoroughly edited. It does need copy-editing. As far as I know, the IETF does not have a team of volunteer copy-editors, and multiple attempts to get help from within the working group have met with only limited success (most notably in the form of help from Stephen, who did quite a bit of work on this before starting on his AD review). If anyone wants to volunteer to spend some time on helping to clean up this document, let me know. Otherwise, I think our only options are either to ask the paid editors at the RFC production center to take a stab, or block an otherwise completed document on cycles that may never appear. > Section 7 uses the term "TGT" without expansion. In the Kerberos > world I can't imagine someone not knowing what this is, but it's not > clear to the layman. It probably needs to be expanded. It does; I somehow missed that in my review. > The algorithm in section 4.1 needs work. The obvious thing is to read > it linearly. Doing that, one would prefer DHCP over DNS SVR info (per > step 2), which is not what step 6 and the graphic say. The algorithm is fine, but the description requires careful reading. Step 2 kicks in only if you get a DHCP response containing Kerberos configuration but no nameservers. > Saying "no answer from the DNS server" is probably not the desired > semantic. There are only two branches here. Either you get a response containing one or more relevant SRV RRs, or you don't. The latter is phrased as "no answer from the DNS server", but is meant to also include errors and empty responses. A suggestion for how to word this better would be welcome. > In 3.4, the option-len field is ambiguous. It says "24-octet + the > length of the realm-name field in octets." But it looks to me like > this option is 27 octets + length of realm name. Perhaps it would be > better to just count the length of the realm name? Yes, the description is wrong; the correct length is _23_ plus the length of the realm. The 16-bit option code and length are part of the DHCPv6 protocol; unless I'm misremembering, the length is the length of the option payload (that is, excluding the two header fields). Thanks for taking the time to review this. -- Jeff From turners@ieca.com Fri May 25 05:57:43 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6538521F8687 for ; Fri, 25 May 2012 05:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S+DpFsfy5CW for ; Fri, 25 May 2012 05:57:42 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.179.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5624221F8686 for ; Fri, 25 May 2012 05:57:42 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id CA92F6AD52CCB; Fri, 25 May 2012 07:57:41 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id BCA7E6AD52CAA for ; Fri, 25 May 2012 07:57:41 -0500 (CDT) Received: from [96.231.123.235] (port=35380 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SXu5M-0005cW-TS; Fri, 25 May 2012 07:57:41 -0500 Message-ID: <4FBF81C4.7050503@ieca.com> Date: Fri, 25 May 2012 08:57:40 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Stephen Hanna References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.123.235]:35380 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "secdir@ietf.org" , Sam Hartman , "ietf@ietf.org" , "emu@ietf.org" Subject: Re: [secdir] [Emu] Updated secdir review of draft-ietf-emu-chbind-16.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 12:57:43 -0000 Steve/Sam, I've gone ahead and entered fixes for these two as RFC editor notes to ensure we won't forget them. Thanks for working through this! spt On 5/24/12 9:07 AM, Stephen Hanna wrote: > Sam, > > Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt. > I'm happy with this version. All my substantive concerns are addressed. > > I do see two non-substantive issues. These can be addressed in some > future version or not at all. > > 1) The word "subvert" is misspelled as "subvirt" in the new text. > > 2) Editing Charles Clancy's address in the Authors' Addresses section > has apparently caused the list of authors in the top right corner of > the first page to revert to this suboptimal form: > > EMU Working Group S. Hartman, Ed. > Internet-Draft Painless Security > Intended status: Standards Track T. Clancy > Expires: November 25, 2012 Department of Electrical > Engineering and Computer Science > K. Hoeper > Motorola Solutions, Inc. > > As you can see, Dr. Clancy's affiliation has now changed back to > "Department of Electrical Engineering and Computer Science". I guess > that whatever tool you're using to create the draft must insist on > placing the second line of each author's address on the first page. > If that's the case, you might want to change Dr. Clancy's address to > > T. Charles Clancy > Virginia Tech > Department of Electrical Engineering and Computer Science > Arlington, VA 22203 > USA > > Or perhaps you'll just have to surrender to the flawed tool and > leave the credit for Dr. Clancy on the first page as nonsensical. > > Thanks for your patience in addressing the issues that I raised. > I think the document is much better for this attention. > > Take care, > > Steve > >> -----Original Message----- >> From: Stephen Hanna >> Sent: Tuesday, May 22, 2012 4:00 PM >> To: 'Sam Hartman' >> Cc: emu@ietf.org; secdir@ietf.org; ietf@ietf.org >> Subject: RE: Updated secdir review of draft-ietf-emu-chbind-15.txt >> >> Sam, >> >> I see now that you are concerned not with circumstances where >> the NAS terminates the tunnel by design but rather with times >> when the NAS is maliciously terminating the tunnel. I'm glad >> that we both agree that having the NAS terminate the tunnel >> is highly undesirable. That did not come through in the draft. >> I'm much relieved to learn that nobody is suggesting this >> as a desirable outcome. I agree that it's an attack scenario >> that must be considered and carefully addressed. >> >> Maybe we can resolve this issue by clarifying the text to >> say more clearly that we're dealing with an attack scenario >> here. For example, we could add a sentence before the words >> "Tunnel methods sometimes use" saying something like "However, >> this is not secure if the NAS can terminate the tunnel (a >> highly undesirable situation)." Then you can mention several >> countermeasures against such an attack: mutual cryptographic >> bindings (still just a -00 individual draft), carefully >> checking the EAP server's identity, etc. We might also take >> this opportunity to split this long paragraph into two: >> one that includes the first three sentences (describing how >> EAP tunnel methods can support channel binding) and another >> describing the attack scenario and countermeasures. >> >> Thanks, >> >> Steve >> >>> -----Original Message----- >>> From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >>> Sent: Monday, May 21, 2012 5:51 PM >>> To: Stephen Hanna >>> Cc: Sam Hartman; emu@ietf.org; secdir@ietf.org; ietf@ietf.org >>> Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt >>> Importance: High >>> >>>>>>>> "Stephen" == Stephen Hanna writes: >>> >>> Stephen> The changes in draft-ietf-emu-chbind-15.txt >> satisfactorily >>> Stephen> address almost all of the comments in my April 13, 2012 >>> Stephen> secdir review. I do have one remaining substantive >> comment >>> Stephen> on this latest draft and two non-substantive ones. >>> >>> Stephen> Substantive Comment ------------------- >>> >>> Stephen> The last paragraph of section 9.1 points out a security >>> Stephen> problem with implementing channel bindings using EAP >>> tunnel >>> Stephen> methods. If the EAP tunnel method terminates on the >>> Stephen> authenticator, the channel bindings can easily be >> defeated >>> Stephen> by the authenticator. While that's true, nobody >> terminates >>> Stephen> the EAP tunnel method on the authenticator today. In the >>> Stephen> EAP model, the authenticator is not trusted so >> terminating >>> Stephen> the EAP tunnel method on the authenticator is a bad idea >>> Stephen> for many reasons. For example, the authenticator would >>> then >>> Stephen> have the ability to bypass protected result indications >>> and >>> Stephen> to bypass all the cryptographic protections provided by >>> the >>> Stephen> tunnel. Sometimes there is value in having the inner >> and >>> Stephen> outer methods terminate on different servers but both >>> Stephen> servers must be trusted. The authenticator is not. So >>> Stephen> there is no big security hole here, unless you have >>> already >>> Stephen> opened an enormous security hole. It's ironic that this >>> Stephen> document which attempts to close vulnerabilities caused >> by >>> Stephen> malicious authenticators ends up subtly suggesting that >>> Stephen> people open a much larger vulnerability! >>> >>> Stephen> I would recommend deleting the end of this paragraph, >>> Stephen> starting with the sentence that starts "Even when >>> Stephen> cryptographic binding".> >>> >>> I disagree very strongly with this proposed change. It's possible >> that >>> the text is not clear and I'd be happy to work for a round or two to >>> see >>> if we can clarify the text, but ending the paragraph as you propose >>> would defeate the point of text we added after a WG consensus call. >>> >>> I agree with you that authenticators are not trusted. >>> The issue is that you cannot trust attackers to act within a >>> specification. >>> If an attacker can gain benefit from doing something, they may do so. >>> >>> So, if an attacker can create a tunnel terminating at an >> authenticator >>> and gain advantage from doing so, then they will do so. >>> >>> Remember that we're talking about crypto binding. If crypto binding >> is >>> relevant for confirming there are no extra servers, then we're in a >>> threat model space where we're trusting the inner method to >>> authenticate >>> the server, not the outer method. You can't say "you should only >>> establish trusted tunnels," because we're hoping that crypto binding >>> will give us that trust. So, the issue here is that once you add >>> channel bindings and the associated changes to the threat model to >> EAP, >>> an authenticator can gain advantage through convincing a client to >>> trust >>> a tunnel that terminates at an authenticator. That is, an >>> authenticator >>> can mount an attack. Yes, the authenticator needs to convince the >> peer >>> to trust the extra tunnel. However, as I discuss in >>> draft-hartman-emu-mutual-crypto-binding and in my presentation at >> last >>> IETF, that's often fairly easy. >>> >>> So, how can we make the text more clear? > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > From yaronf.ietf@gmail.com Fri May 25 09:08:07 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F300E21F8744; Fri, 25 May 2012 09:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.01 X-Spam-Level: X-Spam-Status: No, score=-103.01 tagged_above=-999 required=5 tests=[AWL=0.589, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HQtzEzvwZFqB; Fri, 25 May 2012 09:08:06 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0682D21F873E; Fri, 25 May 2012 09:08:05 -0700 (PDT) Received: by bkty8 with SMTP id y8so1057214bkt.31 for ; Fri, 25 May 2012 09:08:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=dldxR/kvpHWc3gBRkhx8boZHdiIfn4xK2GhG3E2da0I=; b=UpgDH9IKq7MajkMLMFlH8LOexzZPOxHwAilpV+DI3Krm+E1QCEv8VGI9ZIodhrgtOW N78UmAyK8shtkPFCiRr9Zd8zvzPfFjagr7qu6t0LxG3zzI1T2AAYZbn2Ss2hBfBabc5C +TNCU3apGQMyrAw1R0zCKenTn60/2U5HrRsz7H7V+/+FuF7PYEbGCHPIywoSJXp0O8dZ Tc/vGSSa5kPrt8K+PXbdHLA74akAMMyRArKLN3cL9iTXpiahdFGOuQfb3GEKa0DH8NSP T5sc3mTQW3Dhfub+TJ7pB/DKEyc9BGHHkrtnt24F4LDOV+gozCfgLBKc0oanCdReI2ho 1+2w== Received: by 10.204.156.24 with SMTP id u24mr1572621bkw.75.1337962085045; Fri, 25 May 2012 09:08:05 -0700 (PDT) Received: from [10.0.0.3] ([109.64.171.110]) by mx.google.com with ESMTPS id 9sm7002559bku.9.2012.05.25.09.08.02 (version=SSLv3 cipher=OTHER); Fri, 25 May 2012 09:08:03 -0700 (PDT) Message-ID: <4FBFAE5F.8010305@gmail.com> Date: Fri, 25 May 2012 19:07:59 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: secdir@ietf.org, draft-camarillo-rai-media-policy-dataset.all@tools.ietf.org, iesg@ietf.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [secdir] SecDir review of draft-camarillo-rai-media-policy-dataset-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:08:07 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary Nothing much here - this is not where the security action is. However a companion document may need some deeper security review. Details This draft defines the contents/format of a media document. The document allows a SIP policy server to dictate the media policy that should be implemented by a UA, in general or on a per-session basis. • The draft requires that all documents be well-formed and valid XML, which is good - not only for security. • The real security stuff is in draft-ietf-sipping-policy-package-08. I will not review that document here, but I find it puzzling that session (media) information is transmitted/secured along with session encryption keys. Mixing together data of such disparate security sensitivity levels is likely to result in either over-engineering or under-security. • Reading further down the said security considerations, this issue is addressed ("the user agent should not insert" etc.), but none of that discussion is normative! • Moreover, recent discussion on SAAG (http://www.ietf.org/mail-archive/web/saag/current/msg03695.html) suggests that some of the security solutions mandated by the Policy Package draft as well as the current draft are, to put it mildly, not widely implemented. • Back to the current document. Re: XML security considerations, please reference the security considerations of RFC 3470, and possibly also: Marsh, J., Orchard, D., and D. Veillard, "XML Inclusions (XInclude) Version 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xinclude-20061115, November 2006, . Thanks, Yaron From klaas@cisco.com Wed May 30 08:05:25 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A0E21F8672; Wed, 30 May 2012 08:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.243 X-Spam-Level: X-Spam-Status: No, score=-10.243 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BAoPXFMYslvk; Wed, 30 May 2012 08:05:24 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id B612021F8671; Wed, 30 May 2012 08:05:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1689; q=dns/txt; s=iport; t=1338390324; x=1339599924; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=7uKGvV6ccnKNxb2+p/wZPTKadSWOdesd23LbsfQKTIM=; b=S04j7TuvcA0CN0SU5dU4TA+ZrCAS2+5kKbd+/6NbxApyqh6RC5ZoKeRz Njw6ZvxseLtk+dw6wbdoXZhMKEdRfC2h04jOQwFwzeqydlMxNh6wCltgX FOnYBlSOYeqZ/sQGhI9gcdnacIP6/4u9eLnZT85IY80ymUue1mTjhbng1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACc2xk+tJV2b/2dsb2JhbABEtA2BB4IwAWU9FhgDAgECAUsBDAgBAR6HaZkRn3+QRwOVGIEPjH6BZoJi X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208";a="87941284" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 30 May 2012 15:05:24 +0000 Received: from macmini.wierenga.net (rtp-kwiereng-87110.cisco.com [10.116.7.43]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4UF5MSv031834; Wed, 30 May 2012 15:05:22 GMT Message-ID: <4FC63731.7060409@cisco.com> Date: Wed, 30 May 2012 17:05:21 +0200 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: The IESG , secdir@ietf.org, draft-ietf-tcpm-tcpmss.all@tools.ietf.org X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 15:05:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. General comments: ================== This is a short, clear and to the point draft. I have only a few general comments 1 (introduction) - ---------------- - - Please expand MSS on first use - - "(see appendix A)" and "but there still seems to be some confusion" This sounds pretty vague to me. I thought Appendix A would be a verbatim copy of the text from 1122, but it is much more, and I appreciated the discussion. I propose to make that explicit: "RFC1122 clarified the MSS option, but confusion remains as discussed in Appendix A" Security Considerations: ======================== I don't really think what you have written down here qualifies as security considerations. It sort of hints to a denial-of-service, but I don't see any evil, just an operational problem. What I wonder about (but I am not knowledgable to judge) is whether wrong MSS size settings could be exploited for for example buffer overflow attacks. Cheers, Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk/GNzAACgkQH2Wy/p4XeFJQrACdEZggKbo9y+3p3W35N7FBzpho izcAoIl1J9o04ymIXyYmEZP+IiHRH18I =aIb0 -----END PGP SIGNATURE----- From kwiereng@cisco.com Wed May 30 10:39:56 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322F521F85B9; Wed, 30 May 2012 10:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.78 X-Spam-Level: X-Spam-Status: No, score=-6.78 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt7ga4P0v0KO; Wed, 30 May 2012 10:39:55 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id C300021F85B5; Wed, 30 May 2012 10:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=4493; q=dns/txt; s=iport; t=1338399594; x=1339609194; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=NciYSdpQfPVnzBhO6erIc2DMJpEux+p5zB26PhCENxo=; b=aLkIh9qa96ET3jc0uLWGbK2/3GWa///M27QFc7mDfjfC0UP3tvSD/LA5 ykldc1HpGGQu9rMx3oNQbtGh/Ni/42cn9ADs9ycSNLYvG1OVmOcgLaz6Q OTvmQXjnP7lcxkjvjD/+HMxG1fjW9wSjp1aBjSI57xZasc7xQoOHMmt9m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlsHAHRaxk+Q/khL/2dsb2JhbABEtA8CgQeCFwEBAQMBEgEnPwULAgEIGC5XAQEEEyKHZAWZHKABiwUVhE1gA5UYgQ+MfieBP4JigVUI X-IronPort-AV: E=Sophos;i="4.75,685,1330905600"; d="scan'208";a="73825742" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 May 2012 17:39:53 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4UHdrNb031489; Wed, 30 May 2012 17:39:53 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 19:39:53 +0200 Received: from 144.254.74.76 ([144.254.74.76]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2012 17:39:52 +0000 References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> Content-Transfer-Encoding: quoted-printable From: "Klaas Wierenga (kwiereng)" Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: Ac0+izgwu9n5fU9KTAyL2JPMWZ7pwA== Content-Type: text/plain; charset="us-ascii" In-Reply-To: <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> Message-ID: Date: Wed, 30 May 2012 19:39:51 +0200 To: "David Borman" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 30 May 2012 17:39:53.0735 (UTC) FILETIME=[38C3E170:01CD3E8B] Cc: draft-ietf-tcpm-tcpmss.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:39:56 -0000 Hi David, On 30 mei 2012, at 19:29, "David Borman" wrote: > Klass, >=20 > Thanks for the review. >=20 > On May 30, 2012, at 10:05 AM, Klaas Wierenga wrote: >=20 >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >>=20 >> Hi, >>=20 >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >>=20 >> General comments: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> This is a short, clear and to the point draft. I have only a few >> general comments >>=20 >> 1 (introduction) >> - ---------------- >>=20 >> - - Please expand MSS on first use >=20 > Agreed. >=20 >>=20 >> - - "(see appendix A)" and "but there still seems to be some confusion" >>=20 >> This sounds pretty vague to me. I thought Appendix A would be a >> verbatim copy of the text from 1122, but it is much more, and I >> appreciated the discussion. I propose to make that explicit: >>=20 >> "RFC1122 clarified the MSS option, but confusion remains as discussed >> in Appendix A" >=20 > I've changed it to: > RFC 1122 [RFC1122] clarified the MSS > option, which is discussed in Appendix A, but there still seems to be > some confusion. Ah, I thought you had listed all confusion in appendix A. Since that does no= t seem to be the case, can you say anything about the nature of the remainin= g confusion? >>=20 >> Security Considerations: >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> I don't really think what you have written down here qualifies as >> security considerations. It sort of hints to a denial-of-service, but >> I don't see any evil, just an operational problem. >=20 > Another review said more or less the same thing.. Great minds..... ;-) >=20 >> What I wonder about >> (but I am not knowledgable to judge) is whether wrong MSS size >> settings could be exploited for for example buffer overflow attacks. >=20 > There shouldn't be any problem. The MSS is just an upper bound > for the size of packets that can be reassembled by the receiving > hosts; in theory most IPv4 hosts should be using 65535 because they > don't have a fixed limit, and then just let Path MTU discovery sort > it out. In practice, though, the MSS is used as an upper bound for what > size of packet can be received without the need for fragmentation, > avoiding PMTU from probing for larger sizes that will never succeed. >=20 > I don't have a strong opinion about the current content of the > Security Considerations section. My leaning is to just leave it > as is, but I'd be fine with moving the content up to section 5.4 > as an "Additional Consideration", and then have section 6, "Security > Considerations" just have a comment that there are no security > considerations, if folks generally feel that would be better. I don't feel comfortable with a security consideration that isn't, so I woul= d lean towards your alternative proposal. Thanks for the fast response! Klaas >=20 > -David Borman >=20 >>=20 >>=20 >> Cheers, >>=20 >> Klaas >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG/MacGPG2 v2.0.17 (Darwin) >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >>=20 >> iEYEARECAAYFAk/GNzAACgkQH2Wy/p4XeFJQrACdEZggKbo9y+3p3W35N7FBzpho >> izcAoIl1J9o04ymIXyYmEZP+IiHRH18I >> =3DaIb0 >> -----END PGP SIGNATURE----- >=20 > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any di= sclosure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quantu= m. Quantum reserves the right to have electronic communications, including e= mail and attachments, sent across its networks filtered through anti virus a= nd spam software programs and retain such messages in order to comply with a= pplicable data security and retention requirements. Quantum is not responsib= le for the proper and complete transmission of the substance of this communi= cation or for any delay in its receipt. From kwiereng@cisco.com Wed May 30 11:50:47 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A81411E80B6; Wed, 30 May 2012 11:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.78 X-Spam-Level: X-Spam-Status: No, score=-6.78 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfSb4FMS0lys; Wed, 30 May 2012 11:50:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 8385311E8098; Wed, 30 May 2012 11:50:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=kwiereng@cisco.com; l=3990; q=dns/txt; s=iport; t=1338403845; x=1339613445; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=HUGuqIhzlnNtpU5gJQRz/OpzYFdQx7UZHVD+eb7FyI4=; b=lXpZ87sFYC6kx+VsAT7aR5zzXV502VAiGjQEvaL9Ql+pK/UGyVSoyik/ jf3RbSl2B+Zt4t4aA+fb23vwSZFN56TzdzZ0HFRBXwyVycGcJsB9CMa1l y6CUGVGWMpiR/YfnTjov/0VyBSHxYzBVO4n68IzQVlRTMnLdT7kqb9o1Q o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcHANZqxk+Q/khN/2dsb2JhbABEigaqCQKBB4IXAQEBAwESASc/BQsCAQgYLlcBAQQTIodkBZkyn3aLBRWEUWADlRiODSeBP4JigVUI X-IronPort-AV: E=Sophos;i="4.75,686,1330905600"; d="scan'208";a="73828446" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 30 May 2012 18:50:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4UIogab022950; Wed, 30 May 2012 18:50:42 GMT Received: from xmb-ams-101.cisco.com ([144.254.74.76]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 May 2012 20:50:41 +0200 Received: from 144.254.74.76 ([144.254.74.76]) by XMB-AMS-101.cisco.com ([144.254.74.76]) with Microsoft Exchange Server HTTP-DAV ; Wed, 30 May 2012 18:50:41 +0000 References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> Content-Transfer-Encoding: quoted-printable From: "Klaas Wierenga (kwiereng)" Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: Ac0+lRyHuZ+Gs4+uQ/K+RUrpYhx/zQ== Content-Type: text/plain; charset="us-ascii" In-Reply-To: Message-ID: Date: Wed, 30 May 2012 20:50:41 +0200 To: "David Borman" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 30 May 2012 18:50:41.0791 (UTC) FILETIME=[1CCDC8F0:01CD3E95] Cc: draft-ietf-tcpm-tcpmss.all@tools.ietf.org, The IESG , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:50:47 -0000 David, Your suggestion looks fine to me! Klaas Sent from my iPad On 30 mei 2012, at 20:20, "David Borman" wrote: > Klaas, >=20 > On May 30, 2012, at 12:39 PM, Klaas Wierenga (kwiereng) wrote: >> On 30 mei 2012, at 19:29, "David Borman" wrote= : >>> On May 30, 2012, at 10:05 AM, Klaas Wierenga wrote: > ... >>>> - - "(see appendix A)" and "but there still seems to be some confusion"= >>>>=20 >>>> This sounds pretty vague to me. I thought Appendix A would be a >>>> verbatim copy of the text from 1122, but it is much more, and I >>>> appreciated the discussion. I propose to make that explicit: >>>>=20 >>>> "RFC1122 clarified the MSS option, but confusion remains as discussed >>>> in Appendix A" >>>=20 >>> I've changed it to: >>> RFC 1122 [RFC1122] clarified the MSS >>> option, which is discussed in Appendix A, but there still seems to be >>> some confusion. >>=20 >>=20 >> Ah, I thought you had listed all confusion in appendix A. Since that does= not seem to be the case, can you say anything about the nature of the remai= ning confusion? >=20 > How about: > RFC 1122 [RFC1122] clarified the MSS option, which is discussed in > Appendix A, but because it didn't explicitly state how options > should be handled, there still seems to be some confusion. >=20 >>>> Security Considerations: >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >>>> I don't really think what you have written down here qualifies as >>>> security considerations. It sort of hints to a denial-of-service, but >>>> I don't see any evil, just an operational problem. >>>=20 >>> Another review said more or less the same thing.. >>=20 >> Great minds..... ;-) >>=20 >>>=20 >>>> What I wonder about >>>> (but I am not knowledgable to judge) is whether wrong MSS size >>>> settings could be exploited for for example buffer overflow attacks. >>>=20 >>> There shouldn't be any problem. The MSS is just an upper bound >>> for the size of packets that can be reassembled by the receiving >>> hosts; in theory most IPv4 hosts should be using 65535 because they >>> don't have a fixed limit, and then just let Path MTU discovery sort >>> it out. In practice, though, the MSS is used as an upper bound for what= >>> size of packet can be received without the need for fragmentation, >>> avoiding PMTU from probing for larger sizes that will never succeed. >>>=20 >>> I don't have a strong opinion about the current content of the >>> Security Considerations section. My leaning is to just leave it >>> as is, but I'd be fine with moving the content up to section 5.4 >>> as an "Additional Consideration", and then have section 6, "Security >>> Considerations" just have a comment that there are no security >>> considerations, if folks generally feel that would be better. >>=20 >> I don't feel comfortable with a security consideration that isn't, so I w= ould lean towards your alternative proposal. >=20 > Ok, I'll move the content to section 5, and leave "Security Considerations= " > empty, unless someone else objects to making that change. >=20 > -David Borman >=20 > ---------------------------------------------------------------------- > The information contained in this transmission may be confidential. Any di= sclosure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quantu= m. Quantum reserves the right to have electronic communications, including e= mail and attachments, sent across its networks filtered through anti virus a= nd spam software programs and retain such messages in order to comply with a= pplicable data security and retention requirements. Quantum is not responsib= le for the proper and complete transmission of the substance of this communi= cation or for any delay in its receipt. From prvs=24978c23fc=david.borman@quantum.com Wed May 30 10:29:18 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145111E80D2; Wed, 30 May 2012 10:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCIzcl7c79Wm; Wed, 30 May 2012 10:29:17 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDC711E80BB; Wed, 30 May 2012 10:29:16 -0700 (PDT) Received: from pps.filterd (m0001158 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.4/8.14.4) with SMTP id q4UHTAu6022595; Wed, 30 May 2012 10:29:15 -0700 Received: from ppoxedge1.quantum.com ([146.174.252.27]) by mx0b-000ceb01.pphosted.com with ESMTP id 155me88amy-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 May 2012 10:29:15 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE1.quantum.com (146.174.252.27) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 30 May 2012 10:29:01 -0700 Received: from PPOMSG1.QUANTUM.com ([fe80::6081:f8af:54f6:10cc]) by PPOMSG2.QUANTUM.com ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Wed, 30 May 2012 11:29:14 -0600 From: David Borman To: Klaas Wierenga Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyA Date: Wed, 30 May 2012 17:29:13 +0000 Message-ID: <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> References: <4FC63731.7060409@cisco.com> In-Reply-To: <4FC63731.7060409@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-ID: <130E688CB05BF543B06B0FAFB1348008@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-30_02:2012-05-21, 2012-05-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205300187 Content-Type: text/plain; charset="iso-8859-1" X-Mailman-Approved-At: Wed, 30 May 2012 15:19:14 -0700 Cc: "" , The IESG , "" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:29:18 -0000 Klass, Thanks for the review. On May 30, 2012, at 10:05 AM, Klaas Wierenga wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > Hi, >=20 > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > General comments: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > This is a short, clear and to the point draft. I have only a few > general comments >=20 > 1 (introduction) > - ---------------- >=20 > - - Please expand MSS on first use Agreed. >=20 > - - "(see appendix A)" and "but there still seems to be some confusion" >=20 > This sounds pretty vague to me. I thought Appendix A would be a > verbatim copy of the text from 1122, but it is much more, and I > appreciated the discussion. I propose to make that explicit: >=20 > "RFC1122 clarified the MSS option, but confusion remains as discussed > in Appendix A" I've changed it to: RFC 1122 [RFC1122] clarified the MSS option, which is discussed in Appendix A, but there still seems to be some confusion. >=20 > Security Considerations: > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > I don't really think what you have written down here qualifies as > security considerations. It sort of hints to a denial-of-service, but > I don't see any evil, just an operational problem. Another review said more or less the same thing.. > What I wonder about > (but I am not knowledgable to judge) is whether wrong MSS size > settings could be exploited for for example buffer overflow attacks. There shouldn't be any problem. The MSS is just an upper bound for the size of packets that can be reassembled by the receiving hosts; in theory most IPv4 hosts should be using 65535 because they don't have a fixed limit, and then just let Path MTU discovery sort it out. In practice, though, the MSS is used as an upper bound for what size of packet can be received without the need for fragmentation, avoiding PMTU from probing for larger sizes that will never succeed. I don't have a strong opinion about the current content of the Security Considerations section. My leaning is to just leave it as is, but I'd be fine with moving the content up to section 5.4 as an "Additional Consideration", and then have section 6, "Security Considerations" just have a comment that there are no security considerations, if folks generally feel that would be better. =20 -David Borman >=20 >=20 > Cheers, >=20 > Klaas > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.17 (Darwin) > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >=20 > iEYEARECAAYFAk/GNzAACgkQH2Wy/p4XeFJQrACdEZggKbo9y+3p3W35N7FBzpho > izcAoIl1J9o04ymIXyYmEZP+IiHRH18I > =3DaIb0 > -----END PGP SIGNATURE----- ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From prvs=24978c23fc=david.borman@quantum.com Wed May 30 11:20:15 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D58521F861F; Wed, 30 May 2012 11:20:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt3pnKKrE2Ov; Wed, 30 May 2012 11:20:14 -0700 (PDT) Received: from mx0b-000ceb01.pphosted.com (mx0b-000ceb01.pphosted.com [67.231.152.126]) by ietfa.amsl.com (Postfix) with ESMTP id A925521F8618; Wed, 30 May 2012 11:20:14 -0700 (PDT) Received: from pps.filterd (m0001151 [127.0.0.1]) by mx0b-000ceb01.pphosted.com (8.14.4/8.14.4) with SMTP id q4UIJbJT006352; Wed, 30 May 2012 11:20:13 -0700 Received: from ppoxedge2.quantum.com ([146.174.252.28]) by mx0b-000ceb01.pphosted.com with ESMTP id 155qaq84ds-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 30 May 2012 11:20:13 -0700 Received: from PPOMSG2.QUANTUM.com (10.50.35.27) by PPOXEDGE2.quantum.com (146.174.252.28) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 30 May 2012 11:19:56 -0700 Received: from PPOMSG1.QUANTUM.com ([fe80::6081:f8af:54f6:10cc]) by PPOMSG2.QUANTUM.com ([fe80::e4fd:df34:99ee:ac5e%20]) with mapi id 14.01.0355.002; Wed, 30 May 2012 12:20:11 -0600 From: David Borman To: "Klaas Wierenga (kwiereng)" Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyAgAAC+4CAAAs/AA== Date: Wed, 30 May 2012 18:20:10 +0000 Message-ID: References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.110.1] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E9D78E21E818F418CB9839BC024DA74@QUANTUM.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.6.7580, 1.0.260, 0.0.0000 definitions=2012-05-30_02:2012-05-21, 2012-05-30, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1205300204 X-Mailman-Approved-At: Wed, 30 May 2012 15:19:14 -0700 Cc: "" , The IESG , "" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 18:20:15 -0000 Klaas, On May 30, 2012, at 12:39 PM, Klaas Wierenga (kwiereng) wrote: > On 30 mei 2012, at 19:29, "David Borman" wrote: >> On May 30, 2012, at 10:05 AM, Klaas Wierenga wrote: ... >>> - - "(see appendix A)" and "but there still seems to be some confusion" >>>=20 >>> This sounds pretty vague to me. I thought Appendix A would be a >>> verbatim copy of the text from 1122, but it is much more, and I >>> appreciated the discussion. I propose to make that explicit: >>>=20 >>> "RFC1122 clarified the MSS option, but confusion remains as discussed >>> in Appendix A" >>=20 >> I've changed it to: >> RFC 1122 [RFC1122] clarified the MSS >> option, which is discussed in Appendix A, but there still seems to be >> some confusion. >=20 >=20 > Ah, I thought you had listed all confusion in appendix A. Since that does= not seem to be the case, can you say anything about the nature of the rema= ining confusion? How about: RFC 1122 [RFC1122] clarified the MSS option, which is discussed in Appendix A, but because it didn't explicitly state how options should be handled, there still seems to be some confusion. >>> Security Considerations: >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D >>> I don't really think what you have written down here qualifies as >>> security considerations. It sort of hints to a denial-of-service, but >>> I don't see any evil, just an operational problem. >>=20 >> Another review said more or less the same thing.. >=20 > Great minds..... ;-) >=20 >>=20 >>> What I wonder about >>> (but I am not knowledgable to judge) is whether wrong MSS size >>> settings could be exploited for for example buffer overflow attacks. >>=20 >> There shouldn't be any problem. The MSS is just an upper bound >> for the size of packets that can be reassembled by the receiving >> hosts; in theory most IPv4 hosts should be using 65535 because they >> don't have a fixed limit, and then just let Path MTU discovery sort >> it out. In practice, though, the MSS is used as an upper bound for what >> size of packet can be received without the need for fragmentation, >> avoiding PMTU from probing for larger sizes that will never succeed. >>=20 >> I don't have a strong opinion about the current content of the >> Security Considerations section. My leaning is to just leave it >> as is, but I'd be fine with moving the content up to section 5.4 >> as an "Additional Consideration", and then have section 6, "Security >> Considerations" just have a comment that there are no security >> considerations, if folks generally feel that would be better. >=20 > I don't feel comfortable with a security consideration that isn't, so I w= ould lean towards your alternative proposal. Ok, I'll move the content to section 5, and leave "Security Considerations" empty, unless someone else objects to making that change. -David Borman ---------------------------------------------------------------------- The information contained in this transmission may be confidential. Any dis= closure, copying, or further distribution of confidential information is no= t permitted unless such privilege is explicitly granted in writing by Quant= um. Quantum reserves the right to have electronic communications, including= email and attachments, sent across its networks filtered through anti viru= s and spam software programs and retain such messages in order to comply wi= th applicable data security and retention requirements. Quantum is not resp= onsible for the proper and complete transmission of the substance of this c= ommunication or for any delay in its receipt. From michael.scharf@alcatel-lucent.com Wed May 30 13:47:48 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE9E21F8748; Wed, 30 May 2012 13:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.671 X-Spam-Level: X-Spam-Status: No, score=-9.671 tagged_above=-999 required=5 tests=[AWL=0.222, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bybfz7fFY+w; Wed, 30 May 2012 13:47:47 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7E921F8747; Wed, 30 May 2012 13:47:47 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q4UKlidJ001003 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 30 May 2012 22:47:44 +0200 Received: from FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com ([135.120.45.55]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 30 May 2012 22:47:44 +0200 From: "Scharf, Michael (Michael)" To: David Borman Date: Wed, 30 May 2012 22:47:42 +0200 Thread-Topic: secdir review of draft-ietf-tcpm-tcpmss-04 Thread-Index: AQHNPnXIPFIPS9owW0+7AUuNti9CaZbi+xyAgAAC+4CAAAs/AP//voCg Message-ID: <2A886F9088894347A3BE0CC5B7A85F3E891A9BB37B@FRMRSSXCHMBSE3.dc-m.alcatel-lucent.com> References: <4FC63731.7060409@cisco.com> <58B9B09F-ECA8-457E-B22C-34CE7A69CCFA@quantum.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 X-Mailman-Approved-At: Wed, 30 May 2012 15:19:14 -0700 Cc: "" , The IESG , "" Subject: Re: [secdir] secdir review of draft-ietf-tcpm-tcpmss-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 20:47:48 -0000 > >> I don't have a strong opinion about the current content of the=20 > >> Security Considerations section. My leaning is to just=20 > leave it as=20 > >> is, but I'd be fine with moving the content up to section=20 > 5.4 as an=20 > >> "Additional Consideration", and then have section 6, "Security=20 > >> Considerations" just have a comment that there are no security=20 > >> considerations, if folks generally feel that would be better. > >=20 > > I don't feel comfortable with a security consideration that=20 > isn't, so I would lean towards your alternative proposal. >=20 > Ok, I'll move the content to section 5, and leave "Security=20 > Considerations" > empty, unless someone else objects to making that change. Instead of an empty security considerations section, you could also add a s= entence explaining that the document just clarifies what is mandated by RFC= 1122, and that it thus does not result in new security issues. According to the working group discussions and the WGLC feedback, TCPM is a= pparently not aware of any security issues with this draft, and I think tha= t TCPM would be fine with mentioning this more explicitly. Just a thought... Michael (as document shepard) From gonzalo.camarillo@ericsson.com Thu May 31 03:06:46 2012 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD4121F8630; Thu, 31 May 2012 03:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.235 X-Spam-Level: X-Spam-Status: No, score=-106.235 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTRNYj8S8ye6; Thu, 31 May 2012 03:06:45 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 395F021F860D; Thu, 31 May 2012 03:06:44 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc66d000006fdc-64-4fc742b36a85 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id B9.03.28636.3B247CF4; Thu, 31 May 2012 12:06:43 +0200 (CEST) Received: from [131.160.36.95] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.264.0; Thu, 31 May 2012 12:06:42 +0200 Message-ID: <4FC742B2.10508@ericsson.com> Date: Thu, 31 May 2012 13:06:42 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Yaron Sheffer References: <4FBFAE5F.8010305@gmail.com> In-Reply-To: <4FBFAE5F.8010305@gmail.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvre5mp+P+BtMniFvcfjWLzWLGn4nM Fh8WPmSxWHV/BrsDi8fOWXfZPZYs+cnk8eXyZ7YA5igum5TUnMyy1CJ9uwSujOY7/1kLDotW 9Cy5wdrAuECwi5GTQ0LAROLogjNMELaYxIV769m6GLk4hAROMUr8W93FApIQEljNKNF8TxnE 5hXQlFg6cy8biM0ioCpxd8dlVhCbTcBCYsut+2D1ogLBEvO6b7JA1AtKnJz5BMjm4BAB6p12 1ApkPjPI/AOHPzOCxIUFPCX6n0ZArNKQ2L9xAjuIzQlU/vLmRzaI2yQlDv67BhZnFjCQOLJo DiuELS/RvHU2M0SvtsTyZy0sExiFZiHZPAtJyywkLQsYmVcxCucmZuaklxvqpRZlJhcX5+fp FaduYgSG98Etv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2ampBalF8UWlOavEhRiYOTqkG xi79JRXhClejXE49z/6oNTN39YQfRZXW9xpPzvbTqRCt5EoVXPL976rvPsfL4h+s+jtn5Rc1 ycgCBWGmwuVsy394mWx/4jo//emJlhum835ot3ZNeGj15vW8xAiBHRqZMmG7r90vcfl1sSVX 75/5BT+BRYFycT+s3swWuqOU5uy49oPP7CI3ASWW4oxEQy3mouJEADywAYk9AgAA Cc: "iesg@ietf.org" , "draft-camarillo-rai-media-policy-dataset.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-camarillo-rai-media-policy-dataset-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 May 2012 10:06:46 -0000 Hi Yaron, thanks for reviewing the document. I will add the two references you suggest in your last point to the next revision of the draft. With respect to the remainder of your comments on the event package document, that draft has already been in the RFC Editor's queue for a while. So, at this point, we will not change it (although I would be happy to replace that "should not" with a "SHOULD NOT" in AUTH48). Also, SIP security is getting deployed on the field slowly as time goes by. It is true that it is taking a while, but we are getting there. Cheers, Gonzalo On 25/05/2012 7:07 PM, Yaron Sheffer wrote: > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > Summary > > Nothing much here - this is not where the security action is. However a > companion document may need some deeper security review. > > Details > > This draft defines the contents/format of a media document. The document > allows a SIP policy server to dictate the media policy that should be > implemented by a UA, in general or on a per-session basis. > > • The draft requires that all documents be well-formed and valid XML, > which is good - not only for security. > • The real security stuff is in draft-ietf-sipping-policy-package-08. I > will not review that document here, but I find it puzzling that session > (media) information is transmitted/secured along with session encryption > keys. Mixing together data of such disparate security sensitivity levels > is likely to result in either over-engineering or under-security. > • Reading further down the said security considerations, this issue is > addressed ("the user agent should not insert" etc.), but none of that > discussion is normative! > • Moreover, recent discussion on SAAG > (http://www.ietf.org/mail-archive/web/saag/current/msg03695.html) > suggests that some of the security solutions mandated by the Policy > Package draft as well as the current draft are, to put it mildly, not > widely implemented. > • Back to the current document. Re: XML security considerations, please > reference the security considerations of RFC 3470, and possibly also: > Marsh, J., Orchard, D., and D. Veillard, "XML Inclusions (XInclude) > Version 1.0 (Second Edition)", World Wide Web Consortium Recommendation > REC-xinclude-20061115, November 2006, > . > > Thanks, > Yaron >