From alexander.zimmermann@comsys.rwth-aachen.de Tue Aug 31 02:14:19 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E8A03A67B3; Tue, 31 Aug 2010 02:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sruTtAaoUBzv; Tue, 31 Aug 2010 02:14:11 -0700 (PDT) Received: from mta-2.ms.rz.rwth-aachen.de (mta-2.ms.rz.RWTH-Aachen.DE [134.130.7.73]) by core3.amsl.com (Postfix) with ESMTP id 9627E3A63D3; Tue, 31 Aug 2010 02:14:10 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-2.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L80004CEF0GW660@mta-2.ms.rz.RWTH-Aachen.de>; Tue, 31 Aug 2010 11:14:40 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.56,297,1280700000"; d="sig'?scan'208";a="70679931" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 31 Aug 2010 11:14:40 +0200 Received: from [137.226.12.62] ([unknown] [137.226.12.62]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L800004FF0G9U90@relay-auth-2.ms.rz.rwth-aachen.de>; Tue, 31 Aug 2010 11:14:40 +0200 (CEST) Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-4--3793167 From: Alexander Zimmermann In-reply-to: <4FE24FB3-14CA-40A4-A902-531176B36950@nokia.com> Date: Tue, 31 Aug 2010 11:14:44 +0200 Content-transfer-encoding: 7bit Message-id: References: <8B3DD996-10E8-431A-90A6-222804931E08@nokia.com> <4FE24FB3-14CA-40A4-A902-531176B36950@nokia.com> To: Lars Eggert X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Wed, 01 Sep 2010 08:09:37 -0700 Cc: "draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org" , "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-tcpm-tcp-lcd-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 09:14:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-4--3793167 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lars, Hi Catherine, due to vacation, we are a little bit behind our schedule... Please give us one more week. We will definitely incorporate the feedback. Alex Am 31.08.2010 um 10:57 schrieb Lars Eggert: > Hi, >=20 > this is a good suggestion. Authors, would you work this into the text? >=20 > Lars >=20 > On 2010-8-27, at 23:08, Catherine Meadows wrote: >=20 >> Hi Lars: >>=20 >> Thanks for your comments. I perhaps did not appreciate completely = the significance of this being an experimental ID. >>=20 >> Still, I think that the security considerations section could use = some improving. >> Simply presenting one example of an attack without adequate = motivation as to why this >> attack is the most relevant one merely confuses the reader (or at = least that was the effect on me). >> I would suggest that the authors add more motivation such as you give = in your email, >> namely that the only behavior change required by this protocol is in = the response >> to ICMP messages, and thus that the only way an attacker could cause = a change in behavior >> of the protocol is by either causing more or few ICMP messages to be = generated than would have >> occurred otherwise. Then you could discuss the goals of the = attacker; I think it is reasonable to assume, >> as the authors do, that the only possible goal is denial of service, = since the ICMP messages are not used >> for authentication or to control access to sensitive information. = But it wouldn't hurt to point this out. >> Then you could discuss the contribution of spurious or suppressed = ICMP messages to a denial of service attack (minimal). >> You could then discuss the problem of spoofing or suppressing ICMP = messages, although this may not be necessary >> if the effect is minimal. At any case, this would give you a more = convincing argument that the protocol does not introduce >> any security vulnerabilities, and it doesn't require much more than = bringing forward and tying together information that is >> already in the ID. >>=20 >> Cathy >>=20 >> On Aug 26, 2010, at 1:17 PM, Lars Eggert wrote: >>=20 >>> Hi, authors, >>>=20 >>> please respond to the point Catherine raises. >>>=20 >>> (Catherine, a few comments from my side are included below.) >>>=20 >>>=20 >>> On 2010-8-24, at 1:28, Catherine Meadows 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. >>>>=20 >>>> This document proposes an algorithm to make TCP more robust to long = connectivity >>>> disruptions. Currently TCP has no way of distinguishing = disruptions due to connectivity >>>> loss from disruptions due to congestion. Thus, TCP will back off = when faced with connectivity >>>> loss, which will lead to further delays. The proposed algorithm = uses the ICMP destination unreachable >>>> messages as indications of a connectivity disruption, and alters = the behavior of TCP accordingly. >>>>=20 >>>> My impression from reading this draft is that the behavior and = utility of this algorithm will depend on >>>> further research and experimentation. There are a number of = situations in which it will still be possible >>>> to confuse congestion and long connectivity disruptions that may = need further exploration. The authors of the document do a good job of = pointing >>>> these out, but I would have liked to have seen more evidence that = the solutions recommended are the optimal >>>> ones, and under what situations. >>>=20 >>> The goal of this mechanism is not to be optimal (TCP as a whole is = not trying to be optimal). The goal is to improve things in many cases = and not cause harm in realistic all cases. >>>=20 >>>> This is especially the case for the security issues, although it is = not >>>> limited to those. For example, in the discussion of probing = frequency in Section 5.4 the authors make a claim >>>> that in their belief the approach of their algorithm is preferable = to others that would give higher probing >>>> frequency, but they need to provide more evidence to back this up. >>>=20 >>> I think it is fine for an Experimental document to state a belief = and ask people to verify it with experiments. For a standards-track = document, yes, we'd absolutely like to see which one is the one to pick. >>>=20 >>>> The security considerations section itself is rather sketchy, and = doesn't support that authors' assertions >>>> that the algorithm is "considered to be secure." The greatest = security threat posed by this >>>> algorithm is that an attacker could exploit it to persuade a TCP = sender that communication problems >>>> due to congestion are actually due to a connectivity problem, = leading the sender to further contribute to the >>>> congestion. >>>=20 >>> Remember that this mechanism only makes a difference during = timeout-based loss recovery, i.e., when TCP at most sends a packet or = two over often many seconds. And even when it fires, it doesn't result = in a flood of packets, all it results in is that a slow-start restart = will be attempted earlier than without this mechanism. So the potential = for harm is really low. >>>=20 >>>> However, the authors mention only one possible attack: forging ICMP = destination unreachable >>>> messages, which they present only as an "example" of an attack. >>>=20 >>> It's presented of an example where even if the attacked could pull = it off, the mechanism is still unaffected.=20 >>>=20 >>>> I would recommend a more complete >>>> discussion, considering each of the potential ambiguity cases = discussed in the document, and discussing >>>> how an attacker could exploit them and how such exploitation could = be prevented or mitigated. You might >>>> also want to discuss the opposite problem: how an attacker could = convince a sender that a connectivity >>>> problem is a congestion problem. This is less serious, at least = for the moment, since in the current >>>> situation that is exactly what happens, but it could be more of a = threat further down the line if people come >>>> to rely more on this ability to disambiguate. >>>=20 >>> If the authors can think of any other attacks, they should = absolutely include them, but since ICMPs are the only signal the = mechanism reacts to, generating fake ones or suppressing real ones are = pretty much the only attack angles I can think of. >>>=20 >>> Lars >>>=20 >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Catherine Meadows >>>> Naval Research Laboratory >>>> Code 5543 >>>> 4555 Overlook Ave., S.W. >>>> Washington DC, 20375 >>>> phone: 202-767-3490 >>>> fax: 202-404-7942 >>>> email: = catherine.meadows@nrl.navy.mil >>>>=20 >>>=20 >>> Lars >>=20 >> Catherine Meadows >> Naval Research Laboratory >> Code 5543 >> 4555 Overlook Ave., S.W. >> Washington DC, 20375 >> phone: 202-767-3490 >> fax: 202-404-7942 >> email: catherine.meadows@nrl.navy.mil >>=20 >=20 // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22221 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-4--3793167 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkx8yAUACgkQdyiq39b9uS7irACfYMfcH8lFGptvziKPOIwOcOQ9 f8gAn0NtyIh/97D7jQ6pXT9a6GTFmOTp =vcF6 -----END PGP SIGNATURE----- --Apple-Mail-4--3793167-- From ted.ietf@gmail.com Wed Sep 1 09:52:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E77D13A69D5; Wed, 1 Sep 2010 09:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.246 X-Spam-Level: X-Spam-Status: No, score=-1.246 tagged_above=-999 required=5 tests=[AWL=0.753, BAYES_00=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZsUaro+FfgN; Wed, 1 Sep 2010 09:52:36 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A22B13A67F3; Wed, 1 Sep 2010 09:52:31 -0700 (PDT) Received: by ewy22 with SMTP id 22so4848573ewy.31 for ; Wed, 01 Sep 2010 09:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TpD4qJhYUxFMt8MvLr3cwt6ktKWre8N9FZujdwNZ3ow=; b=otQIexzmqXvOFEOy/Ry9PW9Oy6Sfj6JSEbR0BOH7uerGOz+EwKaI1ygORS0FVDlaBr 7Au6Ktp6CTgFzd21vpS9Wk9Jg95bDPXqMU1mwmNFeHZEMd8CvLvTOzHQkDy8BW/7zvwV mZ+H3QkN1wfWNdP6YxR/gym/oJBMpIabjnMLo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Qmv1lJ8qepGkcpJli21fknryFj7/fo03zTmEG+QMhqvM33llAd+PF3zEqwJOz9hl7H eBKOaZWlhNLRYxCULcwqeW/OmMNZZdckFsQqorBihqaYKd1c19lejyKFDmXGr+sweejv Ecp7l7P02ehzalehTbKIEqHXzibonr6myyhCk= MIME-Version: 1.0 Received: by 10.213.34.137 with SMTP id l9mr617998ebd.16.1283359980804; Wed, 01 Sep 2010 09:53:00 -0700 (PDT) Received: by 10.14.45.66 with HTTP; Wed, 1 Sep 2010 09:53:00 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 1 Sep 2010 09:53:00 -0700 Message-ID: From: Ted Hardie To: Christer Holmberg Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: The IETF , "secdir@ietf.org" , "ben@estacado.net" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 16:52:48 -0000 Hi Christer, Thanks for your message and your consideration of the points I raised. Given the scope of changes below, my first suggestion is that the author team actuall= y go ahead with a draft incorporating these changes, so that we can discuss based on the actual text. I also suspect that a second last call will be necessary as a result. Some further discussion in-line. On Tue, Aug 31, 2010 at 10:39 AM, Christer Holmberg wrote: > Hi, > > The purpose of this e-mail is to address the secdir comments given by Ric= hard > Barnes and Ted Hardie. Due to summer vacations, standardization meetings > etc it took a while to put the e-mail together, and we appologise for tha= t. > > GENERAL > =3D=3D=3D=3D=3D=3D=3D > > First, the draft does NOT propose any changes to the TLS authentication > procedures =96 that will be clarified. The changes are only related to th= e > procedure for matching an incoming MSRP message to an MSRP session that > has been negotiated using SDP =96 once any TLS authentication procedure h= as > already taken place. > > So, in case of TLS and name based authentication, if an SBC/ALG modifies > the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the curr= ent > behavior, and sessmatch doesn=92t change that. > > We understand that this fact needs to be clearly indicated in the draft. > > Basically sessmatch allows so that, when using peer to peer MSRP, SIP SBC= s > and SIP aware firewalls can be in the SIP signaling path without acting a= s > MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP rela= ys > the SBC/ALG needs to act as MSRP B2BUA, as today. > > Sessmatch aims to extend the usability of MSRP peer to peer communication= to > scenarios where simple ALGs/SBCs are used, and at least in our experience > customer interest for standard MSRP has grown (from more or less zero) > dramatically due to sessmatch. And, OMA, which previously used a *non-sta= ndard* > version of MSRP (with no interoperability with standard MSRP), has also a= greed > to switch to sessmatch (even if it required a number of changes in their > specifications). > > Second, the intention of sessmatch is not to modify the MSRP URI matching= rules, > but rather to not use MSRP URI matching for session matching. > This is the key point in your message, at least from my perspective. This basically means that all of section 6 of RFC 4975, which clearly describes those URIs as the session identifiers: URIs using the "msrp" and "msrps" schemes are used to identify a session of instant messages at a particular MSRP device, as well as to identify an MSRP relay in general. needs to be replaced and all the logic that depends on it must be reviewed. The current draft does not indicate that section 6 is being normatively updated, and yet this is the key point of the work. You are moving from a namespace-scoped identifier t= o an unscoped identifier, and you will require both justifications of that (some given below) and mechanics for that described in more detail. In particular, I do not believe it is clear in the discussion so far whether the identifier may ever be scoped by the authority section of the URI or whether it is always treated as unscoped. If the latter, it is unclear to me whether the right notion here isn't simply to create a new non-URI identifi= er. > Please also note that when we talk about SBCs/ALGs, we refer to entities = that > normally do NOT have the capability to act as MSRP B2BUAs. > > We will comment the individual comments based on the assumptions above. > > > Comments from Richard > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>I have reviewed this document as part of the security directorate's ongoi= ng >>effort to review all IETF documents being processed by the IESG. These >>comments were written primarily for the benefit of the security area dire= ctors. >>Document editors and WG chairs should treat these comments just like any = other >>last call comments. >> >>This document changes the URI matching algorithm used in MSRP. =A0MSRP se= ssions >>are typically initiated using SDP bodies in SIP. =A0These SDP >>bodies contain MSRP URIs that the peers use to contact each other. >>When one peer receives a request to initiate a session, he verifies that = the >>URI being requested is one that he initiated in SDP, thereby using the UR= I as a >>shared secret to authenticate that the originator of the session actually >>received the SDP body in question. >> >>According to the current SDP specification, this comparison is performed = over >>the whole URI; this document restricts the comparison to the "session-id" >>component, omitting the host, port, and transport components. =A0The goal= of the >>document is to facilitate a certain class of man-in-the-middle attack, na= mely >>to allow a signaling intermediary to insert a media intermediary. =A0The >>restriction on the URI comparison is needed in order for the media interm= ediary >>not to have to modify URIs in MSRP packets to reflect the modifications t= o URIs >>in SDP bodies performed to redirect traffic through the media intermediar= y. > > When an MSRP UA receives an MSRP packet it performs msrp session matching= in order > to verify that the msrp packet belongs to an existing SDP negotiated msrp= session > at the UA. RFC4975 prescribes that URI matching should be used for sessio= n matching. > We argue that the namespace scoping of the session-id values that use of = URI matching > brings is unnecessary. The 80-bit randomness of the session-id and the fa= ct that it > was the UA itself that decided on the session-id value and can ensure tha= t it is > unique within the UA makes the session-id sufficiently unique for session= matching. > Sessmatch is not changing the MSRP URI matching algorithm, it is changing= the session > matching algorithm not to use MSRP URI matching. > Please clarify in what contexts MSRP URI matching would then occur. >>I have a few significant reservations about this document: >> >>1) This extension makes it more difficult for MSRP entities to secure the= ir >>communications against attackers in the signaling path. =A0The current mo= del >>provides a basic integrity protection, in that signaling intermediaries c= annot >>redirect traffic to an arbitrary third party; they must at least advise t= he >>third party about how to modify MSRP packets. The proposed modification w= ould >>remove even this cost. > > If we do not introduce the sessmatch change then the only alternative for= MSRP > connections to be able to be set up when SBCs or SIP aware firewalls are = in the > SIP signaling path is for these to introduce MSRP B2BUA support. This is = probably > not feasible for most SBCs and SIP aware firewalls, and if it actually we= re > feasible then it would mean as big a security problem, or even bigger, th= an > sessmatch. The choice is thus to not use MSRP at all in presence of such = devices > or to introduce sessmatch. Not to fix this probably would mean that use o= f MSRP > will be marginalized. > >>2) Moreover, it raises the cost of providing integrity protection to mess= ages, >>since Alice must now employ both integrity and confidentiality protection= s on >>an end-to-end basis; if her messages are only integrity-protected, then a= proxy >>can remove the integrity protection and redirect traffic without it being >>observable to Alice. >> >>The document needs to clarify what the impacts are for authentication in = secure >>modes of MSRP. =A0In particular: >>-- The distinction between "self-signed" and "public" certificates is >>inappropriate. =A0The proper distinction is between the name-based authen= tication >>in Section 14.2 of RFC 4975 and the fingerprint-based authentication in S= ection >>14.4. > > We cannot find the terminology =93name-based=94 authentication in RFC 497= 5. The RFC talks > about TLS authentication using either certificates from well-known certif= icate > authorities, or using self-signed certificates together with certificate = fingerprints. > > Having said that, however, we DO agree that the terminology you suggest i= s more > appropriate than what we have used and we will introduce this terminology= and explain > it in the Convention section of the sessmatch draft. > >>-- In either case, changing the host name need not result in an authentic= ation >>failure, since the media intermediary can simply authenticate as itself t= o both >>endpoints, having changed the respective MSRP URIs appropriately. > > A media intermediary can only do this if it is an MSRP B2BUA, and sessmat= ch was > introduced just to avoid most SBCs and ALGs having to implement an MSRP B= 2BUA in order > to allow standard MSRP deployment. > >>-- There is currently no requirement that an endpoint identity in the To-= Path >>URI matches the endpoint identity authenticated at the TLS layer, because= these >>two are required to be the same. =A0This document changes that assumption= , and >>should note that these two identities can differ. > > We will explicitly mention this. > >>The document also precludes any name-based multiplexing, where a single M= SRP >>process (single IP address and port) directs requests to different virtua= l >>recipients based on the domain name in the To-Path header. (In analogy to >>Host-based multiplexing in HTTP, which is very widely deployed.) Since wi= th >>this extension, the domain in the To- Path is completely unpredictable fr= om the >>recipient's perspective, it is useless to the recipient. > > That is correct, but there should be no problem for a single MSRP process= (single > IP address and port) to direct requests to different virtual recipients -= based > on the session-id instead. It is only needed for the different virtual re= cipients > to inform the receiver process on which session-ids that are currently ne= gotiated > instead of informing it on which domain name the virtual recipient shall = be > associated with. > >>The document has no backward-compatibility. MSRP implementations that do = not >>support this extension will not be able to receive MSRP sessions from >>implementations that do. In that regard, this document seems more like a = new >>version of MSRP rather than an update. > > It is not true that there is no backwards compatibility. If there are no > SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem for= MSRP > implementations that do not support the sessmatch extension to receive MS= RP > sessions from implementations that do. > > MSRP implementations that do not support the sessmatch extension are howe= ver not > able to establish MSRP end to end conversations if there are ALGs/SBCs in= the > session path (unless these implement MSRP B2BUA) and sessmatch does not c= hange this > fact =96 it will not work disregarding if the other endpoint supports ses= smatch or not. > I do not believe the document describes this scenario. In particular, the document should discuss what happens when an MSRP implementation that believes it sh= ould use MSRP URI matching interacts with an implementation that is using this matching. Frankly, I think this supports the idea of using a straight token-based identifier, rather than a portion of the URI. The scope for confusion is much smaller. >>>>I also note that the security considerations, in addition to having >>>>some fairly disingenuous language about the impact of this change, >>>>seems to fail to mention MSRPS URIs and what, if any, impact this >>>>would have on them. >>> >>>There are no impacts to MSRPS URIs. I assumed it would be implicitly >>>understood since MSRPS URIs are not mentioned in the draft. >>> >>>However, we could explicitly make it clear by modifying the first >>>sentences of section 5: >>> >>>"The change of session matching procedure does not impact the >>>format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps" sc= heme >>>is used. However, MSRP endpoints can only check that the session-id part= of >>>the MSRP URI..." >> >>The conflict here is that with MRSPS authentication, the name in the >>certificate is checked against the domain name in the URI, which was OK w= hen >>the URI in the message was required to be the same. By allowing the domai= n >>name in the message to change, this draft removes man-in-the-middle prote= ction >>from MSRPS. >> >>The document notes that a SIP MitM can already direct the user to another >>destination. =A0However, if the peers use MSRPS with the current authenti= cation >>scheme, the MitM will not be able to be a part of the resulting MSRPS ses= sion, >>since he can't authenticate as one of the endpoints. If only the session = ID is >>used in comparisons, the MitM can patch himself in by changing the domain= in >>the MSRPS URI. (Which actually seems to be the intended use case for this= >draft.) >> >>So the current document does introduce a new MitM vulnerability to MSRPS. > > Sessmatch does not change the fact that name based TLS authentication for= MSRPS > will fail if an SBC or ALG has modified the hostname value in the MSRP UR= I in the > SDP a=3Dpath attribute without also acting as MSRP B2BUA. > > > Comments from Ted > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>I join Richard in believing that this document makes changes beyond that = which >>could be understood as "updating" the MSRP URI scheme processing. >> >>... >> >>I also note that the security considerations, in addition to having some = fairly >>disingenuous language about the impact of this change, seems to fail to m= ention >>MSRPS URIs and what, if any, impact this would have on them. > > We will clarify what impacts there are. > > ------- > >>>>To highlight one particular aspect, RFC 4975 does not require >>>>session-ids to be present, a fact noted both in the ABNF and in this >>>>text: >>>> >>>>4. The session-id part is compared as case sensitive. =A0A URI without >>>> =A0 a session-id part is never equivalent to one that includes one. >>>> >>>>A matching scheme which relies on a URI section which is not >>>>guaranteed to be present has some interesting problems ahead of it. If >>>>this effectively makes their use mandatory, that requires a change to >>>>the fundamental ABNF and text. >>> >>>An MSRP URI in an SDP offer or answer for an MSRP session MUST include a >>>session-id part, so I believe the comment is >>>based on incorrect assumptions. >> >>This is not indicated in the URI matching section > > We will clarify that sessmatch conformant UAs do not use MSRP URI matchin= g in > order to perform MSRP session matching. > >>>Section 6 of RFC 4975 says: >>> >>>"The session-id part identifies a particular session of the >>>participant. The absence of the session-id >>>part indicates a reference to an MSRP host device, but does not refer to= a >>>particular session at that device." >>> >> >>The full section from which that quote is taken is: >> >> =A0 The MSRP URI authority field identifies a participant in a particula= r >> =A0 MSRP session. =A0If the authority field contains a numeric IP addres= s, >> =A0 it MUST also contain a port. =A0The session-id part identifies a >> =A0 particular session of the participant. =A0The absence of the session= -id >> =A0 part indicates a reference to an MSRP host device, but does not refe= r >> =A0 to a particular session at that device. =A0A particular value of >> =A0 session-id is only meaningful in the context of the associated >> =A0 authority; thus, the authority component can be thought of as >> =A0 identifying the "authority" governing a namespace for the session-id= . >> >>This proposal changes the concept of a namespace authority present in the= URI >>matching section of RFC 4975. I am sorry if my wry reference to this in m= y >>previous message was hard to follow; I should have known better. >> >>To be more plain, this proposal fundamentally changes the matching semant= ics of >>the URI set out in RFC 4975, by requiring a match on only a portion of th= e URI. >>At a bare minimum, this would require noting a normative update to sectio= n 6 >>and 6.1 of RFC 4975, which this draft does not do. =A0In reality, this is >>unlikely to be sufficient, as URI matching semantics do not generally hav= e the >>concept of ignoring the authority in providing a match (at least in my re= ading >>of the RFC 3986 "ladder of comparison" text). =A0That means you'd have to= special >>case the MSRP matching semantics, rather than have the URI be parsed and >>compared using a standard library. > > Sessmatch removes the URI matching as a means to do MSRP session matching= , and > replaces it with a pure session-id matching. There is no need to create a= new > URI scheme that does not re-use the authority component. We believe the m= inimum > 80-bit randomness of the session-id, together with the fact that the UA i= tself > generates the session-id it matches on, to be enough for the session-id t= o be > unique in the scope of the sessions that are active at the UA. > I still believe that this requires special-casing the MSRP URI handling in any libraries that are meant to parse and match URIs. There is always a cost and risk to= that kind of special-casing, and I remain less than convinced that using a URI here if you are not using URI matching makes much sense. > Also, the security of the matching is not particularly decreased, since i= t is > relatively easy to find out the authority name anyway. > >>>>I also note that the security considerations, in addition to having >>>>some fairly disingenuous language about the impact of this change, >>>>seems to fail to mention MSRPS URIs and what, if any, impact this >>>>would have on them. >>> >>>There are no impacts to MSRPS URIs. I assumed it would be implicitly und= erstood >>>since MSRPS URIs are not mentioned in the draft. >>> >>>However, we could explicitly make it clear by modifying the first senten= ces of >>>section 5: >>> >>>"The change of session matching procedure does not impact the format of = MSRP >>>URIs, disregarding if the "msrp" scheme or the "msrps" scheme is used. >>>However, MSRP endpoints can only check that the session-id part of the M= SRP >>>URI..." >>> >>This doesn't seem to me to actually work, based on Richard's comments, un= less >>what you mean to say is "if MSRPS is in use, nothing in this draft can be >>used". That gives you different matching semantics for MSRPS (authority m= ust >>be present and must be matched using TLS semantics) vs MSRP (only session= -id is >>checked) which is at the very least a violation of the principle of least >>surprise (no other foo over TLS protocol works that way that I know of ). > > Session matching is done when receiving MSRP packets on an already establ= ished TCP > or TCP/TLS connection, and there will not be any different session matchi= ng procedure > depending on if the connection uses TLS or plain TCP. > Thanks again for the clarifications, Ted > Regards, > > Christer > From fluffy@cisco.com Wed Sep 1 15:28:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 772B23A6964; Wed, 1 Sep 2010 15:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.056 X-Spam-Level: X-Spam-Status: No, score=-110.056 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGxx7DZo0auC; Wed, 1 Sep 2010 15:28:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 446DF3A6849; Wed, 1 Sep 2010 15:28:38 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIpwfkyrRN+J/2dsb2JhbACgcXGlCpwXgm0BgksEhD6FVop3MQ X-IronPort-AV: E=Sophos;i="4.56,306,1280707200"; d="scan'208";a="582036742" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 01 Sep 2010 22:29:08 +0000 Received: from dhcp-171-68-21-80.cisco.com (dhcp-171-68-21-80.cisco.com [171.68.21.80]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o81MT8Ud016801; Wed, 1 Sep 2010 22:29:08 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Cullen Jennings In-Reply-To: Date: Wed, 1 Sep 2010 15:29:07 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org, Ted Hardie , IESG IESG , The IETF , secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 22:28:40 -0000 Do these changes allow an SBC on the signaling path to change the = contents of the MSRP messages without the end points being able to = detect that? I'm sure it will be easier to answer this once we have a = new draft.=20 On Sep 1, 2010, at 9:53 , Ted Hardie wrote: > Hi Christer, >=20 > Thanks for your message and your consideration of the points I raised. > Given the > scope of changes below, my first suggestion is that the author team = actually > go ahead with a draft incorporating these changes, so that we can = discuss > based on the actual text. I also suspect that a second last call will > be necessary as > a result. >=20 > Some further discussion in-line. >=20 > On Tue, Aug 31, 2010 at 10:39 AM, Christer Holmberg > wrote: >> Hi, >>=20 >> The purpose of this e-mail is to address the secdir comments given by = Richard >> Barnes and Ted Hardie. Due to summer vacations, standardization = meetings >> etc it took a while to put the e-mail together, and we appologise for = that. >>=20 >> GENERAL >> =3D=3D=3D=3D=3D=3D=3D >>=20 >> First, the draft does NOT propose any changes to the TLS = authentication >> procedures =96 that will be clarified. The changes are only related = to the >> procedure for matching an incoming MSRP message to an MSRP session = that >> has been negotiated using SDP =96 once any TLS authentication = procedure has >> already taken place. >>=20 >> So, in case of TLS and name based authentication, if an SBC/ALG = modifies >> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the = current >> behavior, and sessmatch doesn=92t change that. >>=20 >> We understand that this fact needs to be clearly indicated in the = draft. >>=20 >> Basically sessmatch allows so that, when using peer to peer MSRP, SIP = SBCs >> and SIP aware firewalls can be in the SIP signaling path without = acting as >> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP = relays >> the SBC/ALG needs to act as MSRP B2BUA, as today. >>=20 >> Sessmatch aims to extend the usability of MSRP peer to peer = communication to >> scenarios where simple ALGs/SBCs are used, and at least in our = experience >> customer interest for standard MSRP has grown (from more or less = zero) >> dramatically due to sessmatch. And, OMA, which previously used a = *non-standard* >> version of MSRP (with no interoperability with standard MSRP), has = also agreed >> to switch to sessmatch (even if it required a number of changes in = their >> specifications). >>=20 >> Second, the intention of sessmatch is not to modify the MSRP URI = matching rules, >> but rather to not use MSRP URI matching for session matching. >>=20 >=20 > This is the key point in your message, at least from my perspective. > This basically > means that all of section 6 of RFC 4975, which clearly describes those = URIs > as the session identifiers: >=20 > URIs using the "msrp" and "msrps" schemes are used to identify a > session of instant messages at a particular MSRP device, as well as > to identify an MSRP relay in general. >=20 > needs to be replaced and all the logic that depends on it must be > reviewed. The current > draft does not indicate that section 6 is being normatively updated, > and yet this is the > key point of the work. You are moving from a namespace-scoped = identifier to an > unscoped identifier, and you will require both justifications of that > (some given below) > and mechanics for that described in more detail. In particular, I do > not believe it > is clear in the discussion so far whether the identifier may ever be > scoped by the authority section > of the URI or whether it is always treated as unscoped. If the > latter, it is unclear to me > whether the right notion here isn't simply to create a new non-URI = identifier. >=20 >=20 >=20 >> Please also note that when we talk about SBCs/ALGs, we refer to = entities that >> normally do NOT have the capability to act as MSRP B2BUAs. >>=20 >> We will comment the individual comments based on the assumptions = above. >>=20 >>=20 >> Comments from Richard >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=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 >>> This document changes the URI matching algorithm used in MSRP. MSRP = sessions >>> are typically initiated using SDP bodies in SIP. These SDP >>> bodies contain MSRP URIs that the peers use to contact each other. >>> When one peer receives a request to initiate a session, he verifies = that the >>> URI being requested is one that he initiated in SDP, thereby using = the URI as a >>> shared secret to authenticate that the originator of the session = actually >>> received the SDP body in question. >>>=20 >>> According to the current SDP specification, this comparison is = performed over >>> the whole URI; this document restricts the comparison to the = "session-id" >>> component, omitting the host, port, and transport components. The = goal of the >>> document is to facilitate a certain class of man-in-the-middle = attack, namely >>> to allow a signaling intermediary to insert a media intermediary. = The >>> restriction on the URI comparison is needed in order for the media = intermediary >>> not to have to modify URIs in MSRP packets to reflect the = modifications to URIs >>> in SDP bodies performed to redirect traffic through the media = intermediary. >>=20 >> When an MSRP UA receives an MSRP packet it performs msrp session = matching in order >> to verify that the msrp packet belongs to an existing SDP negotiated = msrp session >> at the UA. RFC4975 prescribes that URI matching should be used for = session matching. >> We argue that the namespace scoping of the session-id values that use = of URI matching >> brings is unnecessary. The 80-bit randomness of the session-id and = the fact that it >> was the UA itself that decided on the session-id value and can ensure = that it is >> unique within the UA makes the session-id sufficiently unique for = session matching. >> Sessmatch is not changing the MSRP URI matching algorithm, it is = changing the session >> matching algorithm not to use MSRP URI matching. >>=20 >=20 > Please clarify in what contexts MSRP URI matching would then occur. >=20 >=20 >>> I have a few significant reservations about this document: >>>=20 >>> 1) This extension makes it more difficult for MSRP entities to = secure their >>> communications against attackers in the signaling path. The current = model >>> provides a basic integrity protection, in that signaling = intermediaries cannot >>> redirect traffic to an arbitrary third party; they must at least = advise the >>> third party about how to modify MSRP packets. The proposed = modification would >>> remove even this cost. >>=20 >> If we do not introduce the sessmatch change then the only alternative = for MSRP >> connections to be able to be set up when SBCs or SIP aware firewalls = are in the >> SIP signaling path is for these to introduce MSRP B2BUA support. This = is probably >> not feasible for most SBCs and SIP aware firewalls, and if it = actually were >> feasible then it would mean as big a security problem, or even = bigger, than >> sessmatch. The choice is thus to not use MSRP at all in presence of = such devices >> or to introduce sessmatch. Not to fix this probably would mean that = use of MSRP >> will be marginalized. >>=20 >=20 >>> 2) Moreover, it raises the cost of providing integrity protection to = messages, >>> since Alice must now employ both integrity and confidentiality = protections on >>> an end-to-end basis; if her messages are only integrity-protected, = then a proxy >>> can remove the integrity protection and redirect traffic without it = being >>> observable to Alice. >>>=20 >>> The document needs to clarify what the impacts are for = authentication in secure >>> modes of MSRP. In particular: >>> -- The distinction between "self-signed" and "public" certificates = is >>> inappropriate. The proper distinction is between the name-based = authentication >>> in Section 14.2 of RFC 4975 and the fingerprint-based authentication = in Section >>> 14.4. >>=20 >> We cannot find the terminology =93name-based=94 authentication in RFC = 4975. The RFC talks >> about TLS authentication using either certificates from well-known = certificate >> authorities, or using self-signed certificates together with = certificate fingerprints. >>=20 >> Having said that, however, we DO agree that the terminology you = suggest is more >> appropriate than what we have used and we will introduce this = terminology and explain >> it in the Convention section of the sessmatch draft. >>=20 >>> -- In either case, changing the host name need not result in an = authentication >>> failure, since the media intermediary can simply authenticate as = itself to both >>> endpoints, having changed the respective MSRP URIs appropriately. >>=20 >> A media intermediary can only do this if it is an MSRP B2BUA, and = sessmatch was >> introduced just to avoid most SBCs and ALGs having to implement an = MSRP B2BUA in order >> to allow standard MSRP deployment. >>=20 >>> -- There is currently no requirement that an endpoint identity in = the To-Path >>> URI matches the endpoint identity authenticated at the TLS layer, = because these >>> two are required to be the same. This document changes that = assumption, and >>> should note that these two identities can differ. >>=20 >> We will explicitly mention this. >>=20 >>> The document also precludes any name-based multiplexing, where a = single MSRP >>> process (single IP address and port) directs requests to different = virtual >>> recipients based on the domain name in the To-Path header. (In = analogy to >>> Host-based multiplexing in HTTP, which is very widely deployed.) = Since with >>> this extension, the domain in the To- Path is completely = unpredictable from the >>> recipient's perspective, it is useless to the recipient. >>=20 >> That is correct, but there should be no problem for a single MSRP = process (single >> IP address and port) to direct requests to different virtual = recipients - based >> on the session-id instead. It is only needed for the different = virtual recipients >> to inform the receiver process on which session-ids that are = currently negotiated >> instead of informing it on which domain name the virtual recipient = shall be >> associated with. >>=20 >>> The document has no backward-compatibility. MSRP implementations = that do not >>> support this extension will not be able to receive MSRP sessions = from >>> implementations that do. In that regard, this document seems more = like a new >>> version of MSRP rather than an update. >>=20 >> It is not true that there is no backwards compatibility. If there are = no >> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem = for MSRP >> implementations that do not support the sessmatch extension to = receive MSRP >> sessions from implementations that do. >>=20 >> MSRP implementations that do not support the sessmatch extension are = however not >> able to establish MSRP end to end conversations if there are = ALGs/SBCs in the >> session path (unless these implement MSRP B2BUA) and sessmatch does = not change this >> fact =96 it will not work disregarding if the other endpoint supports = sessmatch or not. >>=20 >=20 > I do not believe the document describes this scenario. In particular, > the document > should discuss what happens when an MSRP implementation that believes = it should > use MSRP URI matching interacts with an implementation that is using > this matching. >=20 > Frankly, I think this supports the idea of using a straight > token-based identifier, rather > than a portion of the URI. The scope for confusion is much smaller. >=20 >>>>> I also note that the security considerations, in addition to = having >>>>> some fairly disingenuous language about the impact of this change, >>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>> would have on them. >>>>=20 >>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly >>>> understood since MSRPS URIs are not mentioned in the draft. >>>>=20 >>>> However, we could explicitly make it clear by modifying the first >>>> sentences of section 5: >>>>=20 >>>> "The change of session matching procedure does not impact the >>>> format of MSRP URIs, disregarding if the "msrp" scheme or the = "msrps" scheme >>>> is used. However, MSRP endpoints can only check that the session-id = part of >>>> the MSRP URI..." >>>=20 >>> The conflict here is that with MRSPS authentication, the name in the >>> certificate is checked against the domain name in the URI, which was = OK when >>> the URI in the message was required to be the same. By allowing the = domain >>> name in the message to change, this draft removes man-in-the-middle = protection >>> from MSRPS. >>>=20 >>> The document notes that a SIP MitM can already direct the user to = another >>> destination. However, if the peers use MSRPS with the current = authentication >>> scheme, the MitM will not be able to be a part of the resulting = MSRPS session, >>> since he can't authenticate as one of the endpoints. If only the = session ID is >>> used in comparisons, the MitM can patch himself in by changing the = domain in >>> the MSRPS URI. (Which actually seems to be the intended use case for = this >draft.) >>>=20 >>> So the current document does introduce a new MitM vulnerability to = MSRPS. >>=20 >> Sessmatch does not change the fact that name based TLS authentication = for MSRPS >> will fail if an SBC or ALG has modified the hostname value in the = MSRP URI in the >> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >>=20 >>=20 >> Comments from Ted >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >>> I join Richard in believing that this document makes changes beyond = that which >>> could be understood as "updating" the MSRP URI scheme processing. >>>=20 >>> ... >>>=20 >>> I also note that the security considerations, in addition to having = some fairly >>> disingenuous language about the impact of this change, seems to fail = to mention >>> MSRPS URIs and what, if any, impact this would have on them. >>=20 >> We will clarify what impacts there are. >>=20 >> ------- >>=20 >>>>> To highlight one particular aspect, RFC 4975 does not require >>>>> session-ids to be present, a fact noted both in the ABNF and in = this >>>>> text: >>>>>=20 >>>>> 4. The session-id part is compared as case sensitive. A URI = without >>>>> a session-id part is never equivalent to one that includes one. >>>>>=20 >>>>> A matching scheme which relies on a URI section which is not >>>>> guaranteed to be present has some interesting problems ahead of = it. If >>>>> this effectively makes their use mandatory, that requires a change = to >>>>> the fundamental ABNF and text. >>>>=20 >>>> An MSRP URI in an SDP offer or answer for an MSRP session MUST = include a >>>> session-id part, so I believe the comment is >>>> based on incorrect assumptions. >>>=20 >>> This is not indicated in the URI matching section >>=20 >> We will clarify that sessmatch conformant UAs do not use MSRP URI = matching in >> order to perform MSRP session matching. >>=20 >>>> Section 6 of RFC 4975 says: >>>>=20 >>>> "The session-id part identifies a particular session of the >>>> participant. The absence of the session-id >>>> part indicates a reference to an MSRP host device, but does not = refer to a >>>> particular session at that device." >>>>=20 >>>=20 >>> The full section from which that quote is taken is: >>>=20 >>> The MSRP URI authority field identifies a participant in a = particular >>> MSRP session. If the authority field contains a numeric IP = address, >>> it MUST also contain a port. The session-id part identifies a >>> particular session of the participant. The absence of the = session-id >>> part indicates a reference to an MSRP host device, but does not = refer >>> to a particular session at that device. A particular value of >>> session-id is only meaningful in the context of the associated >>> authority; thus, the authority component can be thought of as >>> identifying the "authority" governing a namespace for the = session-id. >>>=20 >>> This proposal changes the concept of a namespace authority present = in the URI >>> matching section of RFC 4975. I am sorry if my wry reference to this = in my >>> previous message was hard to follow; I should have known better. >>>=20 >>> To be more plain, this proposal fundamentally changes the matching = semantics of >>> the URI set out in RFC 4975, by requiring a match on only a portion = of the URI. >>> At a bare minimum, this would require noting a normative update to = section 6 >>> and 6.1 of RFC 4975, which this draft does not do. In reality, this = is >>> unlikely to be sufficient, as URI matching semantics do not = generally have the >>> concept of ignoring the authority in providing a match (at least in = my reading >>> of the RFC 3986 "ladder of comparison" text). That means you'd have = to special >>> case the MSRP matching semantics, rather than have the URI be parsed = and >>> compared using a standard library. >>=20 >> Sessmatch removes the URI matching as a means to do MSRP session = matching, and >> replaces it with a pure session-id matching. There is no need to = create a new >> URI scheme that does not re-use the authority component. We believe = the minimum >> 80-bit randomness of the session-id, together with the fact that the = UA itself >> generates the session-id it matches on, to be enough for the = session-id to be >> unique in the scope of the sessions that are active at the UA. >>=20 >=20 > I still believe that this requires special-casing the MSRP URI > handling in any libraries > that are meant to parse and match URIs. There is always a cost and = risk to that > kind of special-casing, and I remain less than convinced that using a > URI here if > you are not using URI matching makes much sense. >=20 >=20 >=20 >> Also, the security of the matching is not particularly decreased, = since it is >> relatively easy to find out the authority name anyway. >>=20 >>>>> I also note that the security considerations, in addition to = having >>>>> some fairly disingenuous language about the impact of this change, >>>>> seems to fail to mention MSRPS URIs and what, if any, impact this >>>>> would have on them. >>>>=20 >>>> There are no impacts to MSRPS URIs. I assumed it would be = implicitly understood >>>> since MSRPS URIs are not mentioned in the draft. >>>>=20 >>>> However, we could explicitly make it clear by modifying the first = sentences of >>>> section 5: >>>>=20 >>>> "The change of session matching procedure does not impact the = format of MSRP >>>> URIs, disregarding if the "msrp" scheme or the "msrps" scheme is = used. >>>> However, MSRP endpoints can only check that the session-id part of = the MSRP >>>> URI..." >>>>=20 >>> This doesn't seem to me to actually work, based on Richard's = comments, unless >>> what you mean to say is "if MSRPS is in use, nothing in this draft = can be >>> used". That gives you different matching semantics for MSRPS = (authority must >>> be present and must be matched using TLS semantics) vs MSRP (only = session-id is >>> checked) which is at the very least a violation of the principle of = least >>> surprise (no other foo over TLS protocol works that way that I know = of ). >>=20 >> Session matching is done when receiving MSRP packets on an already = established TCP >> or TCP/TLS connection, and there will not be any different session = matching procedure >> depending on if the connection uses TLS or plain TCP. >>=20 >=20 > Thanks again for the clarifications, >=20 > Ted >=20 >=20 >> Regards, >>=20 >> Christer >>=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From bew@cisco.com Wed Sep 1 16:51:42 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F473A67EF; Wed, 1 Sep 2010 16:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC3qvv0tRcDA; Wed, 1 Sep 2010 16:51:41 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 75D6A3A67DB; Wed, 1 Sep 2010 16:51:41 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADuEfkyrR7Hu/2dsb2JhbACgdnGlBZwXhTkEhD6FVg X-IronPort-AV: E=Sophos;i="4.56,306,1280707200"; d="scan'208";a="357392173" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 01 Sep 2010 23:52:11 +0000 Received: from dhcp-128-107-105-29.cisco.com (dhcp-128-107-105-29.cisco.com [128.107.105.29]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o81NqBFs028569; Wed, 1 Sep 2010 23:52:11 GMT Message-Id: <6D149E99-3A9D-49D5-AACE-4C3253BF6625@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 1 Sep 2010 16:52:04 -0700 X-Mailer: Apple Mail (2.936) Cc: draft-daboo-srv-caldav@tools.ietf.org Subject: [secdir] Secdir review of draft-daboo-srv-caldav-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Sep 2010 23:51:42 -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 review comments. This document describes new DNS SRV service types for the CalDAV protocol, and a bootstrapping method by which clients can find CalDAV servers. There's not much that is security critical in the document. The security considerations section seems sufficient. I do not see the need for any changes. Brian From christer.holmberg@ericsson.com Thu Sep 2 06:20:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3AED3A696F; Thu, 2 Sep 2010 06:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.032 X-Spam-Level: X-Spam-Status: No, score=-5.032 tagged_above=-999 required=5 tests=[AWL=0.967, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJz62jrICDo9; Thu, 2 Sep 2010 06:20:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B65323A688C; Thu, 2 Sep 2010 06:20:44 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-b6-4c7fa4c9d67d Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B3.B4.10125.9C4AF7C4; Thu, 2 Sep 2010 15:21:13 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 2 Sep 2010 15:21:12 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 2 Sep 2010 15:20:56 +0200 From: Christer Holmberg To: Ted Hardie Date: Thu, 2 Sep 2010 15:20:56 +0200 Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch Thread-Index: ActJ9iStdrOdUiu4RiyE/DJwje67EgAqUQpk Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585015BCA3F@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se>, 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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: The IETF , "secdir@ietf.org" , "ben@estacado.net" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:20:47 -0000 Hi Ted, Comments inline. >Thanks for your message and your consideration of the points I raised. >Given the scope of changes below, my first suggestion is that the author t= eam actually >go ahead with a draft incorporating these changes, so that we can discuss >based on the actual text. I also suspect that a second last call will be = necessary as >a result. Yes, we intend to do that. >> GENERAL >> =3D=3D=3D=3D=3D=3D=3D >> >> First, the draft does NOT propose any changes to the TLS authentication >> procedures =96 that will be clarified. The changes are only related to t= he >> procedure for matching an incoming MSRP message to an MSRP session that >> has been negotiated using SDP =96 once any TLS authentication procedure = has >> already taken place. >> >> So, in case of TLS and name based authentication, if an SBC/ALG modifies >> the a=3Dpath MSRP URI, the TLS authentication WILL fail. That is the cur= rent >> behavior, and sessmatch doesn=92t change that. >> >> We understand that this fact needs to be clearly indicated in the draft. >> >> Basically sessmatch allows so that, when using peer to peer MSRP, SIP SB= Cs >> and SIP aware firewalls can be in the SIP signaling path without acting = as >> MSRP B2BUAs. But, for an SBC or ALG to interwork correctly with MSRP rel= ays >> the SBC/ALG needs to act as MSRP B2BUA, as today. >> >> Sessmatch aims to extend the usability of MSRP peer to peer communicatio= n to >> scenarios where simple ALGs/SBCs are used, and at least in our experienc= e >> customer interest for standard MSRP has grown (from more or less zero) >> dramatically due to sessmatch. And, OMA, which previously used a *non-st= andard* >> version of MSRP (with no interoperability with standard MSRP), has also = agreed >> to switch to sessmatch (even if it required a number of changes in their >> specifications). >> >> Second, the intention of sessmatch is not to modify the MSRP URI matchin= g rules, >> but rather to not use MSRP URI matching for session matching. >> > >This is the key point in your message, at least from my perspective. >This basically means that all of section 6 of RFC 4975, which clearly desc= ribes those URIs >as the session identifiers: > > > URIs using the "msrp" and "msrps" schemes are used to identify a > session of instant messages at a particular MSRP device, as well as > to identify an MSRP relay in general. > >needs to be replaced and all the logic that depends on it must be reviewed= . The current >draft does not indicate that section 6 is being normatively updated, >and yet this is the key point of the work. You are moving from a namespac= e-scoped identifier to an >unscoped identifier, and you will require both justifications of that (som= e given below) >and mechanics for that described in more detail. Section 6 does also say: "The session-id part identifies a particular session of the participant." ...and: "The authority component will typically not contain a userinfo component, but MAY do so to indicate a user account for which the session is valid. Note that this is not the same thing as identifying the = session itself." So, I guess some additional text regarding the userinfo component might be = needed. We'll look into it. >In particular, I do not believe it is clear in the discussion so far wheth= er the identifier may ever be scoped by the authority section >of the URI or whether it is always treated as unscoped. If the latter, it= is unclear to me >whether the right notion here isn't simply to create a new non-URI identif= ier. Well, that would not be backward comaptible, would it? As we said, as long = as there are no SBCs in the path, sessmatch is fully backward compatible wi= th RFC 4975. Of course, we could define a new MSRP message element, but wouldn't we then= also need an option-tag in order to require the remote endpoint to support= it? >> Please also note that when we talk about SBCs/ALGs, we refer to entities= that >> normally do NOT have the capability to act as MSRP B2BUAs. >> >> We will comment the individual comments based on the assumptions above. >> >> >> Comments from Richard >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>>I have reviewed this document as part of the security directorate's ongo= ing >>>effort to review all IETF documents being processed by the IESG. These >>>comments were written primarily for the benefit of the security area dir= ectors. >>>Document editors and WG chairs should treat these comments just like any= other >>>last call comments. >>> >>>This document changes the URI matching algorithm used in MSRP. MSRP ses= sions >>>are typically initiated using SDP bodies in SIP. These SDP >>>bodies contain MSRP URIs that the peers use to contact each other. >>>When one peer receives a request to initiate a session, he verifies that= the >>>URI being requested is one that he initiated in SDP, thereby using the U= RI as a >>>shared secret to authenticate that the originator of the session actuall= y >>>received the SDP body in question. >>> >>>According to the current SDP specification, this comparison is performed= over >>>the whole URI; this document restricts the comparison to the "session-id= " >>>component, omitting the host, port, and transport components. The goal = of the >>>document is to facilitate a certain class of man-in-the-middle attack, n= amely >>>to allow a signaling intermediary to insert a media intermediary. The >>>restriction on the URI comparison is needed in order for the media inter= mediary >>>not to have to modify URIs in MSRP packets to reflect the modifications = to URIs >>>in SDP bodies performed to redirect traffic through the media intermedia= ry. >> >> When an MSRP UA receives an MSRP packet it performs msrp session matchin= g in order >> to verify that the msrp packet belongs to an existing SDP negotiated msr= p session >> at the UA. RFC4975 prescribes that URI matching should be used for sessi= on matching. >> We argue that the namespace scoping of the session-id values that use of= URI matching >> brings is unnecessary. The 80-bit randomness of the session-id and the f= act that it >> was the UA itself that decided on the session-id value and can ensure th= at it is >> unique within the UA makes the session-id sufficiently unique for sessio= n matching. >> Sessmatch is not changing the MSRP URI matching algorithm, it is changin= g the session >> matching algorithm not to use MSRP URI matching. > > >Please clarify in what contexts MSRP URI matching would then occur. I am not sure whether it actually would occur :) We'll look into that. However, in any case I think it always good to specify the matching rules f= or the scheme, in case it will be needed at some point. >>>I have a few significant reservations about this document: >>> >>>1) This extension makes it more difficult for MSRP entities to secure th= eir >>>communications against attackers in the signaling path. The current mod= el >>>provides a basic integrity protection, in that signaling intermediaries = cannot >>>redirect traffic to an arbitrary third party; they must at least advise = the >>>third party about how to modify MSRP packets. The proposed modification = would >>>remove even this cost. >> >> If we do not introduce the sessmatch change then the only alternative fo= r MSRP >> connections to be able to be set up when SBCs or SIP aware firewalls are= in the >> SIP signaling path is for these to introduce MSRP B2BUA support. This is= probably >> not feasible for most SBCs and SIP aware firewalls, and if it actually w= ere >> feasible then it would mean as big a security problem, or even bigger, t= han >> sessmatch. The choice is thus to not use MSRP at all in presence of such= devices >> or to introduce sessmatch. Not to fix this probably would mean that use = of MSRP >> will be marginalized. >> >> >>>2) Moreover, it raises the cost of providing integrity protection to mes= sages, >>>since Alice must now employ both integrity and confidentiality protectio= ns on >>>an end-to-end basis; if her messages are only integrity-protected, then = a proxy >>>can remove the integrity protection and redirect traffic without it bein= g >>>observable to Alice. >>> >>>The document needs to clarify what the impacts are for authentication in= secure >>>modes of MSRP. In particular: >>>-- The distinction between "self-signed" and "public" certificates is >>>inappropriate. The proper distinction is between the name-based authent= ication >>>in Section 14.2 of RFC 4975 and the fingerprint-based authentication in = Section >>>14.4. >> >> We cannot find the terminology =93name-based=94 authentication in RFC 49= 75. The RFC talks >> about TLS authentication using either certificates from well-known certi= ficate >> authorities, or using self-signed certificates together with certificate= fingerprints. >> >> Having said that, however, we DO agree that the terminology you suggest = is more >> appropriate than what we have used and we will introduce this terminolog= y and explain >> it in the Convention section of the sessmatch draft. >> >>>-- In either case, changing the host name need not result in an authenti= cation >>>failure, since the media intermediary can simply authenticate as itself = to both >>>endpoints, having changed the respective MSRP URIs appropriately. >> >> A media intermediary can only do this if it is an MSRP B2BUA, and sessma= tch was >> introduced just to avoid most SBCs and ALGs having to implement an MSRP = B2BUA in order >> to allow standard MSRP deployment. >> >>>-- There is currently no requirement that an endpoint identity in the To= -Path >>>URI matches the endpoint identity authenticated at the TLS layer, becaus= e these >>>two are required to be the same. This document changes that assumption,= and >>>should note that these two identities can differ. >> >> We will explicitly mention this. >> >>>The document also precludes any name-based multiplexing, where a single = MSRP >>>process (single IP address and port) directs requests to different virtu= al >>>recipients based on the domain name in the To-Path header. (In analogy t= o >>>Host-based multiplexing in HTTP, which is very widely deployed.) Since w= ith >>>this extension, the domain in the To- Path is completely unpredictable f= rom the >>>recipient's perspective, it is useless to the recipient. >> >> That is correct, but there should be no problem for a single MSRP proces= s (single >> IP address and port) to direct requests to different virtual recipients = - based >> on the session-id instead. It is only needed for the different virtual r= ecipients >> to inform the receiver process on which session-ids that are currently n= egotiated >> instead of informing it on which domain name the virtual recipient shall= be >> associated with. >> >>>The document has no backward-compatibility. MSRP implementations that do= not >>>support this extension will not be able to receive MSRP sessions from >>>implementations that do. In that regard, this document seems more like a= new >>>version of MSRP rather than an update. >> >> It is not true that there is no backwards compatibility. If there are no >> SIP ALGs/SBCs in the SIP/SDP signalling path then there is no problem fo= r MSRP >> implementations that do not support the sessmatch extension to receive M= SRP >> sessions from implementations that do. >> >> MSRP implementations that do not support the sessmatch extension are how= ever not >> able to establish MSRP end to end conversations if there are ALGs/SBCs i= n the >> session path (unless these implement MSRP B2BUA) and sessmatch does not = change this >> fact =96 it will not work disregarding if the other endpoint supports se= ssmatch or not. >> > >I do not believe the document describes this scenario. In particular, the= document >should discuss what happens when an MSRP implementation that believes it s= hould >use MSRP URI matching interacts with an implementation that is using >this matching. We'll put together some text about that. >Frankly, I think this supports the idea of using a straight token-based id= entifier, rather >than a portion of the URI. The scope for confusion is much smaller. I am not arguing against that.. But, again, backward compability. >>>>>I also note that the security considerations, in addition to having >>>>>some fairly disingenuous language about the impact of this change, >>>>>seems to fail to mention MSRPS URIs and what, if any, impact this >>>>>would have on them. >>>> >>>>There are no impacts to MSRPS URIs. I assumed it would be implicitly >>>>understood since MSRPS URIs are not mentioned in the draft. >>>> >>>>However, we could explicitly make it clear by modifying the first >>>>sentences of section 5: >>>> >>>>"The change of session matching procedure does not impact the >>>>format of MSRP URIs, disregarding if the "msrp" scheme or the "msrps" s= cheme >>>>is used. However, MSRP endpoints can only check that the session-id par= t of >>>>the MSRP URI..." >>> >>>The conflict here is that with MRSPS authentication, the name in the >>>certificate is checked against the domain name in the URI, which was OK = when >>>the URI in the message was required to be the same. By allowing the doma= in >>>name in the message to change, this draft removes man-in-the-middle prot= ection >>>from MSRPS. >>> >>>The document notes that a SIP MitM can already direct the user to anothe= r >>>destination. However, if the peers use MSRPS with the current authentic= ation >>>scheme, the MitM will not be able to be a part of the resulting MSRPS se= ssion, >>>since he can't authenticate as one of the endpoints. If only the session= ID is >>>used in comparisons, the MitM can patch himself in by changing the domai= n in >>>the MSRPS URI. (Which actually seems to be the intended use case for thi= s >draft.) >>> >>>So the current document does introduce a new MitM vulnerability to MSRPS= . >> >> Sessmatch does not change the fact that name based TLS authentication fo= r MSRPS >> will fail if an SBC or ALG has modified the hostname value in the MSRP U= RI in the >> SDP a=3Dpath attribute without also acting as MSRP B2BUA. >> >> >> Comments from Ted >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>>I join Richard in believing that this document makes changes beyond that= which >>>could be understood as "updating" the MSRP URI scheme processing. >>> >>>... >>> >>>I also note that the security considerations, in addition to having some= fairly >>>disingenuous language about the impact of this change, seems to fail to = mention >>>MSRPS URIs and what, if any, impact this would have on them. >> >> We will clarify what impacts there are. >> >> ------- >> >>>>>To highlight one particular aspect, RFC 4975 does not require >>>>>session-ids to be present, a fact noted both in the ABNF and in this >>>>>text: >>>>> >>>>>4. The session-id part is compared as case sensitive. A URI without >>>>> a session-id part is never equivalent to one that includes one. >>>>> >>>>>A matching scheme which relies on a URI section which is not >>>>>guaranteed to be present has some interesting problems ahead of it. If >>>>>this effectively makes their use mandatory, that requires a change to >>>>>the fundamental ABNF and text. >>>> >>>>An MSRP URI in an SDP offer or answer for an MSRP session MUST include = a >>>>session-id part, so I believe the comment is >>>>based on incorrect assumptions. >>> >>>This is not indicated in the URI matching section >> >> We will clarify that sessmatch conformant UAs do not use MSRP URI matchi= ng in >> order to perform MSRP session matching. >> >>>>Section 6 of RFC 4975 says: >>>> >>>>"The session-id part identifies a particular session of the >>>>participant. The absence of the session-id >>>>part indicates a reference to an MSRP host device, but does not refer t= o a >>>>particular session at that device." >>>> >>> >>>The full section from which that quote is taken is: >>> >>> The MSRP URI authority field identifies a participant in a particular >>> MSRP session. If the authority field contains a numeric IP address, >>> it MUST also contain a port. The session-id part identifies a >>> particular session of the participant. The absence of the session-id >>> part indicates a reference to an MSRP host device, but does not refer >>> to a particular session at that device. A particular value of >>> session-id is only meaningful in the context of the associated >>> authority; thus, the authority component can be thought of as >>> identifying the "authority" governing a namespace for the session-id. >>> >>>This proposal changes the concept of a namespace authority present in th= e URI >>>matching section of RFC 4975. I am sorry if my wry reference to this in = my >>>previous message was hard to follow; I should have known better. >>> >>>To be more plain, this proposal fundamentally changes the matching seman= tics of >>>the URI set out in RFC 4975, by requiring a match on only a portion of t= he URI. >>>At a bare minimum, this would require noting a normative update to secti= on 6 >>>and 6.1 of RFC 4975, which this draft does not do. In reality, this is >>>unlikely to be sufficient, as URI matching semantics do not generally ha= ve the >>>concept of ignoring the authority in providing a match (at least in my r= eading >>>of the RFC 3986 "ladder of comparison" text). That means you'd have to = special >>>case the MSRP matching semantics, rather than have the URI be parsed and >>>compared using a standard library. >>> >> Sessmatch removes the URI matching as a means to do MSRP session matchin= g, and >> replaces it with a pure session-id matching. There is no need to create = a new >> URI scheme that does not re-use the authority component. We believe the = minimum >> 80-bit randomness of the session-id, together with the fact that the UA = itself >> generates the session-id it matches on, to be enough for the session-id = to be >> unique in the scope of the sessions that are active at the UA. >> > >I still believe that this requires special-casing the MSRP URI handling in= any libraries >that are meant to parse and match URIs. There is always a cost and risk t= o that >kind of special-casing, and I remain less than convinced that using a URI = here if >you are not using URI matching makes much sense. Backward compability... Regards, Christer From christer.holmberg@ericsson.com Thu Sep 2 06:37:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 221543A6A4E; Thu, 2 Sep 2010 06:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.385 X-Spam-Level: X-Spam-Status: No, score=-5.385 tagged_above=-999 required=5 tests=[AWL=1.214, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOi88YI-fdee; Thu, 2 Sep 2010 06:37:10 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D50C93A6A3A; Thu, 2 Sep 2010 06:37:05 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-2d-4c7fa89f90f3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.F6.10125.F98AF7C4; Thu, 2 Sep 2010 15:37:35 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 2 Sep 2010 15:37:34 +0200 Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Thu, 2 Sep 2010 15:37:14 +0200 From: Christer Holmberg To: Cullen Jennings Date: Thu, 2 Sep 2010 15:37:13 +0200 Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch Thread-Index: ActKJRpLF8znua99QcmgUXxWHpwH5gAfOm5r Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> , 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 X-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , Ted Hardie , IESG IESG , The IETF , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:37:12 -0000 Hi Cullen, >Do these changes allow an SBC on the signaling path to change the contents= of the MSRP messages=20 >without the end points being able to detect that? I'm sure it will be easi= er to answer this once we have=20 >a new draft. Sessmatch does not make it any easier for an SBC in the signalling path to = change the content of the MSRP messages.=20 For an SBC to do MSRP message modification it will have to implement MSRP B= 2BUA functionality - no matter if sessmatch is supported by the endpionts o= r not. Regards, Christer= From cyrus@daboo.name Thu Sep 2 06:59:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5FF03A696F; Thu, 2 Sep 2010 06:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A-vZXt8ZMfJN; Thu, 2 Sep 2010 06:59:10 -0700 (PDT) Received: from daboo.name (daboo.name [151.201.22.177]) by core3.amsl.com (Postfix) with ESMTP id B12373A68EA; Thu, 2 Sep 2010 06:59:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by daboo.name (Postfix) with ESMTP id 28917190FDCB3; Thu, 2 Sep 2010 09:59:39 -0400 (EDT) X-Virus-Scanned: amavisd-new at daboo.name Received: from daboo.name ([127.0.0.1]) by localhost (chewy.mulberrymail.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j0xQ2kDWJ20; Thu, 2 Sep 2010 09:59:38 -0400 (EDT) Received: from [17.101.35.28] (unknown [209.83.188.140]) by daboo.name (Postfix) with ESMTPSA id C5964190FDCA7; Thu, 2 Sep 2010 09:59:36 -0400 (EDT) Date: Thu, 02 Sep 2010 09:59:34 -0400 From: Cyrus Daboo To: Brian Weis , secdir@ietf.org, iesg@ietf.org Message-ID: In-Reply-To: <6D149E99-3A9D-49D5-AACE-4C3253BF6625@cisco.com> References: <6D149E99-3A9D-49D5-AACE-4C3253BF6625@cisco.com> X-Mailer: Mulberry/4.1.0a1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline; size=776 Cc: draft-daboo-srv-caldav@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-daboo-srv-caldav-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 13:59:11 -0000 Hi Brian, --On September 1, 2010 4:52:04 PM -0700 Brian Weis 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 review comments. > > This document describes new DNS SRV service types for the CalDAV > protocol, and a bootstrapping method by which clients can find CalDAV > servers. There's not much that is security critical in the document. The > security considerations section seems sufficient. I do not see the need > for any changes. Thanks for doing the review. -- Cyrus Daboo From hilarie@purplestreak.com Thu Sep 2 16:39:31 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B19D93A677C; Thu, 2 Sep 2010 16:39:31 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U4B+isninfT; Thu, 2 Sep 2010 16:39:29 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 6AAA83A65A6; Thu, 2 Sep 2010 16:39:29 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OrJNt-0007hG-Jy; Thu, 02 Sep 2010 17:39:57 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OrJNr-0007iu-Aw; Thu, 02 Sep 2010 17:39:57 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o82NdBEX027379; Thu, 2 Sep 2010 17:39:11 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o82NdAic027378; Thu, 2 Sep 2010 17:39:10 -0600 Date: Thu, 2 Sep 2010 17:39:10 -0600 Message-Id: <201009022339.o82NdAic027378@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: Alexey.Melnikov@isode.com 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; sa04 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Alexey.Melnikov@isode.com 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) Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 02 Sep 2010 23:39:32 -0000 Security review of draft-ietf-calsify-rfc2447bis-10 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 review comments. The document describes the "iCalendar Message-Based Interoperability Protocol (iMIP)", a protocol for transmitting calendar events over SMTP. The security considerations are tied to authenticating the entity with the role of "Organizer" or "Attendee". The authentication relies on MIME security for attaching signatures and public key certificates. The SMTP sender is not relevant to the authentication. I'm slightly puzzled by the first step listed in "Security Considerations" about the steps needed to perform authentication. 1. Using the security mechanism compliant with [RFC-1847], determine who signed the email message containing the iCalendar object. This is the "signer". Note that the signer is not necessarily the person sending an e-mail message since an e-mail message can be forwarded. The confusion stems from the phrases "who signed the email message" and "the person sending". Would "who signed the MIME calendar part" and "the SMTP message sender" be more accurate? I think that MIME allows each part to have a different signer, and I think the protocol anticipates having MIME parts separated from the original SMTP message and forwarded in a different SMTP message. If that's the case, the rephrasing would make sense to me. There is an obvious slippery slope in the iCal "sent-by" parameter. It conflicts with the "organizer". The receiver is left with a dilemna: to authenticate wrt to the "sent-by" entity, or to insist on a signature by the "organizer". It seems to me that the "organizer" could have signed the event (including the "sent-by" parameter) in advance and given the MIME parts to the sender, so there is no need to trust the "sent-by" entity. Or, the receiver could have a list of trusted proxies in its local security policy. But, in general, I think that an event signed by an unknown or untrusted party should be given no special considertion --- it is the same as receiving an unsigned event, and "sent-by" is as irrelevant as the SMTP sender. Hilarie From gonzalo.camarillo@ericsson.com Fri Sep 3 00:04:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCAB3A67F6; Fri, 3 Sep 2010 00:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.83 X-Spam-Level: X-Spam-Status: No, score=-103.83 tagged_above=-999 required=5 tests=[AWL=-1.231, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZAJ2fubQHWG; Fri, 3 Sep 2010 00:04:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 60C763A67F4; Fri, 3 Sep 2010 00:04:27 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-a8-4c809e192db9 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 69.64.06895.91E908C4; Fri, 3 Sep 2010 09:04:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Sep 2010 09:03:36 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Sep 2010 09:03:36 +0200 Message-ID: <4C809DC6.9080109@ericsson.com> Date: Fri, 03 Sep 2010 10:03:34 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Ted Hardie References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Sep 2010 07:03:36.0455 (UTC) FILETIME=[21060170:01CB4B36] X-Brightmail-Tracker: AAAAAA== Cc: The IETF , "secdir@ietf.org" , "ben@estacado.net" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" , Christer Holmberg Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Sep 2010 07:04:30 -0000 Hi Ted, > Thanks for your message and your consideration of the points I raised. > Given the > scope of changes below, my first suggestion is that the author team actually > go ahead with a draft incorporating these changes, so that we can discuss > based on the actual text. I also suspect that a second last call will > be necessary as > a result. the plan is to give the authors some time to discuss with all of you who sent comments on the draft so that the authors understand how to address them. Depending on the nature of the changes needed, we may need to IETF LC it again (as you suggest above) or even let the WG have an additional look at it. But for now, thanks for following this up. Cheers, Gonzalo From rogaglia@cisco.com Thu Sep 2 01:06:06 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7013A6908; Thu, 2 Sep 2010 01:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.826 X-Spam-Level: X-Spam-Status: No, score=-9.826 tagged_above=-999 required=5 tests=[AWL=-0.297, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0J2xhIDkqjh; Thu, 2 Sep 2010 01:06:04 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B7BDA3A6852; Thu, 2 Sep 2010 01:06:02 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcFABr4fkxAZnwM/2dsb2JhbAAwgRSfOHGhN5wOhTkEihk X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="p7s'?scan'208,217";a="154628454" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Sep 2010 08:06:32 +0000 Received: from [144.254.21.53] ([144.254.21.53]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8286F8n000543; Thu, 2 Sep 2010 08:06:30 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-306-121994795; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Wed, 1 Sep 2010 22:11:12 +0200 Message-Id: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> References: To: Sandra Murphy X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Fri, 03 Sep 2010 11:31:04 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, =?iso-8859-1?Q?Alberto_Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 08:06:06 -0000 --Apple-Mail-306-121994795 Content-Type: multipart/alternative; boundary=Apple-Mail-305-121994718 --Apple-Mail-305-121994718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Sandra, I issued a new version of the draft draft-ietf-csi-send-cert documents. I believe the new version addresses all the concerns expressed in this = mail exchange. Regards, Roque On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote: > Hi, > The text of this email has been extracted from a thorough review of = draft-ietf-csi-proxy-send being made by Sandra Murphy. > The reason why the email has been separated is to include the authors = of draft-ietf-csi-send-cert in the discussion of this part of the text, = since I think some of the issues raised by Sandra affect this document. > =20 > I include my comments inline. > =20 > | -----Mensaje original----- > | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] > | Enviado el: viernes, 02 de julio de 2010 2:31 > | Para: iesg@ietf.org; secdir@ietf.org; = draft-ietf-csi-proxy-send.all@tools.ietf.org > | Asunto: secdir review of draft-ietf-csi-proxy-send-04 > |=20 > | This is a review of draft draft-ietf-csi-proxy-send-04.txt. > |=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 > | This document provides new Neighbor Discovery options that will = secure > | proxied Neighbor Discovery messages. It is an update to: > |=20 > | RFC4861: Neighbor Discovery in IPv6 > | RFC4389: Neighbor Discovery Proxies (ND Proxy) > | RFC3971: Send Neighbor Discovery (SEND) > |=20 > | This draft relies on draft draft-ietf-csi-send-cert-04.txt. > |=20 > | The need for new mechanisms for security for proxied messages is = explained > | in draft-ietf-csi-sndp-prob-04.txt. > |=20 > | I've read all of these, but it is pretty new to me, so I could have = missed > | something. > |=20 > | The Neighbor Discovery protocol communicates link-level addresses = in the > | protocol messages. The ND Proxy extension would make changes to = those > | fields. SEND, which secures the base ND protocol, relies on the = sender of > | a message computing a signature associated with the source IP = address of > | the message. Any ND Proxy changes to messages would invalidate the > | signature and the ND Proxy itself could not generate a new = signature > | (since it would not have the private key associated with the source = IP > | address). This draft introduces a Proxy Signature (PS) option to = secure > | the proxied messages. > |=20 > | RFC3971, the base SEND spec, defines a new Router Authorization > | Certificate profile, dependent on RFC3779, which authorizes the = router to > | act as a router and act for certain prefixes. Message = authorization in > | SEND of some ND messages checks the prefixes listed in the = certificate > | against the prefixes mentioned in those messages. There is no = explicit > | representation in the certificate of the authority to act as a = router. > | Possession of the certificate in SEND serves as implicit = authorization to > | act as a router, as that was the only authorization defined. > |=20 > | With the introduction of proxies, there was a need to distinguish = the > | various roles that a node might have in the network. No longer is > | possession of a certificate adequate authorization. The draft > | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to = distinguish > | three different roles: router, proxy and owner. That draft notes = that > | multiple key purposes are possible. I believe that it is also = possible to > | have single roles =96 so a node could be a proxy but not a router. > =20 > Yes, of course single roles are supported. > =20 > | With the extensions of the csi-send-cert draft, possession of a > | certificate is no longer proof of any particular authorization. It = seem > | clear to me that the authorization validation described in RFC3971 = is no > | longer sufficient. I believe that a discussion is needed of what = messages > | require or allow each particular key purpose authorization. = Issuing an > | RA, for example, seems likely to require the "router" value of the = key > | purpose field, if the new certificate format was used for = authorization. > | Issuing an NA may require the "owner" value of the key purpose = field, if > | the new certificate format was used for authorization rather than a = CGA. > | I do not know if that discussion would be more appropriate here or = in the > | csi-send-cert draft, or another draft entirely that updates RFC3971 > | directly. > |=20 > | If a SPND proxy was using SEND to communicate with other nodes that > | understood SPND, would it be OK to use a new format cert (with the > | "router" KeyPurposeId) as a router certificate for the SEND RSA = Signature > | Options? > |=20 > I see. I agree that this needs more precision. > =20 > In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in = cert-04) it discusses the messages that are authorized by each = KeyPurposeId > - "router authorization value indicates that the > certificate has been issued for allowing the router to advertise > prefix(es)" > (I understand that implicitly states that it authorizes the generation = of RA messages. It is not crystal clear for me if it authorizes NA for = routers, although if I had to take this text literally, I would suppose = routers would need an 'owner' authorization if this PKI model = substitutes RFC3971 CGA authorization, considering that the prefix for = NA would be narrowed in general to one address, while the RA = authorization is prefix-wide) > - "proxy authorization value indicates that the > certificate has been issued for allowing the proxy to perform > proxying of neighbor discovery messages for the prefix(es) that are > mentioned using the X.509 extensions for IP addresses" > (I understand it now implicitly states it authorizes for ANY neighbor = discovery message. By the way, this is the assumption underlying in = general draft-ietf-csi-proxy-send-04: in the application scenarios, some = require RA proxying, which is assumed to be performed by means of the = proxy cert) > - "owner authorization [...]For an > address in such certificate the host can assign the address, send/ > receive traffic from this address, and can respond to NSes about = that > address" > (this is the clearest of all statements - although I think issuing = secured NS and RS should also be considered) > =20 > So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates = provide authorization for securing *any* ND message. Considering the = application scenarios, some require proxying RA (PMIPv6 and RFC4389), = and the MIPv6 scenario just require NS/NA proxying. > =20 > In summary so far, there is some specification of the authorization in = draft-csi-send-cert, which I think it would be nice that it could be = refined, and if so, my opinion is that the refinement of which ND = message is authorized by each KeyPurposeId should be in that document. > However, continuing with this issue, I must say that the way the = 'proxy authorization' is defined, and the relationship with the other = cases, is not satisfactory for me. > I think the use of 'owner' should be restricted for hosts that really = own the address (therefore, a substitution of the CGA mechanism) - as = opposed to proxies. > For the 'proxy authorization', I think it could be refined into = something like =93proxy host=94 authorization, and =93proxy router=94 = authorization. > =91Proxy host=92 would authorize for proxying NA, NS and RS, and = =93proxy router=94 authorization would authorize RA and Redirect. This = would provide a finer grain which I think would be desirable (for = example, MIPv6 does not need protecting neither RA nor redirect). > I think this would work (if so, it should be changed in = draft-csi-send-cert). > =20 > What do you think? (both authors of draft-csi-send-cert, Sandra, = etc.). > =20 > Regards, > Alberto > =20 > =20 --Apple-Mail-305-121994718 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Sandra,

I issued a new version of the draft draft-ietf-csi-send-cert documents.

I believe the new = version addresses all the concerns expressed in this mail = exchange.


Hi,

The text of this email has = been extracted from a thorough review of draft-ietf-csi-proxy-send = being made by Sandra Murphy.

The reason why the email has been separated = is to include the authors of draft-ietf-csi-send-cert in the discussion of = this part of the text, since I think some of the issues raised by Sandra affect = this document.

 

I include my comments = inline.

 

|  -----Mensaje original-----

|  De: Sandra Murphy = [mailto:Sandra.Murphy@sparta.com]

|  Enviado el: viernes, 02 de julio de 2010 = 2:31

|  Para: iesg@ietf.org; secdir@ietf.org; = draft-ietf-csi-proxy-= send.all@tools.ietf.org

|  = Asunto: secdir review of draft-ietf-csi-proxy-send-04

|  =

|  = This is a review of draft draft-ietf-csi-proxy-send-04.txt.

|  =

|  = 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 provides new Neighbor Discovery options that will = secure

|  = proxied Neighbor Discovery messages.  It is an update to:

|  =

|  = RFC4861: Neighbor Discovery in IPv6

|  RFC4389: Neighbor Discovery Proxies (ND Proxy)

|  = RFC3971: Send Neighbor Discovery (SEND)

|  =

|  = This draft relies on draft draft-ietf-csi-send-cert-04.txt.

|  =

|  = The need for new mechanisms for security for proxied messages is = explained

|  = in draft-ietf-csi-sndp-prob-04.txt.

|  =

|  = I've read all of these, but it is pretty new to me, so I could have = missed

|  = something.

|  =

|  = The Neighbor Discovery protocol communicates link-level addresses in = the

|  = protocol messages.  The ND Proxy extension would make changes to those

|  = fields.  SEND, which secures the base ND protocol, relies on the sender = of

|  = a message computing a signature associated with the source IP address = of

|  = the message.  Any ND Proxy changes to messages would invalidate the

|  = signature and the ND Proxy itself could not generate a new signature

|  (since it would not have the private key associated with the source = IP

|  = address).  This draft introduces a Proxy Signature (PS) option to = secure

|  = the proxied messages.

|  =

|  = RFC3971, the base SEND spec, defines a new Router Authorization

|  = Certificate profile, dependent on RFC3779, which authorizes the router = to

|  = act as a router and act for certain prefixes.  Message authorization = in

|  = SEND of some ND messages checks the prefixes listed in the certificate

|  = against the prefixes mentioned in those messages.  There is no = explicit

|  = representation in the certificate of the authority to act as a = router.

|  = Possession of the certificate in SEND serves as implicit authorization = to

|  = act as a router, as that was the only authorization defined.

|  =

|  = With the introduction of proxies, there was a need to distinguish = the

|  = various roles that a node might have in the network.  No longer = is

|  = possession of a certificate adequate authorization.  The draft

|  = draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to distinguish

|  = three different roles: router, proxy and owner.  That draft notes = that

|  = multiple key purposes are possible.  I believe that it is also possible = to

|  = have single roles =96 so a node could be a proxy but not a router.

 

Yes, of course single roles = are supported.

 

|  = With the extensions of the csi-send-cert draft, possession of a

|  = certificate is no longer proof of any particular authorization.  It = seem

|  = clear to me that the authorization validation described in RFC3971 is = no

|  = longer sufficient.  I believe that a discussion is needed of what = messages

|  = require or allow each particular key purpose authorization.  Issuing = an

|  = RA, for example, seems likely to require the "router" value of the = key

|  = purpose field, if the new certificate format was used for = authorization.

|  Issuing an NA may require the "owner" value of the key purpose field, = if

|  = the new certificate format was used for authorization rather than a = CGA.

|  = I do not know if that discussion would be more appropriate here or in = the

|  = csi-send-cert draft, or another draft entirely that updates RFC3971

|  = directly.

|  =

|  = If a SPND proxy was using SEND to communicate with other nodes that

|  = understood SPND, would it be OK to use a new format cert (with = the

|  = "router" KeyPurposeId) as a router certificate for the SEND RSA = Signature

|  = Options?

|  =

I see. I = agree that this needs more precision.

 

In = draft-ietf-csi-send-cert-05, section 7 (it is the same text as in cert-04) it discusses the messages that are authorized = by each KeyPurposeId

- "router authorization value indicates that = the

   certificate has been issued for = allowing the router to advertise

   = prefix(es)"

(I understand that implicitly states that it authorizes the generation of RA messages. It is not crystal clear for me = if it authorizes NA for routers, although if I had to take this text = literally, I would suppose routers would need an 'owner' authorization if this PKI = model substitutes RFC3971 CGA authorization, considering that the prefix for = NA would be narrowed in general to one address, while the RA authorization is prefix-wide)

- "proxy authorization value indicates that = the

   certificate has been issued for = allowing the proxy to perform

   proxying of neighbor discovery = messages for the prefix(es) that are

   mentioned using = the X.509 extensions for IP addresses"

(I understand it now implicitly states it = authorizes for ANY neighbor discovery message. By the way, this is the assumption underlying in general draft-ietf-csi-proxy-send-04: in the application scenarios, some require RA proxying, which is assumed to be performed by = means of the proxy cert)

- "owner authorization = [...]For an

   address in such certificate the = host can assign the address, send/

   receive traffic from this = address, and can respond to NSes about that

   = address"

(this is the clearest of all statements - = although I think issuing secured NS and RS should also be = considered)

 

So, as defined now in = draft-ietf-csi-proxy-send-04, proxy certificates provide authorization for securing *any* ND message. Considering the application scenarios, some require proxying RA (PMIPv6 = and RFC4389), and the MIPv6 scenario just require NS/NA proxying. =

 

In summary so far, there is = some specification of the authorization in draft-csi-send-cert, which I think it would be nice = that it could be refined, and if so, my opinion is that the refinement of which = ND message is authorized by each KeyPurposeId should be in = that document.

However, continuing with this issue, I must = say that the way the 'proxy authorization' is defined, and the relationship with = the other cases, is not satisfactory for me.

I think the use of 'owner' = should be restricted for hosts that really own the address (therefore, a substitution of the CGA mechanism) - as opposed to proxies.

For the 'proxy authorization', = I think it could be refined into something like =93proxy host=94 authorization, and =93proxy router=94 authorization.

=91Proxy host=92 would = authorize for proxying NA, NS and RS, and =93proxy router=94 authorization would authorize RA and Redirect. This would provide a finer grain which I think would be = desirable (for example, MIPv6 does not need protecting neither RA nor redirect). =

I think = this would work (if so, it should be changed in draft-csi-send-cert).

 

What do you think? (both = authors of draft-csi-send-cert, Sandra, etc.).

 

Regards,

Alberto

 

 


= --Apple-Mail-305-121994718-- --Apple-Mail-306-121994795 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkwMTIw MTExM1owIwYJKoZIhvcNAQkEMRYEFKsaO3CDqEUU0MeQZ/Xn+JlIYH9iMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBADDikmhaEQTTDlMJEqRIGDNO2y9sdBJStp0DJ3qGTIkusSqxNa42 AHWLhcRhBveXtYQ9k1lIiwn093KwnouTPzTvyTSfgv7mPVxfasMSk/fzrH9h9tGzddFWCKaAINB4 chw+UiGu+/9WNIhUdoA3tvdi+UNOM++m6XiKZxZ15Lr267EqqWgyyzKmnCcjsOaHpY+VzYIEw2F4 D8Y2wISU0CBGbFfbBOTMxj0wl51hV0KAkRaqZ5j9EK8v1IU9dzwr9HMnGqiewkwHH1twYUmtFFQZ 5w7lSvNy3tSdclucs4dNaCjDbLPicASDegySgdyDuDviylhjYejBsoFWJTRrR+MAAAAAAAA= --Apple-Mail-306-121994795-- From gvandeve@cisco.com Thu Sep 2 03:41:49 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BA433A6957; Thu, 2 Sep 2010 03:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.427 X-Spam-Level: X-Spam-Status: No, score=-10.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNGbFhib3ME0; Thu, 2 Sep 2010 03:41:48 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 28A8B3A6934; Thu, 2 Sep 2010 03:41:48 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFYcf0xAZnwN/2dsb2JhbACgfHGgTZwNhTkEjRc X-IronPort-AV: E=Sophos;i="4.56,307,1280707200"; d="scan'208";a="154675974" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 02 Sep 2010 10:42:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o82AgGZb010176; Thu, 2 Sep 2010 10:42:17 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); Thu, 2 Sep 2010 12:42:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 2 Sep 2010 12:42:16 +0200 Message-ID: <4269EA985EACD24987D82DAE2FEC62E5021A9CB3@XMB-AMS-101.cisco.com> In-Reply-To: <20100616002354.GS24077@oracle.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt Thread-Index: AcsM6mpD6GfhEMqjT2S3J6AtTjUS5A9oI0vw References: <20100616002354.GS24077@oracle.com> From: "Gunter Van de Velde (gvandeve)" To: "Nicolas Williams" , "IESG" , X-OriginalArrivalTime: 02 Sep 2010 10:42:17.0476 (UTC) FILETIME=[83592C40:01CB4A8B] X-Mailman-Approved-At: Fri, 03 Sep 2010 11:31:04 -0700 Cc: draft-ietf-v6ops-ra-guard.all@tools.ietf.org Subject: Re: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2010 10:41:49 -0000 Hi Nicolas, We just submitted a new draft: http://www.ietf.org/id/draft-ietf-v6ops-ra-guard-08.txt Inline: GV> -----Original Message----- From: Nicolas Williams [mailto:Nicolas.Williams@oracle.com]=20 Sent: Wednesday, June 16, 2010 2:24 AM To: IESG; secdir@ietf.org Cc: draft-ietf-v6ops-ra-guard.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-v6ops-ra-guard-06.txt 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. In my opinion this document is not quite ready for publication. "RA-Guard" is a filtering service that is intended to run in layer-2 network fabrics to help protect routers from attackers. However, this is not exactly clear from the text of the abstract. The possible types of filters ("filter criteria") given are: - stateless filters based on link-layer address of sender, switch port on which the RA is received, sender IP address, and "prefix list" (what is that?); - stateful filters: stateless filters (see above) learned during a learning period; - stateful filters based on SEND status. Issues: - The Abstract needs a lot of wordsmithing, and needs to expand acronyms on first use. GV> ack.. abstract in the paper now is based upon your suggestion. Here's an attempt at a re-write: " Routing protocols are often susceptible to spoof attacks. The canonical solution to this is Secure Neighbor Discovery (SEND) [RFC3971], a solution that is difficult to deploy. This document proposes a light-weight alternative and complement to SEND based on filtering in the layer-2 network fabric, using a variety of filtering criteria, including, for example, SEND status. " (Not much more needs to be said in the abstract.) GV> Agreed. Abstract is changed, inline with some of the discuss comments. - The Introduction needs a lot of wordsmithing, and needs to expand acronyms on first use. GV> Done - Are there particular routing protocols that this solution applies to, or not? GV> nope.. just IPv6 Router advertisement...=20 - I don't understand why "Ethernet" is described as incompatible with RA-Guard. There clearly exist switched Ethernet L2 fabrics... Perhaps the authors intended to be more specific? GV> I removed the example - The Security Considerations section is too short. Not enough examples of filtering criteria are given in the body of the document, and none of the security considerations of using such any specific RA-Guard filtering criteria are discussed. Nor are security considerations of use of specific filtering criteria with and without also using SEND are discussed. Nor are the security considerations of using learning mode discussed. GV> its longer now inline with the discuss comments - I suppose there's no need for a standard filter interchange language, but perhaps this could be stated explicitly. Even so, examples with a pseudo-language for writing filters may well be useful. GV> Not sure this is needed for this trivial kind of mechanism Many thanks for your review and work on this paper. Gunter Van de Velde From weiler@watson.org Sat Sep 4 17:15:09 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87EA63A68B0 for ; Sat, 4 Sep 2010 17:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.49 X-Spam-Level: X-Spam-Status: No, score=-0.49 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDErq3fl2xOe for ; Sat, 4 Sep 2010 17:15:07 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 917683A659B for ; Sat, 4 Sep 2010 17:15:07 -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 o850FZf9081812 for ; Sat, 4 Sep 2010 20:15:35 -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 o850FYil081808 for ; Sat, 4 Sep 2010 20:15:34 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 4 Sep 2010 20:15:34 -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]); Sat, 04 Sep 2010 20:15:35 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sun, 05 Sep 2010 00:15:09 -0000 Rob Austein is next in the rotation. Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2010-09-09 Reviewer LC end Draft Derek Atkins TR2010-07-09 draft-ietf-avt-forward-shifted-red-06 Julien Laganier T 2010-08-31 draft-ietf-nsis-nslp-auth-06 Eric Rescorla T 2010-09-06 draft-das-mipshop-andsf-dhcp-options-04 Glen Zorn T 2010-07-26 draft-cakulev-mikey-ibake-02 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2010-09-14 draft-ietf-eai-frmwrk-4952bis-07 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-09 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Vincent Roca 2010-08-23 draft-ietf-fecframe-framework-09 Carl Wallace 2010-09-13 draft-josefsson-pbkdf2-test-vectors-05 Sam Weiler 2010-09-03 draft-ietf-opsec-igp-crypto-requirements-00 Brian Weis 2010-09-07 draft-ietf-netmod-dsdl-map-07 Nico Williams 2010-09-10 draft-ietf-fecframe-sdp-elements-08 Tom Yu 2010-09-27 draft-gundavelli-v6ops-l2-unicast-04 Kurt Zeilenga 2010-09-16 draft-ietf-ccamp-lsp-hierarchy-bis-08 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From alexey.melnikov@isode.com Sun Sep 5 15:25:53 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 241FC3A686A; Sun, 5 Sep 2010 15:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCR9Qm850hLa; Sun, 5 Sep 2010 15:25:52 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id B575B3A685B; Sun, 5 Sep 2010 15:25:51 -0700 (PDT) Received: from [188.28.78.136] (188.28.78.136.threembb.co.uk [188.28.78.136]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 5 Sep 2010 23:26:19 +0100 Message-ID: <4C8418DF.6010703@isode.com> Date: Sun, 05 Sep 2010 23:25:35 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Hilarie Orman References: <201009022339.o82NdAic027378@fermat.rhmr.com> In-Reply-To: <201009022339.o82NdAic027378@fermat.rhmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Sep 2010 22:25:53 -0000 Hi Hilarie, Hilarie Orman wrote: >Security review of draft-ietf-calsify-rfc2447bis-10 > >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 review >comments. > > Thank you for your review. >The document describes the "iCalendar Message-Based Interoperability >Protocol (iMIP)", a protocol for transmitting calendar events over >SMTP. > >The security considerations are tied to authenticating the entity >with the role of "Organizer" or "Attendee". The authentication >relies on MIME security for attaching signatures and public key >certificates. The SMTP sender is not relevant to the authentication. > >I'm slightly puzzled by the first step listed in "Security >Considerations" about the steps needed to perform authentication. > > 1. Using the security mechanism compliant with [RFC-1847], determine > who signed the email message containing the iCalendar object. This is > the "signer". Note that the signer is not necessarily the person > sending an e-mail message since an e-mail message can be forwarded. > >The confusion stems from the phrases "who signed the email message" >and "the person sending". Would "who signed the MIME calendar part" > Yes. I think saying "who signed the text/calendar body part ..." would be even better. >and "the SMTP message sender" be more accurate? > Actually no. In general case SMTP message sender (i.e. the SMTP MAIL FROM value) has nothing to do with who is sending out the message (value of the message's Sender: header field). So this text is talking about the person associated with the Sender header field. > I think that MIME >allows each part to have a different signer, and I think the protocol >anticipates having MIME parts separated from the original SMTP message >and forwarded in a different SMTP message. If that's the case, the >rephrasing would make sense to me. > > I would prefer to do the first change and not do anything about the second. >There is an obvious slippery slope in the iCal "sent-by" parameter. >It conflicts with the "organizer". The receiver is left with a >dilemna: to authenticate wrt to the "sent-by" entity, > I think this is the only viable option the way how calendaring and email is done today. >or to insist on a signature by the "organizer". > >It seems to me that the "organizer" >could have signed the event (including the "sent-by" parameter) in >advance and given the MIME parts to the sender, so there is no need to >trust the "sent-by" entity. > Delegation doesn't currently work this way and I don't think this is likely to change. When "sent-by" is used the organizer delegates all handling (out-of-band or using some kind of authorization) to another person. The organizer is not involved in creating the event. Think of this as a case when a boss tells her secretary to organize a meeting. The boss is not going to create the meeting event, sign it and send it to the secretary. If the boss does it, there is no reason to use "sent-by" at all, as the calendar event can be just sent out by the boss. >Or, the receiver could have a list of >trusted proxies in its local security policy. > This is more likely. For example if the organizer and the receiver are in the same organization. Or the receiver can phone the organizer and ask if this was truly authorized (out-of-band verification). >But, in general, I think that an event signed by an unknown or >untrusted party should be given no special considertion --- it is the >same as receiving an unsigned event, and "sent-by" is as irrelevant as >the SMTP sender. > In absence of any other information about organizer authorizing the "sent-by", I agree. But I think the existing text on this is adequate: It is possible to receive iMIP messages sent by someone working on behalf of another "Calendar User". This is determined by examining the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" property. [iCAL] and [iTIP] provide no mechanism to verify that a "Calendar User" has authorized someone else to work on their behalf. To address this security issue, implementations MUST provide mechanisms for the "Calendar Users" to make that decision before applying changes from someone working on behalf of a "Calendar User". One way to achieve this is to reject iMIP messages sent by users other than the "ORGANIZER" or the "ATTENDEE"s. This covers the case "treat as untrusted". Another way is to prompt the user for confirmation. iMIP based calendaring is frequently deployed within a single ADMD (Administrative Domain) [RFC5598], with boundary filtering employed to restrict email calendaring flows to be inside the ADMD. This can help in minimizing malicious changes to calendaring messages in transit, as well as in making authorization decisions easier. Please let me know if you think that some other text needs to be added, or that the quoted text needs to be modified. Regards, Alexey From yaronf.ietf@gmail.com Mon Sep 6 10:47:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E25703A67B5 for ; Mon, 6 Sep 2010 10:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.813 X-Spam-Level: X-Spam-Status: No, score=-101.813 tagged_above=-999 required=5 tests=[AWL=-0.414, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P1oRETy9GDPA for ; Mon, 6 Sep 2010 10:47:55 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DBE0F3A6951 for ; Mon, 6 Sep 2010 10:47:54 -0700 (PDT) Received: by fxm18 with SMTP id 18so2978210fxm.31 for ; Mon, 06 Sep 2010 10:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=8budYuTRTnMrEHVH6oq5A+tuJO/8Aai2q/Bsxpve7Q0=; b=WaZYjG07At+q9zjQ8lgrwbP54W2lNicSUoEGErGjl9X3kacgeqkFtRNN7d/FKxFO5O f34mAufkfFGjYHqGC8iWZ6/4mzUMHqvv3CX7TX855jzJFqKzNMbSWyGhNgA+zQikLDQR CPCFw/xdAEg7HEJU78ONg4G1DyfUNj4cVCiRM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j9u8nI/dU7E2VxJUkvhnRx/1KNh6PK3kx2HDlayOi6VpPN3SC2NFiTC8533PcKe1+Z krzajaldHt4Byid64+Upy9H7HfcRfq/s0K47aUsxAmKIgAlvTnimV9q1wr9DQXeZD2wl EqP6vNmL1GW7Wbtqyw08IVd1rYcVWTnQ3VNZY= Received: by 10.223.111.68 with SMTP id r4mr2958619fap.56.1283795302441; Mon, 06 Sep 2010 10:48:22 -0700 (PDT) Received: from [10.0.0.2] (bzq-79-183-43-64.red.bezeqint.net [79.183.43.64]) by mx.google.com with ESMTPS id s20sm2434629faa.28.2010.09.06.10.48.16 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Sep 2010 10:48:21 -0700 (PDT) Message-ID: <4C85295D.5010209@gmail.com> Date: Mon, 06 Sep 2010 20:48:13 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.11) Gecko/20100713 Lightning/1.0b1 Thunderbird/3.0.6 MIME-Version: 1.0 To: Brian Weis , Dan Harkins References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> In-Reply-To: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Tim Polk , draft-sheffer-emu-eap-eke@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Sep 2010 17:47:57 -0000 Hi Brian, Dan, thanks for both of your reviews. While we do not see additional value in including the identities in the password derivation (given that they are later bound into the shared secret), we don't have any problem with it either. We are fine with making the key derivation function more standard. We propose the following change to http://tools.ietf.org/id/draft-sheffer-emu-eap-eke-08.html#commit-request. We define a KDF which is modeled on RFC 5869, and in fact becomes HKDF when the MAC is an HMAC (note that the draft does *not* constrain MAC functions to be an HMAC construction): PRF := mac("\0"+, P) KEY := mac+(PRF, ID_s | ID_p) DHComponent_S := Encr(KEY, y_s) PRF is truncated or zero-padded if necessary when used to derive KEY. Neither is needed when using an HMAC function for the MAC. The protocol peers should store the MAC'ed password, instead of a plaintext password. The peers have a choice of storing the output of the first application of MAC, or that of the second application (i.e. salted by the identities). The security benefits of the latter should be weighed against the operational difficulty associated with changing either of the identities. BTW, we have changed the "kmac" terminology into "mac", per your comments. The operator mac+ will be redefined as: mac+(key, string) = T1 | T2 ... where each Ti is an application of the keyed MAC with a fixed key: T1 = mac(key, string | 0x01) T2 = mac(key, T1 | string | 0x02) T3 = mac(key, T2 | string | 0x03) Please let us know if this change resolves your concerns. Thanks, Yaron On 08/17/2010 06:52 AM, Brian Weis 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 review comments. > > I previously reviewed -06 of this I-D and made a number of suggestions. > The current version has addressed those as well as other last call > comments. I have just one concern and one comment regarding the changes > regarding encrypting DHComponent_S and DHComponent_P in on-the-wire > payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm going to > discuss DHComponent_S, but DHComponent_P is similarly changed. > > 1. In -06, DHComponent_S was protected with an IKEv2-style prf+(): > DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s), > In -07, DHComponent_S is now protected with a "keyed MAC": > DHComponent_S = Encr(kmac+(password), y_s) > where kmac+() is defined as: > kmac+(P) = T1 | T2 | ... > where each Ti is an application of the keyed MAC with a fixed key: > T1 = kmac("S"+, P | 0x01) > T2 = kmac("S"+, T1 | P | 0x02) > T3 = kmac("S"+, T2 | P | 0x03) > Dan Harkins suggested an "extractor and expander" KDF, which I believe > motivated this change. I think the use of a constant "salt" value used > as a key in kmac+ approximates only the "extractor" function described > in RFC 5869, and the output of an "extractor" is not intended to be the > final KDF output. An "expander" function is necessary to follow the > "extractor" function, and prf+ fits that description. So unless I'm > mistaken, these section should define two calls: one to kmac() to to > create an intermediate value of the appropriate size, and the another > that uses the intermediate value as the key to a prf+ call. > > I think it might be convenient to require the kmac+ and prf+ algorithms > be the same. > > 2. As far as I can tell, the definition of "kmac" is new to this I-D, > which I found a bit confusing. It's really just a MAC, so I think it > would be clearer to just call it a mac(). > > Brian > > > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir From CWallace@cygnacom.com Tue Sep 7 05:57:17 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 749133A6A21; Tue, 7 Sep 2010 05:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbPCrGD4cshS; Tue, 7 Sep 2010 05:57:15 -0700 (PDT) Received: from mail75.messagelabs.com (mail75.messagelabs.com [216.82.250.3]) by core3.amsl.com (Postfix) with SMTP id 557373A6A1E; Tue, 7 Sep 2010 05:57:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: CWallace@cygnacom.com X-Msg-Ref: server-8.tower-75.messagelabs.com!1283864262!103360893!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [65.242.48.17] Received: (qmail 14471 invoked from network); 7 Sep 2010 12:57:43 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (65.242.48.17) by server-8.tower-75.messagelabs.com with SMTP; 7 Sep 2010 12:57:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {EA00B72F-E1DE-4375-B126-778B198C10A7} x-cr-hashedpuzzle: BZ4W GY67 J2j8 Tg9P TqCF UjxG VoFr VpyI WQBo YWch YlSU Zhcc auCf dynj fbgR hG/M; 3; aQBlAHMAZwBAAGkAZQB0AGYALgBvAHIAZwA7AHMAZQBjAGQAaQByAEAAaQBlAHQAZgAuAG8AcgBnADsAcwBpAG0AbwBuAEAAagBvAHMAZQBmAHMAcwBvAG4ALgBvAHIAZwA=; Sosha1_v1; 7; {EA00B72F-E1DE-4375-B126-778B198C10A7}; YwB3AGEAbABsAGEAYwBlAEAAYwB5AGcAbgBhAGMAbwBtAC4AYwBvAG0A; Tue, 07 Sep 2010 12:57:35 GMT; cwBlAGMAZABpAHIAIAByAGUAdgBpAGUAdwAgAG8AZgAgAGQAcgBhAGYAdAAtAGoAbwBzAGUAZgBzAHMAbwBuAC0AcABiAGsAZABmADIALQB0AGUAcwB0AC0AdgBlAGMAdABvAHIAcwAtADAANQA= Content-class: urn:content-classes:message Date: Tue, 7 Sep 2010 08:57:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: secdir review of draft-josefsson-pbkdf2-test-vectors-05 Thread-Index: ActOjD4LyisZmp3VQV6pU1B74BW1Xg== From: "Carl Wallace" To: , , Subject: [secdir] secdir review of draft-josefsson-pbkdf2-test-vectors-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 12:57:17 -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 draft contains test vectors for PKCS #5 Password Based Key Derivation Function 2 (PBKDF2). I did not test the vectors but the draft looks fine otherwise. From dharkins@lounge.org Tue Sep 7 14:24:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0866E3A696F for ; Tue, 7 Sep 2010 14:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[AWL=-0.911, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpPOaWldIdmd for ; Tue, 7 Sep 2010 14:24:23 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 768713A6866 for ; Tue, 7 Sep 2010 14:24:23 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 996542008E; Tue, 7 Sep 2010 14:24:51 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 7 Sep 2010 14:24:51 -0700 (PDT) Message-ID: In-Reply-To: <4C85295D.5010209@gmail.com> References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> <4C85295D.5010209@gmail.com> Date: Tue, 7 Sep 2010 14:24:51 -0700 (PDT) From: "Dan Harkins" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: secdir@ietf.org, Tim Polk , draft-sheffer-emu-eap-eke@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:24:25 -0000 Hi Yaron, Actually what I was suggesting was to use the identities as the "salt" to the extraction part of HKDF. So it would look like this: PRF := mac(ID_s | ID_p, P) KEY := mac+(PRF, "some application-specific string") DHComponent_S := Encr(KEY, y_s) This may impact your desire to use a block cipher as "mac" but you can do the same "truncation or zero-padding" trick you suggest below. Also, I'm not sure what value there is to storing the the mac'd password since that value takes the place of the password to become the authentication credential (EKE is not an asymmetric protocol that can protect against server compromise by storing a transform of the password) but whatever value you find in that practice can only be enhanced by salting the value with the identities thereby ensuring that users with identical passwords will not have identical stored credentials. Dan. On Mon, September 6, 2010 10:48 am, Yaron Sheffer wrote: > Hi Brian, Dan, > > thanks for both of your reviews. > > While we do not see additional value in including the identities in the > password derivation (given that they are later bound into the shared > secret), we don't have any problem with it either. > > We are fine with making the key derivation function more standard. We > propose the following change to > http://tools.ietf.org/id/draft-sheffer-emu-eap-eke-08.html#commit-request. > We define a KDF which is modeled on RFC 5869, and in fact becomes HKDF > when the MAC is an HMAC (note that the draft does *not* constrain MAC > functions to be an HMAC construction): > > PRF := mac("\0"+, P) > KEY := mac+(PRF, ID_s | ID_p) > DHComponent_S := Encr(KEY, y_s) > > PRF is truncated or zero-padded if necessary when used to derive KEY. > Neither is needed when using an HMAC function for the MAC. > > The protocol peers should store the MAC'ed password, instead of a > plaintext password. The peers have a choice of storing the output of the > first application of MAC, or that of the second application (i.e. salted > by the identities). The security benefits of the latter should be > weighed against the operational difficulty associated with changing > either of the identities. > > BTW, we have changed the "kmac" terminology into "mac", per your comments. > > The operator mac+ will be redefined as: > > mac+(key, string) = T1 | T2 ... > > where each Ti is an application of the keyed MAC with a fixed key: > > T1 = mac(key, string | 0x01) > T2 = mac(key, T1 | string | 0x02) > T3 = mac(key, T2 | string | 0x03) > > Please let us know if this change resolves your concerns. > > Thanks, > Yaron > > On 08/17/2010 06:52 AM, Brian Weis 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 review comments. >> >> I previously reviewed -06 of this I-D and made a number of suggestions. >> The current version has addressed those as well as other last call >> comments. I have just one concern and one comment regarding the changes >> regarding encrypting DHComponent_S and DHComponent_P in on-the-wire >> payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm going to >> discuss DHComponent_S, but DHComponent_P is similarly changed. >> >> 1. In -06, DHComponent_S was protected with an IKEv2-style prf+(): >> DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s), >> In -07, DHComponent_S is now protected with a "keyed MAC": >> DHComponent_S = Encr(kmac+(password), y_s) >> where kmac+() is defined as: >> kmac+(P) = T1 | T2 | ... >> where each Ti is an application of the keyed MAC with a fixed key: >> T1 = kmac("S"+, P | 0x01) >> T2 = kmac("S"+, T1 | P | 0x02) >> T3 = kmac("S"+, T2 | P | 0x03) >> Dan Harkins suggested an "extractor and expander" KDF, which I believe >> motivated this change. I think the use of a constant "salt" value used >> as a key in kmac+ approximates only the "extractor" function described >> in RFC 5869, and the output of an "extractor" is not intended to be the >> final KDF output. An "expander" function is necessary to follow the >> "extractor" function, and prf+ fits that description. So unless I'm >> mistaken, these section should define two calls: one to kmac() to to >> create an intermediate value of the appropriate size, and the another >> that uses the intermediate value as the key to a prf+ call. >> >> I think it might be convenient to require the kmac+ and prf+ algorithms >> be the same. >> >> 2. As far as I can tell, the definition of "kmac" is new to this I-D, >> which I found a bit confusing. It's really just a MAC, so I think it >> would be clearer to just call it a mac(). >> >> Brian >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir > From dharkins@lounge.org Tue Sep 7 16:52:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9313A6ADE for ; Tue, 7 Sep 2010 16:52:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[AWL=0.449, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HwRaKYh2Qe-8 for ; Tue, 7 Sep 2010 16:52:01 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 5D8FB3A6ADD for ; Tue, 7 Sep 2010 16:52:01 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 49FB22008E; Tue, 7 Sep 2010 16:52:29 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 7 Sep 2010 16:52:29 -0700 (PDT) Message-ID: <94645e9d1c9193c5830dd01aac396ce7.squirrel@www.trepanning.net> In-Reply-To: References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> <4C85295D.5010209@gmail.com> Date: Tue, 7 Sep 2010 16:52:29 -0700 (PDT) From: "Dan Harkins" To: "Scott Fluhrer (sfluhrer)" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 5 (Lowest) Importance: Low Cc: secdir@ietf.org, Tim Polk , draft-sheffer-emu-eap-eke@tools.ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 23:52:02 -0000 Hi Scott, On Tue, September 7, 2010 2:57 pm, Scott Fluhrer (sfluhrer) wrote: > > >> -----Original Message----- >> From: Dan Harkins [mailto:dharkins@lounge.org] >> Sent: Tuesday, September 07, 2010 5:25 PM >> To: Yaron Sheffer >> Cc: Brian Weis (bew); Dan Harkins; secdir@ietf.org; draft-sheffer-emu- >> eap-eke@tools.ietf.org; Russ Housley; Tim Polk >> Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 >> >> >> Hi Yaron, >> >> Actually what I was suggesting was to use the identities as the >> "salt" to the extraction part of HKDF. So it would look like this: >> >> PRF := mac(ID_s | ID_p, P) >> KEY := mac+(PRF, "some application-specific string") >> DHComponent_S := Encr(KEY, y_s) >> >> This may impact your desire to use a block cipher as "mac" but you can >> do the same "truncation or zero-padding" trick you suggest below. > > Truncation would be a bad idea; that means part (or all) of ID_p does > not contribute to the value of PRF. Now, I don't know if this is a > weakness; on the other hand, if we were assured it wasn't a weakness, > why are we including ID_p at all? Yes, that would be a bad idea. But the alternative was to use a key of all zeros for PRF and then nobody contributes anything. I think it's better to use the identities as "salt" and if this means just using HKDF with some HMAC of a hash function (and not a block cipher) then so be it. But I'm just a contributor not an author :-) >> Also, I'm not sure what value there is to storing the the mac'd >> password since that value takes the place of the password to become >> the authentication credential (EKE is not an asymmetric protocol >> that can protect against server compromise by storing a transform >> of the password) but whatever value you find in that practice can >> only be enhanced by salting the value with the identities thereby >> ensuring that users with identical passwords will not have identical >> stored credentials. > > However, if they were to store the KEY values, then identical passwords > will already not have identical credentials. Would it work out better > if we suggested that more strongly? I guess. Honestly I'm fine with this and the resolution Yaron presented. It's better than the -07 version. But my original comments were essentially, why not just use HKDF. There's this new standard for extraction-expansion key derivation that had alot of cryptographic analysis and it has a rigorous proof behind it when used in the way it is specified and instead of just using that, EAP-EKE is adding yet another negotiable option-- "prf"-- that determines whether you build something that will look like the standard or whether it will look like slightly different. Are we assured that the extraction and pseudo-random properties of "prf" with a value of are appropriate for use in this HKDF-like construct? Even if we are, is there a problem being solved here or a reason why HKDF as defined is not enough? Can't you just say, use HKDF in 5.1 to distill whatever entropy is in the password and generate an encryption key to encrypt the exponentials; use HKDF in 5.2 to distill the entropy from g^(x_s * x_p) mod p and generate Ke and Ki; and then, use HKDF in 5.5 to distill the entropy from SharedSecret and derive MSK and EMSK? Dan. From sfluhrer@cisco.com Tue Sep 7 14:56:45 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C660F3A6862 for ; Tue, 7 Sep 2010 14:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPqd31oPao-d for ; Tue, 7 Sep 2010 14:56:44 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 899523A6867 for ; Tue, 7 Sep 2010 14:56:44 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM9RhkyrRN+J/2dsb2JhbAChCXGlUJtjgw6CLwSEQ4hT X-IronPort-AV: E=Sophos;i="4.56,330,1280707200"; d="scan'208";a="251486135" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 07 Sep 2010 21:57:12 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o87LvC2G029621; Tue, 7 Sep 2010 21:57:12 GMT Received: from xmb-sjc-23e.amer.cisco.com ([128.107.191.15]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 Sep 2010 14:57:12 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 7 Sep 2010 14:57:07 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 Thread-Index: ActO0znpbGe1dAZTTRKhKyxDnjB2IwAAu7XA X-Priority: 5 Priority: Non-Urgent Importance: low References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> <4C85295D.5010209@gmail.com> From: "Scott Fluhrer (sfluhrer)" To: "Dan Harkins" , "Yaron Sheffer" X-OriginalArrivalTime: 07 Sep 2010 21:57:12.0746 (UTC) FILETIME=[A079C0A0:01CB4ED7] X-Mailman-Approved-At: Wed, 08 Sep 2010 08:01:21 -0700 Cc: Tim Polk , draft-sheffer-emu-eap-eke@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Sep 2010 21:56:45 -0000 > -----Original Message----- > From: Dan Harkins [mailto:dharkins@lounge.org] > Sent: Tuesday, September 07, 2010 5:25 PM > To: Yaron Sheffer > Cc: Brian Weis (bew); Dan Harkins; secdir@ietf.org; draft-sheffer-emu- > eap-eke@tools.ietf.org; Russ Housley; Tim Polk > Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 >=20 >=20 > Hi Yaron, >=20 > Actually what I was suggesting was to use the identities as the > "salt" to the extraction part of HKDF. So it would look like this: >=20 > PRF :=3D mac(ID_s | ID_p, P) > KEY :=3D mac+(PRF, "some application-specific string") > DHComponent_S :=3D Encr(KEY, y_s) >=20 > This may impact your desire to use a block cipher as "mac" but you can > do the same "truncation or zero-padding" trick you suggest below. Truncation would be a bad idea; that means part (or all) of ID_p does not contribute to the value of PRF. Now, I don't know if this is a weakness; on the other hand, if we were assured it wasn't a weakness, why are we including ID_p at all? >=20 > Also, I'm not sure what value there is to storing the the mac'd > password since that value takes the place of the password to become > the authentication credential (EKE is not an asymmetric protocol > that can protect against server compromise by storing a transform > of the password) but whatever value you find in that practice can > only be enhanced by salting the value with the identities thereby > ensuring that users with identical passwords will not have identical > stored credentials. However, if they were to store the KEY values, then identical passwords will already not have identical credentials. Would it work out better if we suggested that more strongly? >=20 > Dan. >=20 > On Mon, September 6, 2010 10:48 am, Yaron Sheffer wrote: > > Hi Brian, Dan, > > > > thanks for both of your reviews. > > > > While we do not see additional value in including the identities in > the > > password derivation (given that they are later bound into the shared > > secret), we don't have any problem with it either. > > > > We are fine with making the key derivation function more standard. We > > propose the following change to > > http://tools.ietf.org/id/draft-sheffer-emu-eap-eke-08.html#commit- > request. > > We define a KDF which is modeled on RFC 5869, and in fact becomes > HKDF > > when the MAC is an HMAC (note that the draft does *not* constrain MAC > > functions to be an HMAC construction): > > > > PRF :=3D mac("\0"+, P) > > KEY :=3D mac+(PRF, ID_s | ID_p) > > DHComponent_S :=3D Encr(KEY, y_s) > > > > PRF is truncated or zero-padded if necessary when used to derive KEY. > > Neither is needed when using an HMAC function for the MAC. > > > > The protocol peers should store the MAC'ed password, instead of a > > plaintext password. The peers have a choice of storing the output of > the > > first application of MAC, or that of the second application (i.e. > salted > > by the identities). The security benefits of the latter should be > > weighed against the operational difficulty associated with changing > > either of the identities. > > > > BTW, we have changed the "kmac" terminology into "mac", per your > comments. > > > > The operator mac+ will be redefined as: > > > > mac+(key, string) =3D T1 | T2 ... > > > > where each Ti is an application of the keyed MAC with a fixed key: > > > > T1 =3D mac(key, string | 0x01) > > T2 =3D mac(key, T1 | string | 0x02) > > T3 =3D mac(key, T2 | string | 0x03) > > > > Please let us know if this change resolves your concerns. > > > > Thanks, > > Yaron > > > > On 08/17/2010 06:52 AM, Brian Weis 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 review comments. > >> > >> I previously reviewed -06 of this I-D and made a number of > suggestions. > >> The current version has addressed those as well as other last call > >> comments. I have just one concern and one comment regarding the > changes > >> regarding encrypting DHComponent_S and DHComponent_P in on-the-wire > >> payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm going > to > >> discuss DHComponent_S, but DHComponent_P is similarly changed. > >> > >> 1. In -06, DHComponent_S was protected with an IKEv2-style prf+(): > >> DHComponent_S =3D Encr(prf+(password, "EAP-EKE Password"), y_s), > >> In -07, DHComponent_S is now protected with a "keyed MAC": > >> DHComponent_S =3D Encr(kmac+(password), y_s) > >> where kmac+() is defined as: > >> kmac+(P) =3D T1 | T2 | ... > >> where each Ti is an application of the keyed MAC with a fixed key: > >> T1 =3D kmac("S"+, P | 0x01) > >> T2 =3D kmac("S"+, T1 | P | 0x02) > >> T3 =3D kmac("S"+, T2 | P | 0x03) > >> Dan Harkins suggested an "extractor and expander" KDF, which I > believe > >> motivated this change. I think the use of a constant "salt" value > used > >> as a key in kmac+ approximates only the "extractor" function > described > >> in RFC 5869, and the output of an "extractor" is not intended to be > the > >> final KDF output. An "expander" function is necessary to follow the > >> "extractor" function, and prf+ fits that description. So unless I'm > >> mistaken, these section should define two calls: one to kmac() to to > >> create an intermediate value of the appropriate size, and the > another > >> that uses the intermediate value as the key to a prf+ call. > >> > >> I think it might be convenient to require the kmac+ and prf+ > algorithms > >> be the same. > >> > >> 2. As far as I can tell, the definition of "kmac" is new to this I- > D, > >> which I found a bit confusing. It's really just a MAC, so I think it > >> would be clearer to just call it a mac(). > >> > >> Brian > >> > >> > >> > >> _______________________________________________ > >> secdir mailing list > >> secdir@ietf.org > >> https://www.ietf.org/mailman/listinfo/secdir > > >=20 From hilarie@purplestreak.com Wed Sep 8 14:16:34 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C8EC3A69F3; Wed, 8 Sep 2010 14:16:34 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjP5UEBb+D8J; Wed, 8 Sep 2010 14:16:31 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by core3.amsl.com (Postfix) with ESMTP id 0FC833A6980; Wed, 8 Sep 2010 14:16:30 -0700 (PDT) Received: from mx03.mta.xmission.com ([166.70.13.213]) by out01.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OtS0o-0005ef-Cc; Wed, 08 Sep 2010 15:16:58 -0600 Received: from 166-70-57-249.ip.xmission.com ([166.70.57.249] helo=fermat.rhmr.com) by mx03.mta.xmission.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OtS0m-0005Nx-Jl; Wed, 08 Sep 2010 15:16:58 -0600 Received: from fermat.rhmr.com (localhost [127.0.0.1]) by fermat.rhmr.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o88LF7md032039; Wed, 8 Sep 2010 15:15:07 -0600 Received: (from ho@localhost) by fermat.rhmr.com (8.14.3/8.14.3/Submit) id o88LF62w032038; Wed, 8 Sep 2010 15:15:06 -0600 Date: Wed, 8 Sep 2010 15:15:06 -0600 Message-Id: <201009082115.o88LF62w032038@fermat.rhmr.com> X-Authentication-Warning: fermat.rhmr.com: ho set sender to hilarie using -f From: "Hilarie Orman" To: alexey.melnikov@isode.com In-reply-to: Yourmessage <4C8418DF.6010703@isode.com> 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; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;alexey.melnikov@isode.com 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) Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Wed, 08 Sep 2010 21:16:34 -0000 Comments inline. > From: Alexey Melnikov > Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10 > Date: Sun, 05 Sep 2010 23:25:35 +0100 > Hi Hilarie, > Hilarie Orman wrote: > >Security review of draft-ietf-calsify-rfc2447bis-10 > > > >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 review > >comments. > > > > > Thank you for your review. > >The document describes the "iCalendar Message-Based Interoperability > >Protocol (iMIP)", a protocol for transmitting calendar events over > >SMTP. > > > >The security considerations are tied to authenticating the entity > >with the role of "Organizer" or "Attendee". The authentication > >relies on MIME security for attaching signatures and public key > >certificates. The SMTP sender is not relevant to the authentication. > > > >I'm slightly puzzled by the first step listed in "Security > >Considerations" about the steps needed to perform authentication. > > > > 1. Using the security mechanism compliant with [RFC-1847], determine > > who signed the email message containing the iCalendar object. This is > > the "signer". Note that the signer is not necessarily the person > > sending an e-mail message since an e-mail message can be forwarded. > > > >The confusion stems from the phrases "who signed the email message" > >and "the person sending". Would "who signed the MIME calendar part" > > > Yes. I think saying "who signed the text/calendar body part ..." would > be even better. > >and "the SMTP message sender" be more accurate? > > > Actually no. In general case SMTP message sender (i.e. the SMTP MAIL > FROM value) has nothing to do with who is sending out the message (value > of the message's Sender: header field). So this text is talking about > the person associated with the Sender header field. In the text above, you need to say which protocol the "Sender header field" is associated with. Your text speaks of e-mail and forwarding, thus my assumption that your caveat applied to the SMTP sender. Help out the reader by being explicit. > > I think that MIME > >allows each part to have a different signer, and I think the protocol > >anticipates having MIME parts separated from the original SMTP message > >and forwarded in a different SMTP message. If that's the case, the > >rephrasing would make sense to me. > > > > > I would prefer to do the first change and not do anything about the second. > >There is an obvious slippery slope in the iCal "sent-by" parameter. > >It conflicts with the "organizer". The receiver is left with a > >dilemna: to authenticate wrt to the "sent-by" entity, > > > I think this is the only viable option the way how calendaring and email > is done today. > >or to insist on a signature by the "organizer". > > > >It seems to me that the "organizer" > >could have signed the event (including the "sent-by" parameter) in > >advance and given the MIME parts to the sender, so there is no need to > >trust the "sent-by" entity. > > > Delegation doesn't currently work this way and I don't think this is > likely to change. When "sent-by" is used the organizer delegates all > handling (out-of-band or using some kind of authorization) to another > person. The organizer is not involved in creating the event. Think of > this as a case when a boss tells her secretary to organize a meeting. > The boss is not going to create the meeting event, sign it and send it > to the secretary. If the boss does it, there is no reason to use > "sent-by" at all, as the calendar event can be just sent out by the boss. > >Or, the receiver could have a list of > >trusted proxies in its local security policy. > > > This is more likely. For example if the organizer and the receiver are > in the same organization. > Or the receiver can phone the organizer and ask if this was truly > authorized (out-of-band verification). > >But, in general, I think that an event signed by an unknown or > >untrusted party should be given no special considertion --- it is the > >same as receiving an unsigned event, and "sent-by" is as irrelevant as > >the SMTP sender. > > > In absence of any other information about organizer authorizing the > "sent-by", I agree. > But I think the existing text on this is adequate: > It is possible to receive iMIP messages sent by someone working on > behalf of another "Calendar User". This is determined by examining > the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" > property. [iCAL] and [iTIP] provide no mechanism to verify that a > "Calendar User" has authorized someone else to work on their behalf. > To address this security issue, implementations MUST provide > mechanisms for the "Calendar Users" to make that decision before > applying changes from someone working on behalf of a "Calendar User". > One way to achieve this is to reject iMIP messages sent by users > other than the "ORGANIZER" or the "ATTENDEE"s. > This covers the case "treat as untrusted". > Another way is to > prompt the user for confirmation. This is where I would add the previously recommended text: "Or, the receiver could have a list of trusted proxies in its local security policy." > iMIP based calendaring is frequently deployed within a single ADMD > (Administrative Domain) [RFC5598], with boundary filtering employed > to restrict email calendaring flows to be inside the ADMD. This can > help in minimizing malicious changes to calendaring messages in > transit, as well as in making authorization decisions easier. I'd say the decisions are not "easier" but "less risky". Also, that paragraph sounds like a RECOMMENDATION. Hilarie From christer.holmberg@ericsson.com Thu Sep 9 00:12:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3313A6848; Thu, 9 Sep 2010 00:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.57 X-Spam-Level: X-Spam-Status: No, score=-5.57 tagged_above=-999 required=5 tests=[AWL=1.029, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yg-KzNDyfAT; Thu, 9 Sep 2010 00:12:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 770E23A67CC; Thu, 9 Sep 2010 00:12:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-b0-4c888910c9ff Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EE.EC.10125.019888C4; Thu, 9 Sep 2010 09:13:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Thu, 9 Sep 2010 09:13:19 +0200 From: Christer Holmberg To: Ben Campbell , Cullen Jennings Date: Thu, 9 Sep 2010 09:13:18 +0200 Thread-Topic: secdir review of draft-ietf-simple-msrp-sessmatch Thread-Index: ActPo1ki8jw9pVdrTjKfKNpVEucoawASmCuw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850169444B@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se> <7DA8DA86-792B-44A4-A1AD-8DD6DF3FA985@estacado.net> In-Reply-To: <7DA8DA86-792B-44A4-A1AD-8DD6DF3FA985@estacado.net> 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-Brightmail-Tracker: AAAAAA== Cc: "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , Ted Hardie , "secdir@ietf.org" , IESG IESG , The IETF Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 07:12:56 -0000 Hi, I think Ben gave my clarification :) Regards, Christer =20 > -----Original Message----- > From: Ben Campbell [mailto:ben@estacado.net]=20 > Sent: 9. syyskuuta 2010 1:15 > To: Christer Holmberg; Cullen Jennings > Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org; Ted=20 > Hardie; IESG IESG; The IETF; secdir@ietf.org > Subject: Re: secdir review of draft-ietf-simple-msrp-sessmatch >=20 > (as individual) >=20 > On Sep 2, 2010, at 8:37 AM, Christer Holmberg wrote: >=20 > > Hi Cullen, > >=20 > >> Do these changes allow an SBC on the signaling path to change the=20 > >> contents of the MSRP messages without the end points being able to=20 > >> detect that? I'm sure it will be easier to answer this=20 > once we have a new draft. > >=20 > > Sessmatch does not make it any easier for an SBC in the=20 > signalling path to change the content of the MSRP messages.=20 > >=20 > > For an SBC to do MSRP message modification it will have to=20 > implement MSRP B2BUA functionality - no matter if sessmatch=20 > is supported by the endpionts or not. >=20 > I'm going to have to push on this one a little bit: >=20 > I think it _does_ make it easier for an SBC to change MSRP=20 > messages because it makes it easier for the SBC to put itself=20 > into the media path in the first place. This is no different=20 > than for any other sort of media. >=20 > The need to implement MSRP b2bUA functionality exists if the=20 > SBC changes the To-Path and From-Path headers. It may or may=20 > not be required if it wants to change _bodies_, depending on=20 > whether that change requires chunk-reassembly or changes the=20 > length of the body. And assuming, of course, there is no=20 > end-to-end protection on the MSRP messages in the first=20 > place--and we all know that in practice there probably won't be. >=20 > I think what Christer is talking about is, if sessmatch did=20 > not exist, then if an SBC were to insert itself into the MSRP=20 > media path, it would be _forced_ then to rewrite the To-Path=20 > and From-Path in each MSRP request to match the change it=20 > made in the SDP. If it did not do so, the endpoints would=20 > detect the change and treat it as an error. That is,=20 > sessmatch does not enable the insertion in the first=20 > place--it just makes things cheaper from a processing perspective. >=20 > Note that any end-to-end integrity protection on the SDP,=20 > such as RFC4474 or s/mime, will prevent SBC insertion, with=20 > or without sessmatch. Just like for any other media. >=20 >=20 > >=20 > > Regards, > >=20 > > Christer > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf >=20 > = From alexey.melnikov@isode.com Thu Sep 9 01:25:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3995C3A6A36; Thu, 9 Sep 2010 01:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-BnuUe+Phn6; Thu, 9 Sep 2010 01:25:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id EF02D3A677D; Thu, 9 Sep 2010 01:25:56 -0700 (PDT) Received: from [172.16.2.108] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 9 Sep 2010 09:26:22 +0100 Message-ID: <4C889A1F.5010208@isode.com> Date: Thu, 09 Sep 2010 09:26:07 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Hilarie Orman References: <201009082115.o88LF62w032038@fermat.rhmr.com> In-Reply-To: <201009082115.o88LF62w032038@fermat.rhmr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 08:25:58 -0000 Hi Hilarie, Hilarie Orman wrote: >Comments inline. > > >> From: Alexey Melnikov >> Subject: Re: [secdir] Security review of draft-ietf-calsify-rfc2447bis-10 >> Date: Sun, 05 Sep 2010 23:25:35 +0100 >> >> >> Hi Hilarie, >> >> Hilarie Orman wrote: >> [...] >> >The document describes the "iCalendar Message-Based Interoperability >> >Protocol (iMIP)", a protocol for transmitting calendar events over >> >SMTP. >> > >> >The security considerations are tied to authenticating the entity >> >with the role of "Organizer" or "Attendee". The authentication >> >relies on MIME security for attaching signatures and public key >> >certificates. The SMTP sender is not relevant to the authentication. >> > >> >I'm slightly puzzled by the first step listed in "Security >> >Considerations" about the steps needed to perform authentication. >> > >> > 1. Using the security mechanism compliant with [RFC-1847], determine >> > who signed the email message containing the iCalendar object. This is >> > the "signer". Note that the signer is not necessarily the person >> > sending an e-mail message since an e-mail message can be forwarded. >> > >> >The confusion stems from the phrases "who signed the email message" >> >and "the person sending". Would "who signed the MIME calendar part" >> > >> Yes. I think saying "who signed the text/calendar body part ..." would >> be even better. >> >> >> >and "the SMTP message sender" be more accurate? >> > >> Actually no. In general case SMTP message sender (i.e. the SMTP MAIL >> FROM value) has nothing to do with who is sending out the message (value >> of the message's Sender: header field). So this text is talking about >> the person associated with the Sender header field. >> >> >In the text above, you need to say which protocol the "Sender header >field" is associated with. > This is fairly obvious for somebody who knows details of how email works, but I can see this being confusing. Would adding a reference [RFC5322] (email message format) help here? >Your text speaks of e-mail and forwarding, >thus my assumption that your caveat applied to the SMTP sender. Help out >the reader by being explicit. > [...] >> >But, in general, I think that an event signed by an unknown or >> >untrusted party should be given no special considertion --- it is the >> >same as receiving an unsigned event, and "sent-by" is as irrelevant as >> >the SMTP sender. >> > >> In absence of any other information about organizer authorizing the >> "sent-by", I agree. >> But I think the existing text on this is adequate: >> >> It is possible to receive iMIP messages sent by someone working on >> behalf of another "Calendar User". This is determined by examining >> the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE" >> property. [iCAL] and [iTIP] provide no mechanism to verify that a >> "Calendar User" has authorized someone else to work on their behalf. >> To address this security issue, implementations MUST provide >> mechanisms for the "Calendar Users" to make that decision before >> applying changes from someone working on behalf of a "Calendar User". >> One way to achieve this is to reject iMIP messages sent by users >> other than the "ORGANIZER" or the "ATTENDEE"s. >> >> >> This covers the case "treat as untrusted". >> >> >> Another way is to >> prompt the user for confirmation. >> >> >This is where I would add the previously recommended text: >"Or, the receiver could have a list of trusted >proxies in its local security policy." > Ok, I will add. Thanks. >> iMIP based calendaring is frequently deployed within a single ADMD >> (Administrative Domain) [RFC5598], with boundary filtering employed >> to restrict email calendaring flows to be inside the ADMD. This can >> help in minimizing malicious changes to calendaring messages in >> transit, as well as in making authorization decisions easier. >> >> > >I'd say the decisions are not "easier" but "less risky". > Ok, will change. >Also, that paragraph sounds like a RECOMMENDATION. > It is, but, IMHO, not using normative language in this case is just fine. From ben@estacado.net Wed Sep 8 14:36:49 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 604543A67FA for ; Wed, 8 Sep 2010 14:36:49 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWbGmNOnHBmg for ; Wed, 8 Sep 2010 14:36:44 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 62FBC3A6960 for ; Wed, 8 Sep 2010 14:36:33 -0700 (PDT) Received: from dn3-174.estacado.net (dn3-174.estacado.net [172.16.3.174]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o88LarDN040332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 16:36:54 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 8 Sep 2010 16:36:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0B7E7D8D-CBC0-48C8-B642-A5E7A2D48BF2@estacado.net> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 09 Sep 2010 08:57:29 -0700 Cc: Ted Hardie , The IETF , "secdir@ietf.org" , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , "iesg@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 21:36:49 -0000 I wanted to make a quick response to one part of this discussion--see = below: On Aug 31, 2010, at 12:39 PM, Christer Holmberg wrote: >>>> To highlight one particular aspect, RFC 4975 does not require >>>> session-ids to be present, a fact noted both in the ABNF and in = this >>>> text: >>>>=20 >>>> 4. The session-id part is compared as case sensitive. A URI = without >>>> a session-id part is never equivalent to one that includes one. >>>>=20 >>>> A matching scheme which relies on a URI section which is not >>>> guaranteed to be present has some interesting problems ahead of it. = If >>>> this effectively makes their use mandatory, that requires a change = to >>>> the fundamental ABNF and text. >>>=20 >>> An MSRP URI in an SDP offer or answer for an MSRP session MUST = include a >>> session-id part, so I believe the comment is >>> based on incorrect assumptions. >>=20 >> This is not indicated in the URI matching section >=20 > We will clarify that sessmatch conformant UAs do not use MSRP URI = matching in > order to perform MSRP session matching. In fact, RFC4975 does require an MSRP URI in and SDP offer or answer to = include a session ID part. Unfortunately, it does so rather obliquely. Section 6 contains the following language: > The MSRP URI authority field identifies a participant in a particular > MSRP session. If the authority field contains a numeric IP = address, > it MUST also contain a port. The session-id part identifies a > particular session of the participant. The absence of the = session-id > part indicates a reference to an MSRP host device, but does not = refer > to a particular session at that device. =20 Section 8.2, in the last paragraph, says the following about the = rightmost URI placed in a path attribute in the SDP (Note that 4975 does = not specify MSRP relay behavior, so only the rightmost URI is in scope) > It MUST be assigned for this particular session, and MUST NOT = duplicate > any URI in use for any other session in which the endpoint is > currently participating. It SHOULD be hard to guess, and protected > from eavesdroppers. This is discussed in more detail in=20 > Section 14. >=20 This, taken together, create a requirement for a session-ID for MSRP = URIs used to identify a session in the SDP. I agree this should have = been more strongly worded. An errata entry is probably in order.=20 Thanks! Ben.= From ben@estacado.net Wed Sep 8 15:15:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32A63A696A; Wed, 8 Sep 2010 15:15:02 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUSCqm-srkcD; Wed, 8 Sep 2010 15:15:02 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id EAC703A6866; Wed, 8 Sep 2010 15:15:01 -0700 (PDT) Received: from dn3-174.estacado.net (dn3-174.estacado.net [172.16.3.174]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o88MFAYB071069 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Sep 2010 17:15:11 -0500 (CDT) (envelope-from ben@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Ben Campbell In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se> Date: Wed, 8 Sep 2010 17:15:05 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7DA8DA86-792B-44A4-A1AD-8DD6DF3FA985@estacado.net> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg , Cullen Jennings X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Thu, 09 Sep 2010 08:57:29 -0700 Cc: draft-ietf-simple-msrp-sessmatch@tools.ietf.org, Ted Hardie , secdir@ietf.org, IESG IESG , The IETF Subject: Re: [secdir] secdir review of draft-ietf-simple-msrp-sessmatch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Sep 2010 22:15:03 -0000 (as individual) On Sep 2, 2010, at 8:37 AM, Christer Holmberg wrote: > Hi Cullen, >=20 >> Do these changes allow an SBC on the signaling path to change the = contents of the MSRP messages=20 >> without the end points being able to detect that? I'm sure it will be = easier to answer this once we have=20 >> a new draft. >=20 > Sessmatch does not make it any easier for an SBC in the signalling = path to change the content of the MSRP messages.=20 >=20 > For an SBC to do MSRP message modification it will have to implement = MSRP B2BUA functionality - no matter if sessmatch is supported by the = endpionts or not. I'm going to have to push on this one a little bit: I think it _does_ make it easier for an SBC to change MSRP messages = because it makes it easier for the SBC to put itself into the media path = in the first place. This is no different than for any other sort of = media. The need to implement MSRP b2bUA functionality exists if the SBC changes = the To-Path and From-Path headers. It may or may not be required if it = wants to change _bodies_, depending on whether that change requires = chunk-reassembly or changes the length of the body. And assuming, of = course, there is no end-to-end protection on the MSRP messages in the = first place--and we all know that in practice there probably won't be. I think what Christer is talking about is, if sessmatch did not exist, = then if an SBC were to insert itself into the MSRP media path, it would = be _forced_ then to rewrite the To-Path and From-Path in each MSRP = request to match the change it made in the SDP. If it did not do so, the = endpoints would detect the change and treat it as an error. That is, = sessmatch does not enable the insertion in the first place--it just = makes things cheaper from a processing perspective. Note that any end-to-end integrity protection on the SDP, such as = RFC4474 or s/mime, will prevent SBC insertion, with or without = sessmatch. Just like for any other media. >=20 > Regards, >=20 > Christer > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From new-work-bounces@ietf.org Thu Sep 9 08:47:46 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03CC3A6A83; Thu, 9 Sep 2010 08:47:46 -0700 (PDT) X-Original-To: new-work@core3.amsl.com Delivered-To: new-work@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 737873A6A83 for ; Thu, 9 Sep 2010 08:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.022 X-Spam-Level: X-Spam-Status: No, score=-8.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1O8jQ0DYVgyg for ; Thu, 9 Sep 2010 08:47:40 -0700 (PDT) Received: from jay.w3.org (ssh.w3.org [128.30.52.60]) by core3.amsl.com (Postfix) with ESMTP id 23D063A6A76 for ; Thu, 9 Sep 2010 08:47:39 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=[IPv6:::1]) by jay.w3.org with esmtp (Exim 4.69) (envelope-from ) id 1OtjM6-0006F4-WE; Thu, 09 Sep 2010 11:48:07 -0400 Message-Id: From: Ian Jacobs To: new-work@ietf.org Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 9 Sep 2010 10:48:06 -0500 X-Mailer: Apple Mail (2.936) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: new-work-bounces@ietf.org Errors-To: new-work-bounces@ietf.org X-Mailman-Approved-At: Thu, 09 Sep 2010 08:57:29 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: HTML5 Korean Interest Group (until 2010-10-07) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Sep 2010 15:47:47 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to revise the HTML Activity [0] (see the W3C Process Document description of Activity Proposals [1]). This proposal includes a draft charter for the HTML5 Korean Interest Group: http://www.w3.org/html/ig/ko/ 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 2010-10-07 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 Mike Smith, Team Contact . Thank you, Ian Jacobs, Head of W3C Communications [0] http://www.w3.org/html/ [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 bew@cisco.com Fri Sep 10 11:16:48 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F06FB3A685C for ; Fri, 10 Sep 2010 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lwl8GICpgeuA for ; Fri, 10 Sep 2010 11:16:46 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id F365B3A6819 for ; Fri, 10 Sep 2010 11:16:45 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL4SikyrR7Hu/2dsb2JhbAChQ3GkB5sugwgGgi8EhEVShQmCfA X-IronPort-AV: E=Sophos;i="4.56,347,1280707200"; d="scan'208";a="253271130" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 10 Sep 2010 18:17:12 +0000 Received: from [128.107.147.206] ([128.107.147.206]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o8AIHCYP016825; Fri, 10 Sep 2010 18:17:12 GMT Message-Id: From: Brian Weis To: Yaron Sheffer In-Reply-To: <4C85295D.5010209@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 10 Sep 2010 11:17:09 -0700 References: <3F897C02-D8FE-4D36-9397-2018BDD23927@cisco.com> <4C85295D.5010209@gmail.com> X-Mailer: Apple Mail (2.936) Cc: Tim Polk , draft-sheffer-emu-eap-eke@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] Secdir review of draft-sheffer-emu-eap-eke-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 18:16:48 -0000 Hi Yaron, That approach below looks good to me. Regarding including the identities in the salt: I do note that the HKDF paper referenced by RFC 5869 states several times that the salt should be either a constant value (e.g., "\0"), or a value chosen at random, which I presume means that different values will be uniformly distributed over the size of the salt. I don't see a clear explanation in the paper why this is so (other than a hint in Section 9 that a random salt "prevents building universal dictionaries"). Since the identities aren't going to be random so it may be better to simply use the static value. Thanks, Brian On Sep 6, 2010, at 10:48 AM, Yaron Sheffer wrote: > Hi Brian, Dan, > > thanks for both of your reviews. > > While we do not see additional value in including the identities in > the password derivation (given that they are later bound into the > shared secret), we don't have any problem with it either. > > We are fine with making the key derivation function more standard. > We propose the following change to http://tools.ietf.org/id/draft-sheffer-emu-eap-eke-08.html#commit-request > . We define a KDF which is modeled on RFC 5869, and in fact becomes > HKDF when the MAC is an HMAC (note that the draft does *not* > constrain MAC functions to be an HMAC construction): > > PRF := mac("\0"+, P) > KEY := mac+(PRF, ID_s | ID_p) > DHComponent_S := Encr(KEY, y_s) > > PRF is truncated or zero-padded if necessary when used to derive > KEY. Neither is needed when using an HMAC function for the MAC. > > The protocol peers should store the MAC'ed password, instead of a > plaintext password. The peers have a choice of storing the output of > the first application of MAC, or that of the second application > (i.e. salted by the identities). The security benefits of the latter > should be weighed against the operational difficulty associated with > changing either of the identities. > > BTW, we have changed the "kmac" terminology into "mac", per your > comments. > > The operator mac+ will be redefined as: > > mac+(key, string) = T1 | T2 ... > > where each Ti is an application of the keyed MAC with a fixed key: > > T1 = mac(key, string | 0x01) > T2 = mac(key, T1 | string | 0x02) > T3 = mac(key, T2 | string | 0x03) > > Please let us know if this change resolves your concerns. > > Thanks, > Yaron > > On 08/17/2010 06:52 AM, Brian Weis 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 review comments. >> >> I previously reviewed -06 of this I-D and made a number of >> suggestions. >> The current version has addressed those as well as other last call >> comments. I have just one concern and one comment regarding the >> changes >> regarding encrypting DHComponent_S and DHComponent_P in on-the-wire >> payloads. This is described in Sections 5.1, 5.2, and 6.1. I'm >> going to >> discuss DHComponent_S, but DHComponent_P is similarly changed. >> >> 1. In -06, DHComponent_S was protected with an IKEv2-style prf+(): >> DHComponent_S = Encr(prf+(password, "EAP-EKE Password"), y_s), >> In -07, DHComponent_S is now protected with a "keyed MAC": >> DHComponent_S = Encr(kmac+(password), y_s) >> where kmac+() is defined as: >> kmac+(P) = T1 | T2 | ... >> where each Ti is an application of the keyed MAC with a fixed key: >> T1 = kmac("S"+, P | 0x01) >> T2 = kmac("S"+, T1 | P | 0x02) >> T3 = kmac("S"+, T2 | P | 0x03) >> Dan Harkins suggested an "extractor and expander" KDF, which I >> believe >> motivated this change. I think the use of a constant "salt" value >> used >> as a key in kmac+ approximates only the "extractor" function >> described >> in RFC 5869, and the output of an "extractor" is not intended to be >> the >> final KDF output. An "expander" function is necessary to follow the >> "extractor" function, and prf+ fits that description. So unless I'm >> mistaken, these section should define two calls: one to kmac() to to >> create an intermediate value of the appropriate size, and the another >> that uses the intermediate value as the key to a prf+ call. >> >> I think it might be convenient to require the kmac+ and prf+ >> algorithms >> be the same. >> >> 2. As far as I can tell, the definition of "kmac" is new to this I-D, >> which I found a bit confusing. It's really just a MAC, so I think it >> would be clearer to just call it a mac(). >> >> Brian >> >> >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir -- Brian Weis Security Standards and Technology, ARTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From bew@cisco.com Fri Sep 10 15:26:38 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB1AA3A680F; Fri, 10 Sep 2010 15:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGxbAwRgsAFR; Fri, 10 Sep 2010 15:26:38 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 37D3A3A6807; Fri, 10 Sep 2010 15:26:38 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFZNikyrR7Ht/2dsb2JhbAChRnGlD5tEhT0EhEWFW4J8 X-IronPort-AV: E=Sophos;i="4.56,348,1280707200"; d="scan'208";a="586977257" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 10 Sep 2010 22:27:05 +0000 Received: from [128.107.147.206] ([128.107.147.206]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8AMR53w005168; Fri, 10 Sep 2010 22:27:05 GMT Message-Id: <4C35EDD5-43C1-4621-B392-5EB98F9ADE22@cisco.com> From: Brian Weis To: secdir@ietf.org, iesg@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 10 Sep 2010 15:26:56 -0700 X-Mailer: Apple Mail (2.936) Cc: draft-ietf-netmod-dsdl-map@tools.ietf.org, netmod-chairs@tools.ietf.org Subject: [secdir] Secdir review of draft-ietf-netmod-dsdl-map-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Sep 2010 22:26:39 -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 review comments. This document specifies the mapping rules for translating the YANG data modeling language to the Document Schema Definition Languages (DSDL), a set of XML scheme languages. The security considerations section seems sufficient. I do not see the need for any changes. Brian From weiler@watson.org Sat Sep 11 08:19:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF03A3A6805 for ; Sat, 11 Sep 2010 08:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[AWL=0.863, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0QvKaq2OidhF for ; Sat, 11 Sep 2010 08:19:10 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 39F8C3A67E4 for ; Sat, 11 Sep 2010 08:19:10 -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 o8BFJaUH011910 for ; Sat, 11 Sep 2010 11:19:36 -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 o8BFJaY2011907 for ; Sat, 11 Sep 2010 11:19:36 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 11 Sep 2010 11:19:36 -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; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 11 Sep 2010 11:19:36 -0400 (EDT) Subject: [secdir] XMPP specs coming soon to secdir (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 11 Sep 2010 15:19:11 -0000 Would any of you be especially interested in reviewing the XMPP specs? For something this large, accepting a volunteer (or three) might be better than the usual round-robin. -- Sam ---------- Forwarded message ---------- Date: Fri, 10 Sep 2010 06:08:58 -0600 From: Peter Saint-Andre To: Sean Turner , Tim Polk , secdir-secretary@mit.edu Subject: XMPP specs coming soon to secdir FYI, draft-ietf-xmpp-3920bis is coming soon to a secdir near you (followed soon after by 3921bis). It weighs in at 183 pages and the Security Considerations section is quite extensive. Forewarned is forearmed. :) Peter -- Peter Saint-Andre https://stpeter.im/ From weiler@watson.org Sat Sep 11 08:32:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D03383A6805 for ; Sat, 11 Sep 2010 08:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.822 X-Spam-Level: X-Spam-Status: No, score=-1.822 tagged_above=-999 required=5 tests=[AWL=0.777, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xF4pR1A0MpL8 for ; Sat, 11 Sep 2010 08:32:51 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id F0A6B3A6403 for ; Sat, 11 Sep 2010 08:32:50 -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 o8BFXGkC014136 for ; Sat, 11 Sep 2010 11:33:17 -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 o8BFXGlC014132 for ; Sat, 11 Sep 2010 11:33:16 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 11 Sep 2010 11:33:16 -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]); Sat, 11 Sep 2010 11:33:17 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 11 Sep 2010 15:32:55 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Shawn Emery is next in the rotation. For telechat 2010-09-23 Reviewer LC end Draft Dave Cridland T 2010-09-21 draft-ietf-tcpm-urgent-data-06 Donald Eastlake T 2010-09-21 draft-ietf-mext-nemo-pd-06 Sam Weiler T 2010-09-03 draft-ietf-opsec-igp-crypto-requirements-00 Glen Zorn T 2010-07-26 draft-cakulev-mikey-ibake-02 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2010-09-14 draft-ietf-eai-frmwrk-4952bis-07 Rob Austein - draft-ietf-grow-bgp-graceful-shutdown-requirements-04 Richard Barnes 2010-09-24 draft-ietf-grow-mrt-13 Alan DeKok - draft-ietf-v6ops-cpe-simple-security-12 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 Barry Leiba 2010-08-12 draft-saintandre-tls-server-id-check-09 David McGrew - draft-ietf-ecrit-framework-11 David McGrew 2010-08-05 draft-ietf-pce-manageability-requirements-10 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Vincent Roca 2010-08-23 draft-ietf-fecframe-framework-10 Nico Williams 2010-09-10 draft-ietf-fecframe-sdp-elements-08 Tom Yu 2010-09-27 draft-gundavelli-v6ops-l2-unicast-04 Kurt Zeilenga 2010-09-16 draft-ietf-ccamp-lsp-hierarchy-bis-08 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From rbarnes@bbn.com Sun Sep 12 12:03:51 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA63E3A6903; Sun, 12 Sep 2010 12:03:51 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id llIXKVTqyMoA; Sun, 12 Sep 2010 12:03:50 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 8EAA73A6827; Sun, 12 Sep 2010 12:03:50 -0700 (PDT) Received: from [128.89.254.228] (port=51340 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Ourqa-000BHF-Ej; Sun, 12 Sep 2010 15:04:16 -0400 Message-Id: <0F98AA73-75ED-468B-B16A-9F4D386598F9@bbn.com> From: "Richard L. Barnes" To: secdir@ietf.org, iesg@ietf.org, IETF Discussion , draft-ietf-grow-mrt@tools.ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 12 Sep 2010 15:04:14 -0400 X-Mailer: Apple Mail (2.936) Subject: [secdir] secdir review of draft-ietf-grow-mrt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Sep 2010 19:03:51 -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 defines a data format that routers can use to export information about routing state (e.g., routing tables), and about routing protocol messages that they have received. The security considerations in the document note that the fields in an MRT object are descriptive, so because they do not lead to any particular action by a recipient, they do not create any security concerns. This is mostly correct. My only concern is that some of the information in an MRT object could be considered private, especially given that MRT is commonly used to publish router dumps (e.g., through RouteViews [1]). For example, BGP neighbors that advertise paths to their peers might not expect these paths to be published in an MRT dump. There is also a proposed extension to MRT that would add geolocation information about the router and its peers [2]. I would suggest that the document add a brief note that some information contained in MRT dumps might be considered private. Suggested text based on the above: " Some information contained in an MRT data structure might be considered sensitive or private. For example, a BGP peer that sends a message to an MRT-enabled router might not expect that message to be shared beyond the AS to which it is sent. The proposed geolocation extension to MRT could reveal the location of an MRT router's peers [I- D.ietf-grow-geomrt]. An organization that intends to use the MRT structure to export routing information beyond the domain where it normally accessible (e.g., publishing MRT dumps for use by researchers) should verify with any peers whose information might be included, and possibly remove sensitive fields. " Other than that, I do not believe this document raises any security concerns. [1] [2] From dave.cridland@isode.com Mon Sep 13 01:52:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A9C3A6925; Mon, 13 Sep 2010 01:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGEDmSGytdbz; Mon, 13 Sep 2010 01:52:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 214EB3A67EC; Mon, 13 Sep 2010 01:52:20 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Sep 2010 09:51:12 +0100 X-SMTP-Protocol-Errors: NORDNS Message-Id: <2234.1284367866.672579@puncture> Date: Mon, 13 Sep 2010 09:51:06 +0100 From: Dave Cridland To: The IESG , , Apps Area Review List , Security Area Directorate MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="iso-8859-1"; format="flowed" Content-transfer-encoding: quoted-printable Subject: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 08:52:21 -0000 I have reviewed this document as part of the security directorate's =20 ongoing effort to review all IETF documents being processed by the =20 IESG. These comments were written primarily for the benefit of the =20 security area directors. Document editors and WG chairs should treat =20 these comments just like any other last call comments. In addition, I have been selected as the Apps Reviewer for this =20 document. These comments are similarly written for the benefit of =20 apps area directors, and document editors and WG chairs should treat =20 these comments just like any other last call comments. I have not made any distinction between the comments. Summary: Whilst I agree with the essential premise - that TCP URG is =20 implemented in a different way to that specified, and should be =20 homogenized in favour of the deployed implementations - I feel that =20 both SeolMa and the proposed solution needs to be expanded upon. Simply dropping TCP Urgent data facilities removes an aspect of TCP =20 which - whilst not commonly used in most modern protocols - is =20 nevertheless still used for useful gain in FTP and TELNET. Specific recommendations are at the bottom. Background: The TCP urgent mechanism, as implemented, means that a single octet =20 is lost when the receiver handles the last "Urgent" data section. =20 Thus particularly when multiple urgent data segments are "in flight", =20 it becomes difficult to guess which octets will be lost by the =20 receiver. The SeolMa attack effectively uses these lost octets to pad =20 strings used in TCP based application protocols, thus defeating na=EFve =20 NIDS pattern matching. There is no discussion in the draft about SeolMa, indeed there isn't =20 even a mention of it in the Security Considerations. It's not clear =20 to me if the recommendation to use SO_OOBINLINE would have an effect =20 here - my gut feeling is that it would defeat SeolMa by making these =20 "lost" octets part of the normal data flow again. Cisco's solution relies on simply forcing urgent data to be =20 non-urgent, which will have knock-on effects on TELNET and FTP by =20 default. It's not clear to me from this document (including reading =20 the references) By instituting a blanket ban, in effect, for TCP Urgent data, this =20 effectively deprecates the entire mechanism. This may prove to be the =20 only solution, however my general feeling is that this may not be the =20 case. Niggle: The Cisco-PIX reference does not describe the TCP Urgent behaviour =20 except by implication (it mentions adding rules to allow its use for =20 TELNET and FTP-PI, but that's it). I have a personal distaste for =20 product placement in RFCs, and would prefer that this reference =20 pointed at least at a Cisco paper describing default behaviour, etc. As an aside, the Cisco instructions actually show the user how to =20 enable urgent data on FTP-DTP, rather than FTP-PI, which is incorrect. Specific Recommendations: - An informative reference to FTP and TELNET, noting how and why the =20 URG pointer is used, would make it more obvious what is lost here. - A more detailed description of SeolMa, and its implications, would =20 be useful, and I think required in the Security Considerations =20 section. - I feel that further consideration of the proposed solution to =20 SeolMa is warranted. Dave. From dave.cridland@isode.com Mon Sep 13 01:52:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6CDC3A6925 for ; Mon, 13 Sep 2010 01:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D3liuXf5dUR4 for ; Mon, 13 Sep 2010 01:52:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 885033A6822 for ; Mon, 13 Sep 2010 01:52:40 -0700 (PDT) Received: from puncture ((unknown) [217.155.137.60]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Mon, 13 Sep 2010 09:52:46 +0100 X-SMTP-Protocol-Errors: NORDNS PIPELINING References: In-Reply-To: Message-Id: <2234.1284367871.801309@puncture> Date: Mon, 13 Sep 2010 09:51:11 +0100 From: Dave Cridland To: "secdir-secretary@mit.edu" , Security Area Directorate MIME-Version: 1.0 Content-Type: text/plain; delsp="yes"; charset="us-ascii"; format="flowed" Subject: Re: [secdir] XMPP specs coming soon to secdir (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 08:52:41 -0000 On Sat Sep 11 16:19:36 2010, Samuel Weiler wrote: > Would any of you be especially interested in reviewing the XMPP > specs? For something this large, accepting a volunteer (or three) > might be better than the usual round-robin. I'm far too involved in XMPP to provide a useful objective review, but I'd be happy to help answer questions (via XMPP or email) for any reviewers. Dave. From rdroms.ietf@gmail.com Mon Sep 13 07:20:46 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D6793A69C3; Mon, 13 Sep 2010 07:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.524 X-Spam-Level: X-Spam-Status: No, score=-108.524 tagged_above=-999 required=5 tests=[AWL=2.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXQHnZo8FLFS; Mon, 13 Sep 2010 07:20:43 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B16F63A696B; Mon, 13 Sep 2010 07:20:42 -0700 (PDT) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.56,359,1280707200"; d="scan'208";a="238180212" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2010 14:21:09 +0000 Received: from sjc-vpnasa1-32.cisco.com (sjc-vpnasa1-32.cisco.com [10.21.104.32]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8DEL6hb018178; Mon, 13 Sep 2010 14:21:07 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=windows-1252 From: Ralph Droms In-Reply-To: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> Date: Mon, 13 Sep 2010 16:21:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> To: Roque Gagliano X-Mailer: Apple Mail (2.1078) X-Mailman-Approved-At: Tue, 14 Sep 2010 08:01:47 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, Sandra Murphy , =?iso-8859-1?Q?Alberto_Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, IESG IESG , csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 14:20:46 -0000 Can you clarify the status of draft-ietf-csi-send-cert and = draft-ietf-csi-proxy-send? Does the new rev of draft-ietf-csi-send-cert = address the DISCUSS positions on both docs? - Ralph On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: > Hi Sandra, >=20 > I issued a new version of the draft draft-ietf-csi-send-cert = documents. >=20 > I believe the new version addresses all the concerns expressed in this = mail exchange. >=20 > Regards, >=20 > Roque >=20 >=20 >=20 >=20 > On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote: >=20 >> Hi, >> The text of this email has been extracted from a thorough review of = draft-ietf-csi-proxy-send being made by Sandra Murphy. >> The reason why the email has been separated is to include the authors = of draft-ietf-csi-send-cert in the discussion of this part of the text, = since I think some of the issues raised by Sandra affect this document. >> =20 >> I include my comments inline. >> =20 >> | -----Mensaje original----- >> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >> | Enviado el: viernes, 02 de julio de 2010 2:31 >> | Para: iesg@ietf.org; secdir@ietf.org; = draft-ietf-csi-proxy-send.all@tools.ietf.org >> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 >> |=20 >> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. >> |=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 >> | This document provides new Neighbor Discovery options that will = secure >> | proxied Neighbor Discovery messages. It is an update to: >> |=20 >> | RFC4861: Neighbor Discovery in IPv6 >> | RFC4389: Neighbor Discovery Proxies (ND Proxy) >> | RFC3971: Send Neighbor Discovery (SEND) >> |=20 >> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. >> |=20 >> | The need for new mechanisms for security for proxied messages is = explained >> | in draft-ietf-csi-sndp-prob-04.txt. >> |=20 >> | I've read all of these, but it is pretty new to me, so I could = have missed >> | something. >> |=20 >> | The Neighbor Discovery protocol communicates link-level addresses = in the >> | protocol messages. The ND Proxy extension would make changes to = those >> | fields. SEND, which secures the base ND protocol, relies on the = sender of >> | a message computing a signature associated with the source IP = address of >> | the message. Any ND Proxy changes to messages would invalidate = the >> | signature and the ND Proxy itself could not generate a new = signature >> | (since it would not have the private key associated with the = source IP >> | address). This draft introduces a Proxy Signature (PS) option to = secure >> | the proxied messages. >> |=20 >> | RFC3971, the base SEND spec, defines a new Router Authorization >> | Certificate profile, dependent on RFC3779, which authorizes the = router to >> | act as a router and act for certain prefixes. Message = authorization in >> | SEND of some ND messages checks the prefixes listed in the = certificate >> | against the prefixes mentioned in those messages. There is no = explicit >> | representation in the certificate of the authority to act as a = router. >> | Possession of the certificate in SEND serves as implicit = authorization to >> | act as a router, as that was the only authorization defined. >> |=20 >> | With the introduction of proxies, there was a need to distinguish = the >> | various roles that a node might have in the network. No longer is >> | possession of a certificate adequate authorization. The draft >> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to = distinguish >> | three different roles: router, proxy and owner. That draft notes = that >> | multiple key purposes are possible. I believe that it is also = possible to >> | have single roles =96 so a node could be a proxy but not a router. >> =20 >> Yes, of course single roles are supported. >> =20 >> | With the extensions of the csi-send-cert draft, possession of a >> | certificate is no longer proof of any particular authorization. = It seem >> | clear to me that the authorization validation described in RFC3971 = is no >> | longer sufficient. I believe that a discussion is needed of what = messages >> | require or allow each particular key purpose authorization. = Issuing an >> | RA, for example, seems likely to require the "router" value of the = key >> | purpose field, if the new certificate format was used for = authorization. >> | Issuing an NA may require the "owner" value of the key purpose = field, if >> | the new certificate format was used for authorization rather than = a CGA. >> | I do not know if that discussion would be more appropriate here or = in the >> | csi-send-cert draft, or another draft entirely that updates = RFC3971 >> | directly. >> |=20 >> | If a SPND proxy was using SEND to communicate with other nodes = that >> | understood SPND, would it be OK to use a new format cert (with the >> | "router" KeyPurposeId) as a router certificate for the SEND RSA = Signature >> | Options? >> |=20 >> I see. I agree that this needs more precision. >> =20 >> In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in = cert-04) it discusses the messages that are authorized by each = KeyPurposeId >> - "router authorization value indicates that the >> certificate has been issued for allowing the router to advertise >> prefix(es)" >> (I understand that implicitly states that it authorizes the = generation of RA messages. It is not crystal clear for me if it = authorizes NA for routers, although if I had to take this text = literally, I would suppose routers would need an 'owner' authorization = if this PKI model substitutes RFC3971 CGA authorization, considering = that the prefix for NA would be narrowed in general to one address, = while the RA authorization is prefix-wide) >> - "proxy authorization value indicates that the >> certificate has been issued for allowing the proxy to perform >> proxying of neighbor discovery messages for the prefix(es) that = are >> mentioned using the X.509 extensions for IP addresses" >> (I understand it now implicitly states it authorizes for ANY neighbor = discovery message. By the way, this is the assumption underlying in = general draft-ietf-csi-proxy-send-04: in the application scenarios, some = require RA proxying, which is assumed to be performed by means of the = proxy cert) >> - "owner authorization [...]For an >> address in such certificate the host can assign the address, send/ >> receive traffic from this address, and can respond to NSes about = that >> address" >> (this is the clearest of all statements - although I think issuing = secured NS and RS should also be considered) >> =20 >> So, as defined now in draft-ietf-csi-proxy-send-04, proxy = certificates provide authorization for securing *any* ND message. = Considering the application scenarios, some require proxying RA (PMIPv6 = and RFC4389), and the MIPv6 scenario just require NS/NA proxying. >> =20 >> In summary so far, there is some specification of the authorization = in draft-csi-send-cert, which I think it would be nice that it could be = refined, and if so, my opinion is that the refinement of which ND = message is authorized by each KeyPurposeId should be in that document. >> However, continuing with this issue, I must say that the way the = 'proxy authorization' is defined, and the relationship with the other = cases, is not satisfactory for me. >> I think the use of 'owner' should be restricted for hosts that really = own the address (therefore, a substitution of the CGA mechanism) - as = opposed to proxies. >> For the 'proxy authorization', I think it could be refined into = something like =93proxy host=94 authorization, and =93proxy router=94 = authorization. >> =91Proxy host=92 would authorize for proxying NA, NS and RS, and = =93proxy router=94 authorization would authorize RA and Redirect. This = would provide a finer grain which I think would be desirable (for = example, MIPv6 does not need protecting neither RA nor redirect). >> I think this would work (if so, it should be changed in = draft-csi-send-cert). >> =20 >> What do you think? (both authors of draft-csi-send-cert, Sandra, = etc.). >> =20 >> Regards, >> Alberto >> =20 >> =20 >=20 From rogaglia@cisco.com Mon Sep 13 07:28:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457213A69C3; Mon, 13 Sep 2010 07:28:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.359 X-Spam-Level: X-Spam-Status: No, score=-10.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eb1KqMya3gLI; Mon, 13 Sep 2010 07:28:55 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7C2ED3A697E; Mon, 13 Sep 2010 07:28:54 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 3815 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM/RjUxAZnwM/2dsb2JhbAChRnGmS5sbAoU+BIongn0 X-IronPort-AV: E=Sophos;i="4.56,359,1280707200"; d="p7s'?scan'208";a="158778965" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Sep 2010 14:29:15 +0000 Received: from [144.254.21.40] ([144.254.21.40]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8DETCsB014426; Mon, 13 Sep 2010 14:29:13 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-180--1009211765; protocol="application/pkcs7-signature"; micalg=sha1 From: Roque Gagliano In-Reply-To: Date: Mon, 13 Sep 2010 16:29:09 +0200 Message-Id: <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> To: Ralph Droms X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 14 Sep 2010 08:01:47 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, Sandra Murphy , =?iso-8859-1?Q?Alberto_Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, IESG IESG , csi-chairs@tools.ietf.org Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 14:28:57 -0000 --Apple-Mail-180--1009211765 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Ralph, I can answer for the draft-ietf-csi-send-cert document. The new revision = addressed all the DISCUSS positions for that document. As I mentioned in a previous email, we came back to the WG to ask one = change that is been requested by one of the authors of the = draft-ietf-csi-proxy-send document. The change consist of adding a new = EKU. I think is best to wait for the WG opinion on this issue because if this = additional EKU is needed, it makes sense to have it in this same = document. Regards, Roque. = --------------------------------------------------------------------------= -------------------------------------------------------------------- Roque Gagliano = Cisco Systems International S=E0rl=09 Software Engineer = Mailstop ROL01/2/ Corporate Development Technology Group = Avenue des Uttins 5 = 1180 Rolle rogaglia@cisco.com = Switzerland Phone: +41 21 823 2805 = =09 For corporate legal information go to: = http://www.cisco.com/web/about/doing_business/legal/cri/index.html On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote: > Can you clarify the status of draft-ietf-csi-send-cert and = draft-ietf-csi-proxy-send? Does the new rev of draft-ietf-csi-send-cert = address the DISCUSS positions on both docs? >=20 > - Ralph >=20 > On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: >=20 >> Hi Sandra, >>=20 >> I issued a new version of the draft draft-ietf-csi-send-cert = documents. >>=20 >> I believe the new version addresses all the concerns expressed in = this mail exchange. >>=20 >> Regards, >>=20 >> Roque >>=20 >>=20 >>=20 >>=20 >> On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote: >>=20 >>> Hi, >>> The text of this email has been extracted from a thorough review of = draft-ietf-csi-proxy-send being made by Sandra Murphy. >>> The reason why the email has been separated is to include the = authors of draft-ietf-csi-send-cert in the discussion of this part of = the text, since I think some of the issues raised by Sandra affect this = document. >>>=20 >>> I include my comments inline. >>>=20 >>> | -----Mensaje original----- >>> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>> | Enviado el: viernes, 02 de julio de 2010 2:31 >>> | Para: iesg@ietf.org; secdir@ietf.org; = draft-ietf-csi-proxy-send.all@tools.ietf.org >>> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 >>> |=20 >>> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. >>> |=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 >>> | This document provides new Neighbor Discovery options that will = secure >>> | proxied Neighbor Discovery messages. It is an update to: >>> |=20 >>> | RFC4861: Neighbor Discovery in IPv6 >>> | RFC4389: Neighbor Discovery Proxies (ND Proxy) >>> | RFC3971: Send Neighbor Discovery (SEND) >>> |=20 >>> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. >>> |=20 >>> | The need for new mechanisms for security for proxied messages is = explained >>> | in draft-ietf-csi-sndp-prob-04.txt. >>> |=20 >>> | I've read all of these, but it is pretty new to me, so I could = have missed >>> | something. >>> |=20 >>> | The Neighbor Discovery protocol communicates link-level addresses = in the >>> | protocol messages. The ND Proxy extension would make changes to = those >>> | fields. SEND, which secures the base ND protocol, relies on the = sender of >>> | a message computing a signature associated with the source IP = address of >>> | the message. Any ND Proxy changes to messages would invalidate = the >>> | signature and the ND Proxy itself could not generate a new = signature >>> | (since it would not have the private key associated with the = source IP >>> | address). This draft introduces a Proxy Signature (PS) option to = secure >>> | the proxied messages. >>> |=20 >>> | RFC3971, the base SEND spec, defines a new Router Authorization >>> | Certificate profile, dependent on RFC3779, which authorizes the = router to >>> | act as a router and act for certain prefixes. Message = authorization in >>> | SEND of some ND messages checks the prefixes listed in the = certificate >>> | against the prefixes mentioned in those messages. There is no = explicit >>> | representation in the certificate of the authority to act as a = router. >>> | Possession of the certificate in SEND serves as implicit = authorization to >>> | act as a router, as that was the only authorization defined. >>> |=20 >>> | With the introduction of proxies, there was a need to distinguish = the >>> | various roles that a node might have in the network. No longer = is >>> | possession of a certificate adequate authorization. The draft >>> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to = distinguish >>> | three different roles: router, proxy and owner. That draft notes = that >>> | multiple key purposes are possible. I believe that it is also = possible to >>> | have single roles =96 so a node could be a proxy but not a = router. >>>=20 >>> Yes, of course single roles are supported. >>>=20 >>> | With the extensions of the csi-send-cert draft, possession of a >>> | certificate is no longer proof of any particular authorization. = It seem >>> | clear to me that the authorization validation described in = RFC3971 is no >>> | longer sufficient. I believe that a discussion is needed of what = messages >>> | require or allow each particular key purpose authorization. = Issuing an >>> | RA, for example, seems likely to require the "router" value of = the key >>> | purpose field, if the new certificate format was used for = authorization. >>> | Issuing an NA may require the "owner" value of the key purpose = field, if >>> | the new certificate format was used for authorization rather than = a CGA. >>> | I do not know if that discussion would be more appropriate here = or in the >>> | csi-send-cert draft, or another draft entirely that updates = RFC3971 >>> | directly. >>> |=20 >>> | If a SPND proxy was using SEND to communicate with other nodes = that >>> | understood SPND, would it be OK to use a new format cert (with = the >>> | "router" KeyPurposeId) as a router certificate for the SEND RSA = Signature >>> | Options? >>> |=20 >>> I see. I agree that this needs more precision. >>>=20 >>> In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in = cert-04) it discusses the messages that are authorized by each = KeyPurposeId >>> - "router authorization value indicates that the >>> certificate has been issued for allowing the router to advertise >>> prefix(es)" >>> (I understand that implicitly states that it authorizes the = generation of RA messages. It is not crystal clear for me if it = authorizes NA for routers, although if I had to take this text = literally, I would suppose routers would need an 'owner' authorization = if this PKI model substitutes RFC3971 CGA authorization, considering = that the prefix for NA would be narrowed in general to one address, = while the RA authorization is prefix-wide) >>> - "proxy authorization value indicates that the >>> certificate has been issued for allowing the proxy to perform >>> proxying of neighbor discovery messages for the prefix(es) that = are >>> mentioned using the X.509 extensions for IP addresses" >>> (I understand it now implicitly states it authorizes for ANY = neighbor discovery message. By the way, this is the assumption = underlying in general draft-ietf-csi-proxy-send-04: in the application = scenarios, some require RA proxying, which is assumed to be performed by = means of the proxy cert) >>> - "owner authorization [...]For an >>> address in such certificate the host can assign the address, send/ >>> receive traffic from this address, and can respond to NSes about = that >>> address" >>> (this is the clearest of all statements - although I think issuing = secured NS and RS should also be considered) >>>=20 >>> So, as defined now in draft-ietf-csi-proxy-send-04, proxy = certificates provide authorization for securing *any* ND message. = Considering the application scenarios, some require proxying RA (PMIPv6 = and RFC4389), and the MIPv6 scenario just require NS/NA proxying. >>>=20 >>> In summary so far, there is some specification of the authorization = in draft-csi-send-cert, which I think it would be nice that it could be = refined, and if so, my opinion is that the refinement of which ND = message is authorized by each KeyPurposeId should be in that document. >>> However, continuing with this issue, I must say that the way the = 'proxy authorization' is defined, and the relationship with the other = cases, is not satisfactory for me. >>> I think the use of 'owner' should be restricted for hosts that = really own the address (therefore, a substitution of the CGA mechanism) = - as opposed to proxies. >>> For the 'proxy authorization', I think it could be refined into = something like =93proxy host=94 authorization, and =93proxy router=94 = authorization. >>> =91Proxy host=92 would authorize for proxying NA, NS and RS, and = =93proxy router=94 authorization would authorize RA and Redirect. This = would provide a finer grain which I think would be desirable (for = example, MIPv6 does not need protecting neither RA nor redirect). >>> I think this would work (if so, it should be changed in = draft-csi-send-cert). >>>=20 >>> What do you think? (both authors of draft-csi-send-cert, Sandra, = etc.). >>>=20 >>> Regards, >>> Alberto >>>=20 >>>=20 >>=20 >=20 --Apple-Mail-180--1009211765 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKHjCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFSjCCBDKgAwIBAgIQL5vTKNUCwWQOjacT KoWGmzANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDUxMjAwMDAwMFoXDTExMDUxMjIzNTk1OVowggETMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDlJvcXVlIEdh Z2xpYW5vMSEwHwYJKoZIhvcNAQkBFhJyb2dhZ2xpYUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQDGyowL31WLYDEbY59gvyg0OcBMh/AqsE5EpWzobCsYs1secYJvZlKm 5+2CjNWTQziHYo19cp7DG9XDLLGdLW7HC0VikR65cxIURXJoUKQO3QJYV99mrtnwCKf/FyzxeF11 pRILFbkgvpAZjCLig/RgNLt5cGGl8FGCe22sBWdBxU+sQiffsS774edvd3xFiRPaB/sOVPc4fbvw twOkEuas4IaH9Oivt1ZUvrFmBnS8mCYbk0OKjKjIEeS62TPsGCZv3f9Ffgm0Az4On6MiP1dARKp/ it5aow047hoFNXFCsWVLeEyDLk3avqS3/9fH//9NWvj0Mq/FhkaEw4Sv66TLAgMBAAGjgcwwgckw CQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZl cmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBAIxI8f9LAL0e mThKlUnwxlBH+q2htxBy9vBt24uGl8dunGyK4Aq7PAQiCF2XJfM2sWSRpdkIdbd9cD5upkcteP4s pL/T85qsfT1dLiQDTZ6/o19umk6DkqG0DpR+n+7jTUGdCzDhhzTZZblqY0afimcQ79uqZcF5ojDl N5Np93N3djqAmD37aKG1KE8xzBP0WiwxfVIGYua098YIsioWb0zvGmPd9JdMO55+jwkjFAOsT5kK ivXkjDnZJ1HM8GVQjGPnYBDEJBmC2B+kdbpi17cntYE/6V/SgrpB4t14YuswgMYRh1lGP7eKiiAj mwnaJL9aMMrqBwHLY/BLEA+3hRsxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNV BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEe MBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAx IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYabMAkGBSsOAwIa BQCgggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDkxMzE0 MjkxMFowIwYJKoZIhvcNAQkEMRYEFC+RmaNGfaqG1YQSLqyDQT6DsbxaMIIBAwYJKwYBBAGCNxAE MYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczov L3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0g RzICEC+b0yjVAsFkDo2nEyqFhpswggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMC VVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3Jw YSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2ln biBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAvm9Mo1QLBZA6NpxMqhYab MA0GCSqGSIb3DQEBAQUABIIBAGsxhaWSLUTIWWaTIxqeUeWOprIEtoIznN1EE3MMhGZqXHdgDpMJ 5hxLsECVSmYQOtgQpFZQi+7zuRuSXYRhV4crfk4A6r2tnd48zV2SLwStMh8U5mCOL5KOKY5FjSRm 1d1ANw72DnQFzrdV0HHlaMj6cmpqia1SmqzVCqLMwdVkaWjNaMIHBru2pKPt/ULW4zXsLZ7Yy3ik SfqDW9fC2HMw/V7zw9s32gV5WoFm2VUcYteFqzEBuA/nll344a5LCHwSiXqmyKyd/ZwSRZBwiHR6 iuhxcVnT5HtRVeCmf2bn3p6O0hjEJTkuSJsRacv3f4jpcUsFORzh733sluGBk+sAAAAAAAA= --Apple-Mail-180--1009211765-- From marcelo@it.uc3m.es Mon Sep 13 08:23:18 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 447C03A69EA; Mon, 13 Sep 2010 08:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.457 X-Spam-Level: X-Spam-Status: No, score=-106.457 tagged_above=-999 required=5 tests=[AWL=0.142, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PE6fTHyZRh1B; Mon, 13 Sep 2010 08:23:16 -0700 (PDT) Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id D088B3A69D8; Mon, 13 Sep 2010 08:23:15 -0700 (PDT) X-uc3m-safe: yes Received: from marcelo-bagnulos-macbook-pro.local (73.31.18.95.dynamic.jazztel.es [95.18.31.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id 4F21BBEA8BA; Mon, 13 Sep 2010 17:23:37 +0200 (CEST) Message-ID: <4C8E41F6.906@it.uc3m.es> Date: Mon, 13 Sep 2010 17:23:34 +0200 From: marcelo bagnulo braun User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; es-ES; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Roque Gagliano References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> In-Reply-To: <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17636.000 X-Mailman-Approved-At: Tue, 14 Sep 2010 08:01:47 -0700 Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, Sandra Murphy , =?windows-1252?Q?Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, =?windows-1252?Q?Alberto_?=, Ralph Droms , csi-chairs@tools.ietf.org, IESG IESG Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 15:23:18 -0000 El 13/09/10 16:29, Roque Gagliano escribió: > Hi Ralph, > > I can answer for the draft-ietf-csi-send-cert document. The new revision addressed all the DISCUSS positions for that document. > > As I mentioned in a previous email, we came back to the WG to ask one change that is been requested by one of the authors of the draft-ietf-csi-proxy-send document. The change consist of adding a new EKU. > > I think is best to wait for the WG opinion on this issue because if this additional EKU is needed, it makes sense to have it in this same document. > Right, the problem is that the WG is slient, so we probably need to solve this in some other way i.e. propose something to the WG and see if anybody objects. The new EKU is the proposed way to deal with one comment from Sandy's review of the proxy send document. It seems we could live without, but it would be a somehow inferior solution. I would suggest that unless getting a new EKU is a lot of work, we go ahead with that. would that make sense? Regards, marcelo > Regards, > Roque. > > ---------------------------------------------------------------------------------------------------------------------------------------------- > Roque Gagliano Cisco Systems International Sàrl > Software Engineer Mailstop ROL01/2/ > Corporate Development Technology Group Avenue des Uttins 5 > 1180 Rolle > rogaglia@cisco.com Switzerland > Phone: +41 21 823 2805 > > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote: > >> Can you clarify the status of draft-ietf-csi-send-cert and draft-ietf-csi-proxy-send? Does the new rev of draft-ietf-csi-send-cert address the DISCUSS positions on both docs? >> >> - Ralph >> >> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: >> >>> Hi Sandra, >>> >>> I issued a new version of the draft draft-ietf-csi-send-cert documents. >>> >>> I believe the new version addresses all the concerns expressed in this mail exchange. >>> >>> Regards, >>> >>> Roque >>> >>> >>> >>> >>> On Jul 6, 2010, at 5:32 PM, Alberto García wrote: >>> >>>> Hi, >>>> The text of this email has been extracted from a thorough review of draft-ietf-csi-proxy-send being made by Sandra Murphy. >>>> The reason why the email has been separated is to include the authors of draft-ietf-csi-send-cert in the discussion of this part of the text, since I think some of the issues raised by Sandra affect this document. >>>> >>>> I include my comments inline. >>>> >>>> | -----Mensaje original----- >>>> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>>> | Enviado el: viernes, 02 de julio de 2010 2:31 >>>> | Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org >>>> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 >>>> | >>>> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. >>>> | >>>> | 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 provides new Neighbor Discovery options that will secure >>>> | proxied Neighbor Discovery messages. It is an update to: >>>> | >>>> | RFC4861: Neighbor Discovery in IPv6 >>>> | RFC4389: Neighbor Discovery Proxies (ND Proxy) >>>> | RFC3971: Send Neighbor Discovery (SEND) >>>> | >>>> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. >>>> | >>>> | The need for new mechanisms for security for proxied messages is explained >>>> | in draft-ietf-csi-sndp-prob-04.txt. >>>> | >>>> | I've read all of these, but it is pretty new to me, so I could have missed >>>> | something. >>>> | >>>> | The Neighbor Discovery protocol communicates link-level addresses in the >>>> | protocol messages. The ND Proxy extension would make changes to those >>>> | fields. SEND, which secures the base ND protocol, relies on the sender of >>>> | a message computing a signature associated with the source IP address of >>>> | the message. Any ND Proxy changes to messages would invalidate the >>>> | signature and the ND Proxy itself could not generate a new signature >>>> | (since it would not have the private key associated with the source IP >>>> | address). This draft introduces a Proxy Signature (PS) option to secure >>>> | the proxied messages. >>>> | >>>> | RFC3971, the base SEND spec, defines a new Router Authorization >>>> | Certificate profile, dependent on RFC3779, which authorizes the router to >>>> | act as a router and act for certain prefixes. Message authorization in >>>> | SEND of some ND messages checks the prefixes listed in the certificate >>>> | against the prefixes mentioned in those messages. There is no explicit >>>> | representation in the certificate of the authority to act as a router. >>>> | Possession of the certificate in SEND serves as implicit authorization to >>>> | act as a router, as that was the only authorization defined. >>>> | >>>> | With the introduction of proxies, there was a need to distinguish the >>>> | various roles that a node might have in the network. No longer is >>>> | possession of a certificate adequate authorization. The draft >>>> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to distinguish >>>> | three different roles: router, proxy and owner. That draft notes that >>>> | multiple key purposes are possible. I believe that it is also possible to >>>> | have single roles – so a node could be a proxy but not a router. >>>> >>>> Yes, of course single roles are supported. >>>> >>>> | With the extensions of the csi-send-cert draft, possession of a >>>> | certificate is no longer proof of any particular authorization. It seem >>>> | clear to me that the authorization validation described in RFC3971 is no >>>> | longer sufficient. I believe that a discussion is needed of what messages >>>> | require or allow each particular key purpose authorization. Issuing an >>>> | RA, for example, seems likely to require the "router" value of the key >>>> | purpose field, if the new certificate format was used for authorization. >>>> | Issuing an NA may require the "owner" value of the key purpose field, if >>>> | the new certificate format was used for authorization rather than a CGA. >>>> | I do not know if that discussion would be more appropriate here or in the >>>> | csi-send-cert draft, or another draft entirely that updates RFC3971 >>>> | directly. >>>> | >>>> | If a SPND proxy was using SEND to communicate with other nodes that >>>> | understood SPND, would it be OK to use a new format cert (with the >>>> | "router" KeyPurposeId) as a router certificate for the SEND RSA Signature >>>> | Options? >>>> | >>>> I see. I agree that this needs more precision. >>>> >>>> In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in cert-04) it discusses the messages that are authorized by each KeyPurposeId >>>> - "router authorization value indicates that the >>>> certificate has been issued for allowing the router to advertise >>>> prefix(es)" >>>> (I understand that implicitly states that it authorizes the generation of RA messages. It is not crystal clear for me if it authorizes NA for routers, although if I had to take this text literally, I would suppose routers would need an 'owner' authorization if this PKI model substitutes RFC3971 CGA authorization, considering that the prefix for NA would be narrowed in general to one address, while the RA authorization is prefix-wide) >>>> - "proxy authorization value indicates that the >>>> certificate has been issued for allowing the proxy to perform >>>> proxying of neighbor discovery messages for the prefix(es) that are >>>> mentioned using the X.509 extensions for IP addresses" >>>> (I understand it now implicitly states it authorizes for ANY neighbor discovery message. By the way, this is the assumption underlying in general draft-ietf-csi-proxy-send-04: in the application scenarios, some require RA proxying, which is assumed to be performed by means of the proxy cert) >>>> - "owner authorization [...]For an >>>> address in such certificate the host can assign the address, send/ >>>> receive traffic from this address, and can respond to NSes about that >>>> address" >>>> (this is the clearest of all statements - although I think issuing secured NS and RS should also be considered) >>>> >>>> So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates provide authorization for securing *any* ND message. Considering the application scenarios, some require proxying RA (PMIPv6 and RFC4389), and the MIPv6 scenario just require NS/NA proxying. >>>> >>>> In summary so far, there is some specification of the authorization in draft-csi-send-cert, which I think it would be nice that it could be refined, and if so, my opinion is that the refinement of which ND message is authorized by each KeyPurposeId should be in that document. >>>> However, continuing with this issue, I must say that the way the 'proxy authorization' is defined, and the relationship with the other cases, is not satisfactory for me. >>>> I think the use of 'owner' should be restricted for hosts that really own the address (therefore, a substitution of the CGA mechanism) - as opposed to proxies. >>>> For the 'proxy authorization', I think it could be refined into something like “proxy host” authorization, and “proxy router” authorization. >>>> ‘Proxy host’ would authorize for proxying NA, NS and RS, and “proxy router” authorization would authorize RA and Redirect. This would provide a finer grain which I think would be desirable (for example, MIPv6 does not need protecting neither RA nor redirect). >>>> I think this would work (if so, it should be changed in draft-csi-send-cert). >>>> >>>> What do you think? (both authors of draft-csi-send-cert, Sandra, etc.). >>>> >>>> Regards, >>>> Alberto >>>> >>>> From alexander.zimmermann@comsys.rwth-aachen.de Tue Sep 14 06:31:52 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F173A6909; Tue, 14 Sep 2010 06:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqs6fokIaORc; Tue, 14 Sep 2010 06:31:49 -0700 (PDT) Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by core3.amsl.com (Postfix) with ESMTP id 655013A6993; Tue, 14 Sep 2010 06:31:43 -0700 (PDT) MIME-version: 1.0 Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0L8Q004T3O9KH890@mta-1.ms.rz.RWTH-Aachen.de>; Tue, 14 Sep 2010 15:32:08 +0200 (CEST) X-IronPort-AV: E=Sophos;i="4.56,365,1280700000"; d="sig'?scan'208";a="72422068" Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Tue, 14 Sep 2010 15:32:08 +0200 Received: from [137.226.12.58] ([unknown] [137.226.12.58]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0L8Q001H2O9KP930@relay-auth-2.ms.rz.rwth-aachen.de>; Tue, 14 Sep 2010 15:32:08 +0200 (CEST) From: Alexander Zimmermann Content-type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary=Apple-Mail-22--926231563 Content-transfer-encoding: 7bit Date: Tue, 14 Sep 2010 15:32:09 +0200 Message-id: To: Lars Eggert , Adrian Farrel , Juergen Quittek , Enrico Marocco , Catherine Meadows X-Pgp-Agent: GPGMail 1.2.3 X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Tue, 14 Sep 2010 08:01:47 -0700 Cc: draft-ietf-tcpm-tcp-lcd.all@tools.ietf.org, ops-dir@ietf.org, secdir@ietf.org, General Area Review Team , iesg@ietf.org Subject: [secdir] Reviews for draft-ietf-tcpm-tcp-lcd-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 13:31:52 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-22--926231563 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, thanks again for reviewing the draft. We incorporated the feedback from * Juergen Quittek: - Integrate ICMPv6 discussion directly in Section 3. Section 7.3 = is deleted. * Catherine Meadows: - Clarified security section. Section 10 - Clarified why not a higher probing frequency is used. Section = 5.4 * Adrian Farrel: - Clarified the experimental status of the document (last = paragraph in section 2) * Enrico Marocco: nits -- New version (-03) has been submitted for draft-ietf-tcpm-tcp-lcd-03.txt. http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-lcd-03.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tcpm-tcp-lcd-03 -- // // Dipl.-Inform. Alexander Zimmermann // Department of Computer Science, Informatik 4 // RWTH Aachen University // Ahornstr. 55, 52056 Aachen, Germany // phone: (49-241) 80-21422, fax: (49-241) 80-22222 // email: zimmermann@cs.rwth-aachen.de // web: http://www.umic-mesh.net // --Apple-Mail-22--926231563 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: Signierter Teil der Nachricht content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) iEYEARECAAYFAkyPeVoACgkQdyiq39b9uS48lACghcDbLwOEDExG3UIaB1k6uSbl c1cAnA1xJpV+IsRierGw6uuH/ht+UDo/ =w4+y -----END PGP SIGNATURE----- --Apple-Mail-22--926231563-- From turners@ieca.com Tue Sep 14 08:12:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 532893A6AAA for ; Tue, 14 Sep 2010 08:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e8uegWMhmELs for ; Tue, 14 Sep 2010 08:11:58 -0700 (PDT) Received: from smtp111.biz.mail.re2.yahoo.com (smtp111.biz.mail.re2.yahoo.com [66.196.116.96]) by core3.amsl.com (Postfix) with SMTP id 1701A3A6ACC for ; Tue, 14 Sep 2010 08:11:58 -0700 (PDT) Received: (qmail 73403 invoked from network); 14 Sep 2010 15:12:22 -0000 Received: from thunderfish.local (turners@96.231.127.24 with plain) by smtp111.biz.mail.re2.yahoo.com with SMTP; 14 Sep 2010 08:12:21 -0700 PDT X-Yahoo-SMTP: ZrP3VLSswBDL75pF8ymZHDSu9B.vcMfDPgLJ X-YMail-OSG: gpWYhgYVM1k6imj6e_rmcRlDB1PmbI61qRYI02cXY.39Q4d 1juA.bwshICixXXbKXeRmPHmdt5iODTOivAdrkrYenlmB5wXKSYs6US6nEiC RJMVhgGVSXYg.0w3C25DGvjDLY5t4fc4qX6Gvi6mWMzQOdwVsAHyA0qWpUzd Aap2323t9qlU2.ReAfpf3U5TlvLuhyS3wnjsx.ipwD5XaYAF2XHDs8lstPYh eEQ4cn_h.j0utRrUNiINNZSqHmmbeZhMNaQNbSpBzUUvQueFaQeky8vhde66 FudoCic4_1YjIG2qnrChYecAImWMvyYXV1Pi9QhF_tx2RgsYAcNrrZTrpIx7 VnpJGjC_g0s9hOL3CF3Bie.fg9Krw9BJfT5CP_Iih355J4m6Du7aBqQ1cYJZ 6hto5HLHJ_uITzwpg3vJc8Wj3JZWDd_bYhibhv18rvWf6.S6CZ00JaLCE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8F90D4.3040301@ieca.com> Date: Tue, 14 Sep 2010 11:12:20 -0400 From: Sean Turner User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: marcelo bagnulo braun References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> <4C8E41F6.906@it.uc3m.es> In-Reply-To: <4C8E41F6.906@it.uc3m.es> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Roque Gagliano , draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, "Alberto "@core3.amsl.com, Sandra Murphy , =?windows-1252?Q?Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, Ralph Droms , csi-chairs@tools.ietf.org, IESG IESG Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 15:12:02 -0000 marcelo bagnulo braun wrote: > > > El 13/09/10 16:29, Roque Gagliano escribió: >> Hi Ralph, >> >> I can answer for the draft-ietf-csi-send-cert document. The new >> revision addressed all the DISCUSS positions for that document. >> >> As I mentioned in a previous email, we came back to the WG to ask one >> change that is been requested by one of the authors of the >> draft-ietf-csi-proxy-send document. The change consist of adding a new >> EKU. >> >> I think is best to wait for the WG opinion on this issue because if >> this additional EKU is needed, it makes sense to have it in this same >> document. >> > Right, the problem is that the WG is slient, so we probably need to > solve this in some other way i.e. propose something to the WG and see if > anybody objects. > > The new EKU is the proposed way to deal with one comment from Sandy's > review of the proxy send document. It seems we could live without, but > it would be a somehow inferior solution. I would suggest that unless > getting a new EKU is a lot of work, we go ahead with that. Getting an EKU is pretty easy. Ask Russ Housley (cced) for one. He controls assigning the OID out of the PKIX arc. Obvioulsy, you'll need to add some text in the document to explain its use. spt > would that make sense? > > Regards, marcelo > > >> Regards, >> Roque. >> >> ---------------------------------------------------------------------------------------------------------------------------------------------- >> >> Roque >> Gagliano >> Cisco Systems International Sàrl >> Software Engineer Mailstop >> ROL01/2/ >> Corporate Development Technology Group Avenue des >> Uttins 5 >> 1180 Rolle >> rogaglia@cisco.com Switzerland >> Phone: +41 21 823 2805 >> >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote: >> >>> Can you clarify the status of draft-ietf-csi-send-cert and >>> draft-ietf-csi-proxy-send? Does the new rev of >>> draft-ietf-csi-send-cert address the DISCUSS positions on both docs? >>> >>> - Ralph >>> >>> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: >>> >>>> Hi Sandra, >>>> >>>> I issued a new version of the draft draft-ietf-csi-send-cert documents. >>>> >>>> I believe the new version addresses all the concerns expressed in >>>> this mail exchange. >>>> >>>> Regards, >>>> >>>> Roque >>>> >>>> >>>> >>>> >>>> On Jul 6, 2010, at 5:32 PM, Alberto García wrote: >>>> >>>>> Hi, >>>>> The text of this email has been extracted from a thorough review of >>>>> draft-ietf-csi-proxy-send being made by Sandra Murphy. >>>>> The reason why the email has been separated is to include the >>>>> authors of draft-ietf-csi-send-cert in the discussion of this part >>>>> of the text, since I think some of the issues raised by Sandra >>>>> affect this document. >>>>> >>>>> I include my comments inline. >>>>> >>>>> | -----Mensaje original----- >>>>> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>>>> | Enviado el: viernes, 02 de julio de 2010 2:31 >>>>> | Para: iesg@ietf.org; secdir@ietf.org; >>>>> draft-ietf-csi-proxy-send.all@tools.ietf.org >>>>> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 >>>>> | >>>>> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. >>>>> | >>>>> | 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 provides new Neighbor Discovery options that will >>>>> secure >>>>> | proxied Neighbor Discovery messages. It is an update to: >>>>> | >>>>> | RFC4861: Neighbor Discovery in IPv6 >>>>> | RFC4389: Neighbor Discovery Proxies (ND Proxy) >>>>> | RFC3971: Send Neighbor Discovery (SEND) >>>>> | >>>>> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. >>>>> | >>>>> | The need for new mechanisms for security for proxied messages is >>>>> explained >>>>> | in draft-ietf-csi-sndp-prob-04.txt. >>>>> | >>>>> | I've read all of these, but it is pretty new to me, so I could >>>>> have missed >>>>> | something. >>>>> | >>>>> | The Neighbor Discovery protocol communicates link-level >>>>> addresses in the >>>>> | protocol messages. The ND Proxy extension would make changes to >>>>> those >>>>> | fields. SEND, which secures the base ND protocol, relies on the >>>>> sender of >>>>> | a message computing a signature associated with the source IP >>>>> address of >>>>> | the message. Any ND Proxy changes to messages would invalidate the >>>>> | signature and the ND Proxy itself could not generate a new >>>>> signature >>>>> | (since it would not have the private key associated with the >>>>> source IP >>>>> | address). This draft introduces a Proxy Signature (PS) option >>>>> to secure >>>>> | the proxied messages. >>>>> | >>>>> | RFC3971, the base SEND spec, defines a new Router Authorization >>>>> | Certificate profile, dependent on RFC3779, which authorizes the >>>>> router to >>>>> | act as a router and act for certain prefixes. Message >>>>> authorization in >>>>> | SEND of some ND messages checks the prefixes listed in the >>>>> certificate >>>>> | against the prefixes mentioned in those messages. There is no >>>>> explicit >>>>> | representation in the certificate of the authority to act as a >>>>> router. >>>>> | Possession of the certificate in SEND serves as implicit >>>>> authorization to >>>>> | act as a router, as that was the only authorization defined. >>>>> | >>>>> | With the introduction of proxies, there was a need to >>>>> distinguish the >>>>> | various roles that a node might have in the network. No longer is >>>>> | possession of a certificate adequate authorization. The draft >>>>> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to >>>>> distinguish >>>>> | three different roles: router, proxy and owner. That draft >>>>> notes that >>>>> | multiple key purposes are possible. I believe that it is also >>>>> possible to >>>>> | have single roles – so a node could be a proxy but not a router. >>>>> >>>>> Yes, of course single roles are supported. >>>>> >>>>> | With the extensions of the csi-send-cert draft, possession of a >>>>> | certificate is no longer proof of any particular authorization. >>>>> It seem >>>>> | clear to me that the authorization validation described in >>>>> RFC3971 is no >>>>> | longer sufficient. I believe that a discussion is needed of >>>>> what messages >>>>> | require or allow each particular key purpose authorization. >>>>> Issuing an >>>>> | RA, for example, seems likely to require the "router" value of >>>>> the key >>>>> | purpose field, if the new certificate format was used for >>>>> authorization. >>>>> | Issuing an NA may require the "owner" value of the key purpose >>>>> field, if >>>>> | the new certificate format was used for authorization rather >>>>> than a CGA. >>>>> | I do not know if that discussion would be more appropriate here >>>>> or in the >>>>> | csi-send-cert draft, or another draft entirely that updates RFC3971 >>>>> | directly. >>>>> | >>>>> | If a SPND proxy was using SEND to communicate with other nodes that >>>>> | understood SPND, would it be OK to use a new format cert (with the >>>>> | "router" KeyPurposeId) as a router certificate for the SEND RSA >>>>> Signature >>>>> | Options? >>>>> | >>>>> I see. I agree that this needs more precision. >>>>> >>>>> In draft-ietf-csi-send-cert-05, section 7 (it is the same text as >>>>> in cert-04) it discusses the messages that are authorized by each >>>>> KeyPurposeId >>>>> - "router authorization value indicates that the >>>>> certificate has been issued for allowing the router to advertise >>>>> prefix(es)" >>>>> (I understand that implicitly states that it authorizes the >>>>> generation of RA messages. It is not crystal clear for me if it >>>>> authorizes NA for routers, although if I had to take this text >>>>> literally, I would suppose routers would need an 'owner' >>>>> authorization if this PKI model substitutes RFC3971 CGA >>>>> authorization, considering that the prefix for NA would be narrowed >>>>> in general to one address, while the RA authorization is prefix-wide) >>>>> - "proxy authorization value indicates that the >>>>> certificate has been issued for allowing the proxy to perform >>>>> proxying of neighbor discovery messages for the prefix(es) that are >>>>> mentioned using the X.509 extensions for IP addresses" >>>>> (I understand it now implicitly states it authorizes for ANY >>>>> neighbor discovery message. By the way, this is the assumption >>>>> underlying in general draft-ietf-csi-proxy-send-04: in the >>>>> application scenarios, some require RA proxying, which is assumed >>>>> to be performed by means of the proxy cert) >>>>> - "owner authorization [...]For an >>>>> address in such certificate the host can assign the address, send/ >>>>> receive traffic from this address, and can respond to NSes about >>>>> that >>>>> address" >>>>> (this is the clearest of all statements - although I think issuing >>>>> secured NS and RS should also be considered) >>>>> >>>>> So, as defined now in draft-ietf-csi-proxy-send-04, proxy >>>>> certificates provide authorization for securing *any* ND message. >>>>> Considering the application scenarios, some require proxying RA >>>>> (PMIPv6 and RFC4389), and the MIPv6 scenario just require NS/NA >>>>> proxying. >>>>> >>>>> In summary so far, there is some specification of the authorization >>>>> in draft-csi-send-cert, which I think it would be nice that it >>>>> could be refined, and if so, my opinion is that the refinement of >>>>> which ND message is authorized by each KeyPurposeId should be in >>>>> that document. >>>>> However, continuing with this issue, I must say that the way the >>>>> 'proxy authorization' is defined, and the relationship with the >>>>> other cases, is not satisfactory for me. >>>>> I think the use of 'owner' should be restricted for hosts that >>>>> really own the address (therefore, a substitution of the CGA >>>>> mechanism) - as opposed to proxies. >>>>> For the 'proxy authorization', I think it could be refined into >>>>> something like “proxy host” authorization, and “proxy router” >>>>> authorization. >>>>> ‘Proxy host’ would authorize for proxying NA, NS and RS, and “proxy >>>>> router” authorization would authorize RA and Redirect. This would >>>>> provide a finer grain which I think would be desirable (for >>>>> example, MIPv6 does not need protecting neither RA nor redirect). >>>>> I think this would work (if so, it should be changed in >>>>> draft-csi-send-cert). >>>>> >>>>> What do you think? (both authors of draft-csi-send-cert, Sandra, >>>>> etc.). >>>>> >>>>> Regards, >>>>> Alberto >>>>> >>>>> > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > From wintert@acm.org Tue Sep 14 08:57:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE18D3A6991 for ; Tue, 14 Sep 2010 08:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.955 X-Spam-Level: X-Spam-Status: No, score=-101.955 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj-KyrNqtq5R for ; Tue, 14 Sep 2010 08:57:11 -0700 (PDT) Received: from smtp107.prem.mail.ac4.yahoo.com (smtp107.prem.mail.ac4.yahoo.com [76.13.13.46]) by core3.amsl.com (Postfix) with SMTP id 421B13A681D for ; Tue, 14 Sep 2010 08:57:11 -0700 (PDT) Received: (qmail 29951 invoked from network); 14 Sep 2010 15:57:33 -0000 Received: from [10.56.17.103] (wintert@71.178.253.216 with plain) by smtp107.prem.mail.ac4.yahoo.com with SMTP; 14 Sep 2010 08:57:33 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: xLiJHCAVM1mCurJoPcO2SdUZnIgN_yy_m4f6qSGjrqu_Qjl m_cNBVoqeqs1QMUtl4TN7YTwbSVg2UnrfRMLkSdzROPZZy51yjBBvG0QFNCi fgeHfOZSMXF7RY4q22O5VMUIHzlv8iVZilebMjv1JvN77LrC0032w37bc2pE xYYYNhueXSO_XQDHpT4f5TBjEUX19gbCp2KvxGj6eKnWV3Aags5ctlYYlIXs DbqaMxU8TCk88rdu7L0hvlf6TD10EXhTt6wwOa.XguY0cYrpQ1YoNebDux8M ryt2Lmg4K4PgwyDa5Z0IAYRh4SWs- X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C8F9B6A.1080708@acm.org> Date: Tue, 14 Sep 2010 11:57:30 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.12) Gecko/20100826 Thunderbird/3.0.7 MIME-Version: 1.0 To: Tina TSOU References: <44BCD8D277C6479097DB80AF063B4325@china.huawei.com> In-Reply-To: <44BCD8D277C6479097DB80AF063B4325@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 14 Sep 2010 09:05:02 -0700 Cc: secdir-secretary@mit.edu, iesg@ietf.org, draft-ietf-roll-rpl@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-rpl-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 15:57:13 -0000 Hi Tina, On 08/31/2010 11:22 PM, Tina TSOU 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. Thank you for your review. > > This draft is well written. I only have two comments. > > 1. It is lack of manageability aspects to produce MIB; As far as the MIB in general, we did not define a MIB but instead did describe some general manageability aspects in Section 17. We chose to defer to the CoRE working group and other future work to specify the details, as introduced in Section 17.1: Most of the existing IETF management standards are Structure of Management Information (SMI) based data models (MIB modules) to monitor and manage networking devices. For a number of protocols, the IETF community has used the IETF Standard Management Framework, including the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols. As pointed out in [RFC5706], the common policy in terms of operation and management has been expanded to a policy that is more open to a set of tools and management protocols rather than strictly relying on a single protocol such as SNMP. In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535] that discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration. One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410]. In the case of LLNs, it must be noted that at the time of writing, the CoRE Working Group is actively working on resource management of devices in LLNs. Still, it is felt that this section provides important guidance on how RPL should be deployed, operated, and managed. More specifically, we propose to add some text to call out aspects of security manageability. > 2. Should be added flow examples for RPL; We can come up with a few illustrative examples and add those to the draft. > > > > B. R. Tina http://tinatsou.weebly.com/index.html > > Does this address your concerns? Regards, -RPL Authors From Sandra.Murphy@cobham.com Tue Sep 14 10:35:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D75D3A69EB; Tue, 14 Sep 2010 10:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byzsUeo3H0rm; Tue, 14 Sep 2010 10:35:54 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 8888A3A69C8; Tue, 14 Sep 2010 10:35:54 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o8EHaEK0026653; Tue, 14 Sep 2010 12:36:14 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o8EHaDgN025475; Tue, 14 Sep 2010 12:36:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB5432.FC12282A" Date: Tue, 14 Sep 2010 13:33:46 -0400 Message-ID: <5ABE30CE099A524CBF95C715D37BCACC3D015B@nemo.columbia.ads.sparta.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [secdir] secdir review of draft-ietf-csi-proxy-send-04 Thread-Index: ActUHz3htVDFZX13TVyPZZq6jCQoWQAEt9Tp References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> <4C8E41F6.906@it.uc3m.es> <4C8F90D4.3040301@ieca.com> From: "Murphy, Sandra" To: "Sean Turner" , "marcelo bagnulo braun" X-Mailman-Approved-At: Tue, 14 Sep 2010 10:41:32 -0700 Cc: Roque Gagliano , draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, "Alberto "@core3.amsl.com, =?iso-8859-1?Q?Garc=EDa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, Ralph Droms , csi-chairs@tools.ietf.org, IESG IESG Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 17:35:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB5432.FC12282A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hopefully readable. As it is sent from a smartphone. Roque and I have communicated about timing of my rereview. He says I = might as well wait for the wg to decide. I am interested, iirc, in what = actions or messages require what certs Sandy -----Original Message---. Looking forward to (having time to) reviewing = the new draft. -- From: Sean Turner [mailto:turners@ieca.com] Sent: Tue 9/14/2010 11:12 AM To: marcelo bagnulo braun Cc: Roque Gagliano; draft-ietf-csi-send-cert@tools.ietf.org; = secdir@ietf.org; Murphy, Sandra; Garc=EDa; = draft-ietf-csi-proxy-send.all@tools.ietf.org; "Alberto "@core3.amsl.com; = Ralph Droms; csi-chairs@tools.ietf.org; IESG IESG; Russ Housley Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 =20 marcelo bagnulo braun wrote: >=20 >=20 > El 13/09/10 16:29, Roque Gagliano escribi=F3: >> Hi Ralph, >> >> I can answer for the draft-ietf-csi-send-cert document. The new=20 >> revision addressed all the DISCUSS positions for that document. >> >> As I mentioned in a previous email, we came back to the WG to ask one = >> change that is been requested by one of the authors of the=20 >> draft-ietf-csi-proxy-send document. The change consist of adding a = new=20 >> EKU. >> >> I think is best to wait for the WG opinion on this issue because if=20 >> this additional EKU is needed, it makes sense to have it in this same = >> document. >> > Right, the problem is that the WG is slient, so we probably need to=20 > solve this in some other way i.e. propose something to the WG and see = if=20 > anybody objects. >=20 > The new EKU is the proposed way to deal with one comment from Sandy's=20 > review of the proxy send document. It seems we could live without, but = > it would be a somehow inferior solution. I would suggest that unless=20 > getting a new EKU is a lot of work, we go ahead with that. Getting an EKU is pretty easy. Ask Russ Housley=20 (cced) for one. He controls assigning the OID=20 out of the PKIX arc. Obvioulsy, you'll need to add some text in the=20 document to explain its use. spt > would that make sense? >=20 > Regards, marcelo >=20 >=20 >> Regards, >> Roque. >> >> = -------------------------------------------------------------------------= ---------------------------------------------------------------------=20 >> >> Roque=20 >> Gagliano = =20 >> Cisco Systems International S=E0rl =20 >> Software Engineer Mailstop=20 >> ROL01/2/ >> Corporate Development Technology Group Avenue des = >> Uttins 5 >> 1180 Rolle >> rogaglia@cisco.com Switzerland >> Phone: +41 21 823 2805 =20 >> >> For corporate legal information go to:=20 >> http://www.cisco.com/web/about/doing_business/legal/cri/index.html >> >> On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote: >> >>> Can you clarify the status of draft-ietf-csi-send-cert and=20 >>> draft-ietf-csi-proxy-send? Does the new rev of=20 >>> draft-ietf-csi-send-cert address the DISCUSS positions on both docs? >>> >>> - Ralph >>> >>> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano wrote: >>> >>>> Hi Sandra, >>>> >>>> I issued a new version of the draft draft-ietf-csi-send-cert = documents. >>>> >>>> I believe the new version addresses all the concerns expressed in=20 >>>> this mail exchange. >>>> >>>> Regards, >>>> >>>> Roque >>>> >>>> >>>> >>>> >>>> On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote: >>>> >>>>> Hi, >>>>> The text of this email has been extracted from a thorough review = of=20 >>>>> draft-ietf-csi-proxy-send being made by Sandra Murphy. >>>>> The reason why the email has been separated is to include the=20 >>>>> authors of draft-ietf-csi-send-cert in the discussion of this part = >>>>> of the text, since I think some of the issues raised by Sandra=20 >>>>> affect this document. >>>>> >>>>> I include my comments inline. >>>>> >>>>> | -----Mensaje original----- >>>>> | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] >>>>> | Enviado el: viernes, 02 de julio de 2010 2:31 >>>>> | Para: iesg@ietf.org; secdir@ietf.org;=20 >>>>> draft-ietf-csi-proxy-send.all@tools.ietf.org >>>>> | Asunto: secdir review of draft-ietf-csi-proxy-send-04 >>>>> | >>>>> | This is a review of draft draft-ietf-csi-proxy-send-04.txt. >>>>> | >>>>> | I have reviewed this document as part of the security = directorate's >>>>> | ongoing effort to review all IETF documents being processed by=20 >>>>> the IESG. >>>>> | These comments were written primarily for the benefit of the=20 >>>>> security area >>>>> | directors. Document editors and WG chairs should treat these=20 >>>>> comments just >>>>> | like any other last call comments. >>>>> | >>>>> | This document provides new Neighbor Discovery options that will = >>>>> secure >>>>> | proxied Neighbor Discovery messages. It is an update to: >>>>> | >>>>> | RFC4861: Neighbor Discovery in IPv6 >>>>> | RFC4389: Neighbor Discovery Proxies (ND Proxy) >>>>> | RFC3971: Send Neighbor Discovery (SEND) >>>>> | >>>>> | This draft relies on draft draft-ietf-csi-send-cert-04.txt. >>>>> | >>>>> | The need for new mechanisms for security for proxied messages = is=20 >>>>> explained >>>>> | in draft-ietf-csi-sndp-prob-04.txt. >>>>> | >>>>> | I've read all of these, but it is pretty new to me, so I could=20 >>>>> have missed >>>>> | something. >>>>> | >>>>> | The Neighbor Discovery protocol communicates link-level=20 >>>>> addresses in the >>>>> | protocol messages. The ND Proxy extension would make changes = to=20 >>>>> those >>>>> | fields. SEND, which secures the base ND protocol, relies on = the=20 >>>>> sender of >>>>> | a message computing a signature associated with the source IP=20 >>>>> address of >>>>> | the message. Any ND Proxy changes to messages would invalidate = the >>>>> | signature and the ND Proxy itself could not generate a new=20 >>>>> signature >>>>> | (since it would not have the private key associated with the=20 >>>>> source IP >>>>> | address). This draft introduces a Proxy Signature (PS) option=20 >>>>> to secure >>>>> | the proxied messages. >>>>> | >>>>> | RFC3971, the base SEND spec, defines a new Router Authorization >>>>> | Certificate profile, dependent on RFC3779, which authorizes the = >>>>> router to >>>>> | act as a router and act for certain prefixes. Message=20 >>>>> authorization in >>>>> | SEND of some ND messages checks the prefixes listed in the=20 >>>>> certificate >>>>> | against the prefixes mentioned in those messages. There is no=20 >>>>> explicit >>>>> | representation in the certificate of the authority to act as a=20 >>>>> router. >>>>> | Possession of the certificate in SEND serves as implicit=20 >>>>> authorization to >>>>> | act as a router, as that was the only authorization defined. >>>>> | >>>>> | With the introduction of proxies, there was a need to=20 >>>>> distinguish the >>>>> | various roles that a node might have in the network. No longer = is >>>>> | possession of a certificate adequate authorization. The draft >>>>> | draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to=20 >>>>> distinguish >>>>> | three different roles: router, proxy and owner. That draft=20 >>>>> notes that >>>>> | multiple key purposes are possible. I believe that it is also=20 >>>>> possible to >>>>> | have single roles - so a node could be a proxy but not a = router. >>>>> >>>>> Yes, of course single roles are supported. >>>>> >>>>> | With the extensions of the csi-send-cert draft, possession of a >>>>> | certificate is no longer proof of any particular authorization. = =20 >>>>> It seem >>>>> | clear to me that the authorization validation described in=20 >>>>> RFC3971 is no >>>>> | longer sufficient. I believe that a discussion is needed of=20 >>>>> what messages >>>>> | require or allow each particular key purpose authorization. =20 >>>>> Issuing an >>>>> | RA, for example, seems likely to require the "router" value of=20 >>>>> the key >>>>> | purpose field, if the new certificate format was used for=20 >>>>> authorization. >>>>> | Issuing an NA may require the "owner" value of the key purpose=20 >>>>> field, if >>>>> | the new certificate format was used for authorization rather=20 >>>>> than a CGA. >>>>> | I do not know if that discussion would be more appropriate here = >>>>> or in the >>>>> | csi-send-cert draft, or another draft entirely that updates = RFC3971 >>>>> | directly. >>>>> | >>>>> | If a SPND proxy was using SEND to communicate with other nodes = that >>>>> | understood SPND, would it be OK to use a new format cert (with = the >>>>> | "router" KeyPurposeId) as a router certificate for the SEND RSA = >>>>> Signature >>>>> | Options? >>>>> | >>>>> I see. I agree that this needs more precision. >>>>> >>>>> In draft-ietf-csi-send-cert-05, section 7 (it is the same text as=20 >>>>> in cert-04) it discusses the messages that are authorized by each=20 >>>>> KeyPurposeId >>>>> - "router authorization value indicates that the >>>>> certificate has been issued for allowing the router to = advertise >>>>> prefix(es)" >>>>> (I understand that implicitly states that it authorizes the=20 >>>>> generation of RA messages. It is not crystal clear for me if it=20 >>>>> authorizes NA for routers, although if I had to take this text=20 >>>>> literally, I would suppose routers would need an 'owner'=20 >>>>> authorization if this PKI model substitutes RFC3971 CGA=20 >>>>> authorization, considering that the prefix for NA would be = narrowed=20 >>>>> in general to one address, while the RA authorization is = prefix-wide) >>>>> - "proxy authorization value indicates that the >>>>> certificate has been issued for allowing the proxy to perform >>>>> proxying of neighbor discovery messages for the prefix(es) that = are >>>>> mentioned using the X.509 extensions for IP addresses" >>>>> (I understand it now implicitly states it authorizes for ANY=20 >>>>> neighbor discovery message. By the way, this is the assumption=20 >>>>> underlying in general draft-ietf-csi-proxy-send-04: in the=20 >>>>> application scenarios, some require RA proxying, which is assumed=20 >>>>> to be performed by means of the proxy cert) >>>>> - "owner authorization [...]For an >>>>> address in such certificate the host can assign the address, = send/ >>>>> receive traffic from this address, and can respond to NSes = about=20 >>>>> that >>>>> address" >>>>> (this is the clearest of all statements - although I think issuing = >>>>> secured NS and RS should also be considered) >>>>> >>>>> So, as defined now in draft-ietf-csi-proxy-send-04, proxy=20 >>>>> certificates provide authorization for securing *any* ND message.=20 >>>>> Considering the application scenarios, some require proxying RA=20 >>>>> (PMIPv6 and RFC4389), and the MIPv6 scenario just require NS/NA=20 >>>>> proxying. >>>>> >>>>> In summary so far, there is some specification of the = authorization=20 >>>>> in draft-csi-send-cert, which I think it would be nice that it=20 >>>>> could be refined, and if so, my opinion is that the refinement of=20 >>>>> which ND message is authorized by each KeyPurposeId should be in=20 >>>>> that document. >>>>> However, continuing with this issue, I must say that the way the=20 >>>>> 'proxy authorization' is defined, and the relationship with the=20 >>>>> other cases, is not satisfactory for me. >>>>> I think the use of 'owner' should be restricted for hosts that=20 >>>>> really own the address (therefore, a substitution of the CGA=20 >>>>> mechanism) - as opposed to proxies. >>>>> For the 'proxy authorization', I think it could be refined into=20 >>>>> something like "proxy host" authorization, and "proxy router"=20 >>>>> authorization. >>>>> 'Proxy host' would authorize for proxying NA, NS and RS, and = "proxy=20 >>>>> router" authorization would authorize RA and Redirect. This would=20 >>>>> provide a finer grain which I think would be desirable (for=20 >>>>> example, MIPv6 does not need protecting neither RA nor redirect). >>>>> I think this would work (if so, it should be changed in=20 >>>>> draft-csi-send-cert). >>>>> >>>>> What do you think? (both authors of draft-csi-send-cert, Sandra,=20 >>>>> etc.). >>>>> >>>>> Regards, >>>>> Alberto >>>>> >>>>> >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir >=20 ------_=_NextPart_001_01CB5432.FC12282A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [secdir] secdir review of = draft-ietf-csi-proxy-send-04

Hopefully readable. As it is sent from a = smartphone.

Roque and I have communicated about timing of my rereview.  He says = I might as well wait for the wg to decide.  I am interested, iirc, = in what actions or messages require what certs


Sandy

-----Original Message---.  Looking forward to (having time to) = reviewing the new draft.

--
From: Sean Turner [mailto:turners@ieca.com]
Sent: Tue 9/14/2010 11:12 AM
To: marcelo bagnulo braun
Cc: Roque Gagliano; draft-ietf-csi-send-cert@tools.ietf.org; = secdir@ietf.org; Murphy, Sandra; Garc=EDa; = draft-ietf-csi-proxy-send.all@tools.ietf.org; "Alberto = "@core3.amsl.com; Ralph Droms; csi-chairs@tools.ietf.org; IESG = IESG; Russ Housley
Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04

marcelo bagnulo braun wrote:
>
>
> El 13/09/10 16:29, Roque Gagliano escribi=F3:
>> Hi Ralph,
>>
>> I can answer for the draft-ietf-csi-send-cert document. The = new
>> revision addressed all the DISCUSS positions for that = document.
>>
>> As I mentioned in a previous email, we came back to the WG to = ask one
>> change that is been requested by one of the authors of the
>> draft-ietf-csi-proxy-send document. The change consist of = adding a new
>> EKU.
>>
>> I think is best to wait for the WG opinion on this issue = because if
>> this additional EKU is needed, it makes sense to have it in = this same
>> document.
>>
> Right, the problem is that the WG is slient, so we probably need = to
> solve this in some other way i.e. propose something to the WG and = see if
> anybody objects.
>
> The new EKU is the proposed way to deal with one comment from = Sandy's
> review of the proxy send document. It seems we could live without, = but
> it would be a somehow inferior solution. I would suggest that = unless
> getting a new EKU is a lot of work, we go ahead with that.

Getting an EKU is pretty easy.  Ask Russ Housley
<housley@vigilsec.com> (cced) for one.  He controls assigning = the OID
out of the PKIX arc.  Obvioulsy, you'll need to add some text in = the
document to explain its use.

spt

> would that make sense?
>
> Regards, marcelo
>
>
>> Regards,
>> Roque.
>>
>> = -------------------------------------------------------------------------= ---------------------------------------------------------------------
= >>
>> Roque
>> = Gagliano           = ;            =             &= nbsp;           &n= bsp;           &nb= sp;  
>> Cisco Systems International S=E0rl  
>> Software = Engineer           = ;            =             &= nbsp;    Mailstop
>> ROL01/2/
>> Corporate Development  Technology = Group           &n= bsp;        Avenue des
>> Uttins 5
>>           = ;            =             &= nbsp;           &n= bsp;         1180 Rolle
>> = rogaglia@cisco.com         &= nbsp;           &n= bsp;           &nb= sp;      Switzerland
>> Phone: +41 21 823 = 2805           &nb= sp;           &nbs= p;          
>>
>> For corporate legal information go to:
>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html=
>>
>> On Sep 13, 2010, at 4:21 PM, Ralph Droms wrote:
>>
>>> Can you clarify the status of draft-ietf-csi-send-cert = and
>>> draft-ietf-csi-proxy-send?  Does the new rev of
>>> draft-ietf-csi-send-cert address the DISCUSS positions on = both docs?
>>>
>>> - Ralph
>>>
>>> On Sep 1, 2010, at 10:11 PM 9/1/10, Roque Gagliano = wrote:
>>>
>>>> Hi Sandra,
>>>>
>>>> I issued a new version of the draft = draft-ietf-csi-send-cert documents.
>>>>
>>>> I believe the new version addresses all the concerns = expressed in
>>>> this mail exchange.
>>>>
>>>> Regards,
>>>>
>>>> Roque
>>>>
>>>>
>>>>
>>>>
>>>> On Jul 6, 2010, at 5:32 PM, Alberto Garc=EDa wrote:
>>>>
>>>>> Hi,
>>>>> The text of this email has been extracted from a = thorough review of
>>>>> draft-ietf-csi-proxy-send being made by Sandra = Murphy.
>>>>> The reason why the email has been separated is to = include the
>>>>> authors of draft-ietf-csi-send-cert in the = discussion of this part
>>>>> of the text, since I think some of the issues = raised by Sandra
>>>>> affect this document.
>>>>>
>>>>> I include my comments inline.
>>>>>
>>>>> |  -----Mensaje original-----
>>>>> |  De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com<= /A>]
>>>>> |  Enviado el: viernes, 02 de julio de 2010 = 2:31
>>>>> |  Para: iesg@ietf.org; secdir@ietf.org;
>>>>> draft-ietf-csi-proxy-send.all@tools.ietf.org
>>>>> |  Asunto: secdir review of = draft-ietf-csi-proxy-send-04
>>>>> |
>>>>> |  This is a review of draft = draft-ietf-csi-proxy-send-04.txt.
>>>>> |
>>>>> |  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 provides new Neighbor = Discovery options that will
>>>>> secure
>>>>> |  proxied Neighbor Discovery messages.  = It is an update to:
>>>>> |
>>>>> |  RFC4861: Neighbor Discovery in IPv6
>>>>> |  RFC4389: Neighbor Discovery Proxies (ND = Proxy)
>>>>> |  RFC3971: Send Neighbor Discovery (SEND)
>>>>> |
>>>>> |  This draft relies on draft = draft-ietf-csi-send-cert-04.txt.
>>>>> |
>>>>> |  The need for new mechanisms for security = for proxied messages is
>>>>> explained
>>>>> |  in draft-ietf-csi-sndp-prob-04.txt.
>>>>> |
>>>>> |  I've read all of these, but it is pretty = new to me, so I could
>>>>> have missed
>>>>> |  something.
>>>>> |
>>>>> |  The Neighbor Discovery protocol = communicates link-level
>>>>> addresses in the
>>>>> |  protocol messages.  The ND Proxy = extension would make changes to
>>>>> those
>>>>> |  fields.  SEND, which secures the base = ND protocol, relies on the
>>>>> sender of
>>>>> |  a message computing a signature associated = with the source IP
>>>>> address of
>>>>> |  the message.  Any ND Proxy changes to = messages would invalidate the
>>>>> |  signature and the ND Proxy itself could not = generate a new
>>>>> signature
>>>>> |  (since it would not have the private key = associated with the
>>>>> source IP
>>>>> |  address).  This draft introduces a = Proxy Signature (PS) option
>>>>> to secure
>>>>> |  the proxied messages.
>>>>> |
>>>>> |  RFC3971, the base SEND spec, defines a new = Router Authorization
>>>>> |  Certificate profile, dependent on RFC3779, = which authorizes the
>>>>> router to
>>>>> |  act as a router and act for certain = prefixes.  Message
>>>>> authorization in
>>>>> |  SEND of some ND messages checks the = prefixes listed in the
>>>>> certificate
>>>>> |  against the prefixes mentioned in those = messages.  There is no
>>>>> explicit
>>>>> |  representation in the certificate of the = authority to act as a
>>>>> router.
>>>>> |  Possession of the certificate in SEND = serves as implicit
>>>>> authorization to
>>>>> |  act as a router, as that was the only = authorization defined.
>>>>> |
>>>>> |  With the introduction of proxies, there was = a need to
>>>>> distinguish the
>>>>> |  various roles that a node might have in the = network.  No longer is
>>>>> |  possession of a certificate adequate = authorization.  The draft
>>>>> |  draft-ietf-csi-send-cert-04.txt uses the = KeyPurposeId field to
>>>>> distinguish
>>>>> |  three different roles: router, proxy and = owner.  That draft
>>>>> notes that
>>>>> |  multiple key purposes are possible.  I = believe that it is also
>>>>> possible to
>>>>> |  have single roles - so a node could be a = proxy but not a router.
>>>>>
>>>>> Yes, of course single roles are supported.
>>>>>
>>>>> |  With the extensions of the csi-send-cert = draft, possession of a
>>>>> |  certificate is no longer proof of any = particular authorization. 
>>>>> It seem
>>>>> |  clear to me that the authorization = validation described in
>>>>> RFC3971 is no
>>>>> |  longer sufficient.  I believe that a = discussion is needed of
>>>>> what messages
>>>>> |  require or allow each particular key = purpose authorization. 
>>>>> Issuing an
>>>>> |  RA, for example, seems likely to require = the "router" value of
>>>>> the key
>>>>> |  purpose field, if the new certificate = format was used for
>>>>> authorization.
>>>>> |  Issuing an NA may require the = "owner" value of the key purpose
>>>>> field, if
>>>>> |  the new certificate format was used for = authorization rather
>>>>> than a CGA.
>>>>> |  I do not know if that discussion would be = more appropriate here
>>>>> or in the
>>>>> |  csi-send-cert draft, or another draft = entirely that updates RFC3971
>>>>> |  directly.
>>>>> |
>>>>> |  If a SPND proxy was using SEND to = communicate with other nodes that
>>>>> |  understood SPND, would it be OK to use a = new format cert (with the
>>>>> |  "router" KeyPurposeId) as a = router certificate for the SEND RSA
>>>>> Signature
>>>>> |  Options?
>>>>> |
>>>>> I see. I agree that this needs more precision.
>>>>>
>>>>> In draft-ietf-csi-send-cert-05, section 7 (it is = the same text as
>>>>> in cert-04) it discusses the messages that are = authorized by each
>>>>> KeyPurposeId
>>>>> - "router authorization value indicates that = the
>>>>>    certificate has been issued for = allowing the router to advertise
>>>>>    prefix(es)"
>>>>> (I understand that implicitly states that it = authorizes the
>>>>> generation of RA messages. It is not crystal clear = for me if it
>>>>> authorizes NA for routers, although if I had to = take this text
>>>>> literally, I would suppose routers would need an = 'owner'
>>>>> authorization if this PKI model substitutes RFC3971 = CGA
>>>>> authorization, considering that the prefix for NA = would be narrowed
>>>>> in general to one address, while the RA = authorization is prefix-wide)
>>>>> - "proxy authorization value indicates that = the
>>>>>    certificate has been issued for = allowing the proxy to perform
>>>>>    proxying of neighbor discovery = messages for the prefix(es) that are
>>>>>    mentioned using the X.509 = extensions for IP addresses"
>>>>> (I understand it now implicitly states it = authorizes for ANY
>>>>> neighbor discovery message. By the way, this is the = assumption
>>>>> underlying in general draft-ietf-csi-proxy-send-04: = in the
>>>>> application scenarios, some require RA proxying, = which is assumed
>>>>> to be performed by means of the proxy cert)
>>>>> - "owner authorization [...]For an
>>>>>    address in such certificate the = host can assign the address, send/
>>>>>    receive traffic from this = address, and can respond to NSes about
>>>>> that
>>>>>    address"
>>>>> (this is the clearest of all statements - although = I think issuing
>>>>> secured NS and RS should also be considered)
>>>>>
>>>>> So, as defined now in draft-ietf-csi-proxy-send-04, = proxy
>>>>> certificates provide authorization for securing = *any* ND message.
>>>>> Considering the application scenarios, some require = proxying RA
>>>>> (PMIPv6 and RFC4389), and the MIPv6 scenario just = require NS/NA
>>>>> proxying.
>>>>>
>>>>> In summary so far, there is some specification of = the authorization
>>>>> in draft-csi-send-cert, which I think it would be = nice that it
>>>>> could be refined, and if so, my opinion is that the = refinement of
>>>>> which ND message is authorized by each KeyPurposeId = should be in
>>>>> that document.
>>>>> However, continuing with this issue, I must say = that the way the
>>>>> 'proxy authorization' is defined, and the = relationship with the
>>>>> other cases, is not satisfactory for me.
>>>>> I think the use of 'owner' should be restricted for = hosts that
>>>>> really own the address (therefore, a substitution = of the CGA
>>>>> mechanism) - as opposed to proxies.
>>>>> For the 'proxy authorization', I think it could be = refined into
>>>>> something like "proxy host" = authorization, and "proxy router"
>>>>> authorization.
>>>>> 'Proxy host' would authorize for proxying NA, NS = and RS, and "proxy
>>>>> router" authorization would authorize RA and = Redirect. This would
>>>>> provide a finer grain which I think would be = desirable (for
>>>>> example, MIPv6 does not need protecting neither RA = nor redirect).
>>>>> I think this would work (if so, it should be = changed in
>>>>> draft-csi-send-cert).
>>>>>
>>>>> What do you think? (both authors of = draft-csi-send-cert, Sandra,
>>>>> etc.).
>>>>>
>>>>> Regards,
>>>>> Alberto
>>>>>
>>>>>
>
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.or= g/mailman/listinfo/secdir
>

------_=_NextPart_001_01CB5432.FC12282A-- From jhutz@cmu.edu Tue Sep 14 13:33:13 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4F333A6A8B; Tue, 14 Sep 2010 13:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.556 X-Spam-Level: X-Spam-Status: No, score=-106.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PslrS7oDGMu; Tue, 14 Sep 2010 13:33:10 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id 21E5C3A6AFC; Tue, 14 Sep 2010 13:32:53 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8EKWlM7006867 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Sep 2010 16:32:47 -0400 (EDT) Date: Tue, 14 Sep 2010 16:32:47 -0400 From: Jeffrey Hutzelman To: Sean Turner , marcelo bagnulo braun Message-ID: <8EA3785E28E67B2A2DC45EC3@minbar.fac.cs.cmu.edu> In-Reply-To: <29443_1284477154_o8EFCWBY026030_4C8F90D4.3040301@ieca.com> References: <8984FD9D-2516-437A-AEF3-8E0F5DDAD6EB@cisco.com> <241F9803-ED2F-48B2-B192-2AC02B280433@cisco.com> <4C8E41F6.906@it.uc3m.es> <29443_1284477154_o8EFCWBY026030_4C8F90D4.3040301@ieca.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: Roque Gagliano , draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, Sandra Murphy , =?UTF-8?Q?Garc=C3=ADa?= , draft-ietf-csi-proxy-send.all@tools.ietf.org, Alberto@core3.amsl.com, IESG IESG , csi-chairs@tools.ietf.org, Ralph Droms Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 20:33:13 -0000 --On Tuesday, September 14, 2010 11:12:20 AM -0400 Sean Turner wrote: >> The new EKU is the proposed way to deal with one comment from Sandy's >> review of the proxy send document. It seems we could live without, but >> it would be a somehow inferior solution. I would suggest that unless >> getting a new EKU is a lot of work, we go ahead with that. > > Getting an EKU is pretty easy. Ask Russ Housley > (cced) for one. He controls assigning the OID out of the PKIX arc. > Obvioulsy, you'll need to add some text in the document to explain its > use. In fact, it can be even easier than that. The whole point of using OIDs for this is that an EKU can be _any_ OID, not just one out of that arc. So if you have your own arc (or a PEN), you can assign your own OID. -- Jeff From barryleiba.mailing.lists@gmail.com Tue Sep 14 14:40:56 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CB2E3A6B5C; Tue, 14 Sep 2010 14:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 tagged_above=-999 required=5 tests=[AWL=-0.286, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzAG7LxlADdt; Tue, 14 Sep 2010 14:40:51 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id A64933A6B4E; Tue, 14 Sep 2010 14:39:32 -0700 (PDT) Received: by gwb20 with SMTP id 20so3310814gwb.31 for ; Tue, 14 Sep 2010 14:39:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:reply-to:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+TkntEpq1x3Vu7ud+mAMhk5OwoYsYWy5TGmhXGUOg4c=; b=NBFIZ8+4/pDq7QvgpLjnYu8wuvMqMJoaUq6aJAdI8A14PW8vyQ4e7jK7c7WvIi7MER ELRb3vQX7gXjHE/XcslBo7Sc/WCgL8jgGJoecfn+VqXiM8U/DMfNlxeoYbbg07v+PMh7 ig1K0lb1JUlCQxHTLRcGe37T17bIq5k1r4Pbk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; b=DEA0+KMUauZTyzRN4GgVjidD98gLcGpGPKq4t/VnDwp6v2Yvxu+U4BZ/72eIGzUrMk +21E7v1wtkOqXiGZnx9iDgg2ARfhoMKCL+CuzIAcYGQl5xmIqILElRLKOVuGWmxstnNN PBLM6YBgBwEwY2FZIL409RgWMjBtPg8jGimJQ= MIME-Version: 1.0 Received: by 10.150.95.3 with SMTP id s3mr134307ybb.338.1284500381091; Tue, 14 Sep 2010 14:39:41 -0700 (PDT) Received: by 10.42.8.196 with HTTP; Tue, 14 Sep 2010 14:39:40 -0700 (PDT) Date: Tue, 14 Sep 2010 17:39:40 -0400 Message-ID: From: Barry Leiba To: draft-saintandre-tls-server-id-check.all@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: iesg@ietf.org, secdir@ietf.org Subject: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: barryleiba@computer.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 21:40:56 -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. Please forgive the lateness of this review; I really meant to have it done sooner. First, I found the document to be a tough read, and I can't really pin down why. I started reviewing it several times, and restarted, before I finally got through it. I can't give any advice with this comment, so just take it as it is. Second, there's a mixture of "natural person" and "human user" in the document, and my sense is that you mean the same thing by both. If you do, you should switch to one term (I prefer the latter; "natural person" sounds odd). If they're meant to be different, you should make it clear what the difference is. Third, I'll note the earlier discussion of issues with IDN comparisons. I have nothing to add to that discussion, and it may be that the best thing is to leave things as they are. Comments are in order of appearance, not significance: -- Page 16, bullet 6: The certificate MAY contain more than one DNS-ID, but SHOULD NOT contain more than one CN-ID. Why "SHOULD NOT", and not "MUST NOT" ? I'm not challenging this; it's a question. -- Page 17, sec 4.2, first graf: Before connecting to the server, the client MUST construct a list of acceptable reference identifiers. Why MUST it be done "before"? Can anyone detect, or does it hurt interoperability, if it's done, say, in parallel with connection, or while the client is waiting for the server to return the certificate? -- Page 18, sec 4.2, last bullet: o The list SHOULD NOT include a CN-ID; however, the CN-ID (if included) MUST be constructed only from the source domain and never from a target domain. I find this oddly put. How about "The list SHOULD NOT include a CN-ID. If a CN-ID is used despite this advice, it MUST be..." ? I'd also like to take the security note from section 4.3 and echo it here. So maybe this?: << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite this advice, it MUST be constructed only from the source domain and never from a target domain. Further, it MUST NOT be used unless there are no other supported identifiers present in the certificate. >> -- Page 18, sec 4.3, first graf: by seeking a match and aborting the search if any presented identifier matches one of its reference identifiers. "Aborting" has the connotation of premature termination, before completion, and that's not the case here; you're saying that the match completes the process. How about, simply, "stopping", or "ending" ? -- Page 19, sec 4.4.3: I think implementers might think that you're simply allowing any leading wildcard character, so we should explicitly dissuade them. So, in the first graf: the wildcard character '*', but only as the left-most label of the domain name, make it "only as the complete value of the left-most label". And in the second graf: in which the wildcard character is contained within a label fragment (e.g., baz*.example.net is not allowed and MUST NOT be taken to match baz1.example.net and baz2.example.net) change to: baz1.example.net and baz2.example.net; also, *bozz.example.net is not allowed and MUST NOT be taken to match frobozz.example.net) -- Page 19, sec 4.4.3, last graf: A specification that references the rules defined in this document can specify that the wildcard character is not allowed in certificates used by the relevant application protocol or community of interest. How about =93...can strengthen this section by ruling out wildcard matching altogether for the relevant...=94 ? -- Page 20, sec 4.4.4, second graf: entry types supported by the client), the client MAY as a fallback check for a string whose form matches that of a fully-qualified DNS domain name in the CN-ID. Back in section 4.2, you say that the client SHOULD NOT include CN-ID in the list, and here you're saying that it MAY make such a comparison. That seems oddly contradictory to me, though one can certainly argue that SHOULD NOT implies MAY. I'd prefer to see this worded differently. -- Page 21, sec 4.6.2: client MUST verify that the presented certificate matches the cached certificate and (if it is an interactive client) MUST notify the user if the certificate has changed since the last time a secure connection was successfully negotiated (where causes of change include but are not limited to changes in the DNS domain name, identifiers, issuer, certification path, and expiration date). I worry about this kind of advice. It violates my rule that says, "Don't ask the user a question that he's not qualified to answer." Of course, "notify the user" can mean a lot of things, but too many clients will implement something like this with a popup that will be meaningless to 99% of the people who use it. -- Page 21, sec 4.6.3, last graf: Instead, the client MUST proceed as follows. I like a colon there, instead of the full stop. -- Page 21, sec 4.6.3.1, security note: caution, for example by first encouraging the user to terminate the connection, forcing the user to view the entire certification path, and allowing the user to accept the certificate only on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session). Same comment as for 4.6.2. Most users will not understand certificate problems, and will have no idea what they should do about them. Always remember the "Barry's mother problem". My mother will *never* want to see an "entire certification path", let alone appreciate being "forced" to. -- Page 22, sec 5.1: When the connecting application is an interactive client, the source domain name and service type MUST be provided by a human user (e.g. when specifying the server portion of the user's account name on the server or when explicitly configuring the client to connect to a particular host or URI as in [SIP-LOC]) and MUST NOT be derived from the user inputs in an automated fashion (e.g., a host name or domain name discovered through DNS resolution of the source domain). This rule is important because only a match between the user inputs (in the form of a reference identifier) and a presented identifier enables the client to be sure that the certificate can legitimately be used to secure the connection. Does this mean that a client specifically designed for the "gumbo" service can't automatically use the service type "gumbo", without the user's involvement? Or that a client put out by example.net can't assume a host name of services.example.net in the absence of user input that says otherwise? Further, it's entirely reasonable for a program to have a user enter something like "gmail", and have the client turn that into something like "mail.google.com", deriving it from the user's input in an automated fashion. Do we really want to forbid that sort of thing? -- Barry Leiba From tena@huawei.com Tue Sep 14 20:03:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A6683A6922; Tue, 14 Sep 2010 20:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.199 X-Spam-Level: X-Spam-Status: No, score=-100.199 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4qw2iiHhKcF; Tue, 14 Sep 2010 20:02:59 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id C08B43A6867; Tue, 14 Sep 2010 20:02:58 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8R00AQ2PTBQN@szxga02-in.huawei.com>; Wed, 15 Sep 2010 11:03:12 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L8R00HS3PTBDP@szxga02-in.huawei.com>; Wed, 15 Sep 2010 11:03:11 +0800 (CST) Received: from z00147053k ([10.70.39.122]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L8R00JYHPTBA9@szxml06-in.huawei.com>; Wed, 15 Sep 2010 11:03:11 +0800 (CST) Date: Wed, 15 Sep 2010 11:03:11 +0800 From: Tina TSOU To: Tim Winter Message-id: <65F35EC6237847ACABFFBD50FE21E405@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <44BCD8D277C6479097DB80AF063B4325@china.huawei.com> <4C8F9B6A.1080708@acm.org> Cc: secdir-secretary@mit.edu, iesg@ietf.org, draft-ietf-roll-rpl@tools.ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-ietf-roll-rpl-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 03:03:00 -0000 Tim, That's fine for me. B. R. Tina http://tinatsou.weebly.com ----- Original Message ----- From: "Tim Winter" To: "Tina TSOU" Cc: ; ; ; Sent: Tuesday, September 14, 2010 11:57 PM Subject: Re: [secdir] secdir review of draft-ietf-roll-rpl-11 > Hi Tina, > > On 08/31/2010 11:22 PM, Tina TSOU 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. > > Thank you for your review. > > > > > This draft is well written. I only have two comments. > > > > 1. It is lack of manageability aspects to produce MIB; > > As far as the MIB in general, we did not define a MIB but instead did > describe some general manageability aspects in Section 17. We chose to > defer to the CoRE working group and other future work to specify the > details, as introduced in Section 17.1: > > Most of the existing IETF management standards are Structure of > Management Information (SMI) based data models (MIB modules) to > monitor and manage networking devices. > > For a number of protocols, the IETF community has used the IETF > Standard Management Framework, including the Simple Network > Management Protocol [RFC3410], the Structure of Management > Information [RFC2578], and MIB data models for managing new > protocols. > > As pointed out in [RFC5706], the common policy in terms of > operation > and management has been expanded to a policy that is more open to a > set of tools and management protocols rather than strictly relying > on a single protocol such as SNMP. > > In 2003, the Internet Architecture Board (IAB) held a workshop on > Network Management [RFC3535] that discussed the strengths and > weaknesses of some IETF network management protocols and compared > them to operational needs, especially configuration. > > One issue discussed was the user-unfriendliness of the binary > format > of SNMP [RFC3410]. In the case of LLNs, it must be noted that at > the time of writing, the CoRE Working Group is actively working on > resource management of devices in LLNs. Still, it is felt that > this > section provides important guidance on how RPL should be deployed, > operated, and managed. > > More specifically, we propose to add some text to call out aspects of > security manageability. > > > > 2. Should be added flow examples for RPL; > > We can come up with a few illustrative examples and add those to the > draft. > > > > > > > > > > B. R. Tina http://tinatsou.weebly.com/index.html > > > > > > > Does this address your concerns? > > Regards, > > -RPL Authors > From new-work-bounces@ietf.org Tue Sep 14 14:40:51 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E63743A6B5E; Tue, 14 Sep 2010 14:40:51 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 46A843A6B55; Tue, 14 Sep 2010 14:39:56 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100914214001.46A843A6B55@core3.amsl.com> Date: Tue, 14 Sep 2010 14:39:56 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 07:11:04 -0700 Subject: [secdir] [new-work] WG Review: Energy Management (eman) 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, 14 Sep 2010 21:40:52 -0000 A new IETF working group has been proposed in the Operations and Management 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 September 21, 2010. Energy Management (eman) --------------------------------------------------- Current Status: Proposed Working Group Last Modified: 2010-09-09 Chairs: TBD Area Director: Dan Romascanu (dromasca@avaya.com) Mailing List Address: eman@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/eman Archive: http://www.ietf.org/mail-archive/web/eman Description of Working Group Energy management is becoming an additional requirement for network management systems due to several factors including the rising and fluctuating energy costs, the increased awareness of the ecological impact of operating networks and devices, and the regulation of governments on energy consumption and production. The basic objective of energy management is operating communication networks and other equipments with a minimal amount of energy while still providing sufficient performance to meet service level objectives. A discussion of detailed requirements has already started in the OPSAWG, but further exploration in the EMAN WG is needed. Today, most networking and network-attached devices neither monitor nor allow control energy usage as they are mainly instrumented for functions such as fault, configuration, accounting, performance, and security management. These devices are not instrumented to be aware of energy consumption. There are very few means specified in IETF documents for energy management, which includes the areas of power monitoring, energy monitoring, and power state control. The OPSAWG started working on a MIB module for monitoring energy consumption and power states of energy-aware devices and found that more than just a MIB module was needed to manage energy in networks. Rather a new framework for energy management needs to be developed first. A particular difference between energy management and other management tasks is that in some cases energy consumption of a device is not measured at the device itself but reported by a different place. For example, at a Power over Ethernet (PoE) sourcing device or at a smart power strip, in which cases one device is effectively metering another remote device. This requires a clear definition of the relationship between the reporting devices and identification of remote devices for which monitoring information is provided. Similar considerations will apply to power state control of remote devices, for example, at a PoE sourcing device that switches on and off power at its ports. The WG will investigate existing standards such as those from the IEC, ANSI, DMTF and others, and reuse existing work as much as possible. The EMAN WG will work on the management of energy-aware devices, covered by the following items : 1. Requirements for energy management. The EMAN WG will develop a requirements document that will specify energy management properties that will allow networks and devices to become energy aware. In addition to energy awareness requirements, the need for control functions will be discussed. Specifically the need to monitor and control properties of devices that are remote to the reporting device should be discussed. 2. Energy management framework. The EMAN WG will create a framework document that will describe extensions to current management framework, required for energy management. This includes: power and energy monitoring, power states, power state control, and potential power state transitions. The framework will focus on energy management for IP-based network equipment (routers, switches, IP cameras, phones and the like). Particularly, the relationships between reporting devices, remote devices, and monitoring probes (such as might be used in low-power and lossy networks) need to be elaborated. For the case of a device reporting on behalf of other devices and controlling those devices, the framework will address the issues of discovery and identification of remote devices. 3. Energy-aware Networks and Devices MIB document The EMAN WG will develop a MIB module for monitoring energy-aware networks and devices. The module will address devices identification, context information, and potential relationship between reporting devices, remote devices, and monitoring probes. 4. Power and Energy Monitoring MIB document The EMAN WG will develop a document defining managed objects for monitoring of power states and energy consumption/production. The monitoring of power states includes: retrieving power states, properties of power states, current power state, power state transitions, and power state statistics. The managed objects will provide means for reporting detailed properties of the actual energy rate (power) and of accumulated energy. Further, it will provide information on electrical power quality. 5. Battery MIB document The EMAN WG will develop a document defining managed objects for battery monitoring, which will provide means for reporting detailed properties of the actual charge, age, and state of a battery and of battery statistics. 6. Applicability statement The EMAN WG will develop an applicability statement, describing the variety of applications that can use the energy framework and associated MIB modules. Potential examples are building networks, home energy gateway, etc. Finally, the document will also discuss relationships of the framework to other architectures and frameworks (such as smartgrid). The applicability statement will explain the relationship between the work in this WG and the other existing standards such as those from the IEC, ANSI, DMTF, and others. Goals and Milestones Dec 2010 Publish Internet draft on Energy Management Requirements Dec 2010 Publish Internet draft on Energy Management Framework Dec 2010 Publish Internet draft on Energy-aware Networks and Devices MIB Dec 2010 Publish Internet draft on Power and Energy Monitoring MIB Dec 2010 Publish Internet draft on Battery MIB Apr 2011 Publish Internet draft on Energy Management Applicability May 2011 Submit Internet draft on Energy Management Requirements for publication as Informational RFC Sep 2011 Submit Internet draft on Energy Management Framework for publication as Informational RFC Sep 2011 Submit Internet draft on Energy-aware Networks and Devices MIB for publication as Standard Track RFC Sep 2011 Submit Internet draft on Power and Energy Monitoring MIB for publication as Standard Track RFC Sep 2011 Submit Internet draft on Battery MIB for publication as Standard Track RFC Dec 2011 Submit Internet draft on Energy Management Applicability for publication as Informational RFC _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Sep 14 15:28:05 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63E2A3A6B3C; Tue, 14 Sep 2010 15:28:05 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 0173E3A6B20; Tue, 14 Sep 2010 15:28:03 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100914222804.0173E3A6B20@core3.amsl.com> Date: Tue, 14 Sep 2010 15:28:03 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 15 Sep 2010 07:11:05 -0700 Subject: [secdir] [new-work] WG Review: Recharter of Hypertext Transfer Protocol Bis (httpbis) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Sep 2010 22:28:05 -0000 A modified charter has been submitted for the Hypertext Transfer Protocol Bis (httpbis) working group in the Applications 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 September 21, 2010. Hypertext Transfer Protocol Bis (httpbis) --------------------------------------------------- Current Status: Active Working Group Last modified: 2010-09-02 Chairs: Mark Nottingham (mnot@pobox.com) Applications Area Director(s): Alexey Melnikov (alexey.melnikov@isode.com) Peter Saint Andre (stpeter@stpeter.im) Applications Area Advisor: Alexey Melnikov (alexey.melnikov@isode.com) Mailing Lists: General Discussion: ietf-http-wg@w3.org To Subscribe:ietf-http-wg-request@w3.org Subject: subscribe Archive: http://lists.w3.org/Archives/Public/ietf-http-wg/ Description of Working Group HTTP is one of the most successful and widely-used protocols on the Internet today. However, its specification has several editorial issues. Additionally, after years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP. The working group will refine RFC2616 to: * Incorporate errata and updates (e.g., references, IANA registries, ABNF) * Fix editorial problems which have led to misunderstandings of the specification * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Where necessary, add implementation advice * Document the security properties of HTTP and its associated mechanisms (e.g., Basic and Digest authentication, cookies, TLS) for common applications It will also incorporate the generic authentication framework from RFC 2617, without obsoleting or updating that specification's definition of the Basic and Digest schemes. Finally, it will incorporate relevant portions of RFC 2817 (in particular, the CONNECT method and advice on the use of Upgrade), so that that specification can be moved to Historic status. In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP * Impact on existing implementations and deployments The Working Group must not introduce a new version of HTTP and should not add new functionality to HTTP. The WG is not tasked with producing new methods, headers, or extension mechanisms, but may introduce new protocol elements if necessary as part of revising existing functionality which has proven to be problematic. The Working Group's specification deliverables are: * A document (or set of documents) that is suitable to supersede RFC 2616 and move RFC 2817 to Historic status * A document cataloguing the security properties of HTTP Goals and Milestones Done First HTTP Revision Internet Draft Done First HTTP Security Properties Internet Draft Nov 2010 Request Last Call for HTTP Revision Nov 2010 Request Last Call for HTTP Security Properties Apr 2011 Submit HTTP Revision to IESG for consideration as a Draft Standard Apr 2011 Submit HTTP Security Properties to IESG for consideration as Informational _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From Kurt.Zeilenga@Isode.com Wed Sep 15 08:02:23 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B6A3A69B6; Wed, 15 Sep 2010 08:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zz9jlLzKgJ8P; Wed, 15 Sep 2010 08:02:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id 710053A69A6; Wed, 15 Sep 2010 08:02:20 -0700 (PDT) Received: from [10.1.10.199] (c-67-174-234-87.hsd1.ca.comcast.net [67.174.234.87]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 15 Sep 2010 16:02:45 +0100 From: Kurt Zeilenga Date: Wed, 15 Sep 2010 08:02:41 -0700 Message-Id: <3277758F-B774-49B6-9AB0-4BC17C352D24@Isode.com> To: IESG IESG X-Mailer: Apple Mail (2.1081) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-ccamp-lsp-hierarchy-bis@tools.ietf.org, Security Area Directorate Subject: [secdir] secdir review: draft-ietf-ccamp-lsp-hierarchy-bis X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 15:02:23 -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. I have reviewed this document and find the "Security Considerations" = section adequately addresses security issues. Regards, Kurt= From weiler@watson.org Wed Sep 15 11:13:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050CC3A696B; Wed, 15 Sep 2010 11:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.859 X-Spam-Level: X-Spam-Status: No, score=-1.859 tagged_above=-999 required=5 tests=[AWL=0.740, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8hesBnSQV+l; Wed, 15 Sep 2010 11:13:29 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 8DB133A6848; Wed, 15 Sep 2010 11:13:29 -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 o8FIDs59013201; Wed, 15 Sep 2010 14:13:54 -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 o8FIDrQA013198; Wed, 15 Sep 2010 14:13:53 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Wed, 15 Sep 2010 14:13:53 -0400 (EDT) From: Samuel Weiler To: ietf@ietf.org, secdir@ietf.org, draft-ietf-opsec-igp-crypto-requirements.all@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, 15 Sep 2010 14:13:54 -0400 (EDT) Subject: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:13:41 -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 is an informational document that appearently recaps requirement levels for implementation and use of crypto algorithms for hop-by-hop authentication of routing data. Assuming that no requirements are being changed, I have no objections to the security considerations analysis, but I do have editorial comments. I got lost as to the purpose of this doc. Please reword the abstract and intro to make it clear that you're merely recapping requirements, not setting them (if that is indeed true). Is there a way to present this information more compactly? I suggest a table with routing protocol on one axis, crypto suite on another, and requirement status in the elements (perhaps with a cite to the doc that sets the requirement). You might separely say "MANDATORY to implement, OPTIONAL to use, NOT SUGGESTED for use". You could also put suggestions and speculation about the future in the same table, though you may need to define some terms. And it needs to be clear when this doc diverges from past ones or makes a new statement. I have not gone back through the previous docs to confirm that this doc isn't changing anything. I see a whole bunch of lower case "may" and "should", and I'm wondering what to make of them. In describing each routing protocol's authentication options, it would be helpful to say whether there's any in-band negotiation available. If so, more needs to be said about that in the security considerations. If not, it should be documented here. I don't need to hear three or four separate times that cleartext passwords are bad. Minor: remove citations from the abstract (per rfc editor policy). -- Sam From jhutz@cmu.edu Wed Sep 15 11:30:40 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C80313A6848; Wed, 15 Sep 2010 11:30:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.557 X-Spam-Level: X-Spam-Status: No, score=-106.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR3uBy45WZKl; Wed, 15 Sep 2010 11:30:39 -0700 (PDT) Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id 5670D3A69B4; Wed, 15 Sep 2010 11:30:27 -0700 (PDT) Received: from MINBAR.FAC.CS.CMU.EDU (MINBAR.FAC.CS.CMU.EDU [128.2.216.42]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8FIUnIt001518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Sep 2010 14:30:50 -0400 (EDT) Date: Wed, 15 Sep 2010 14:30:49 -0400 From: Jeffrey Hutzelman To: barryleiba@computer.org, draft-saintandre-tls-server-id-check.all@tools.ietf.org Message-ID: <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> In-Reply-To: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.196 Cc: iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 18:30:40 -0000 --On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba wrote: > Second, there's a mixture of "natural person" and "human user" in the > document, and my sense is that you mean the same thing by both. If > you do, you should switch to one term (I prefer the latter; "natural > person" sounds odd). If they're meant to be different, you should > make it clear what the difference is. When I hear "natural person", I think "as opposed to corporation". I'm pretty sure that's not what's meant here, and I agree it sounds odd. > -- Page 21, sec 4.6.2: > client MUST verify that the presented certificate matches the cached > certificate and (if it is an interactive client) MUST notify the user > if the certificate has changed since the last time a secure > connection was successfully negotiated (where causes of change > include but are not limited to changes in the DNS domain name, > identifiers, issuer, certification path, and expiration date). > > I worry about this kind of advice. It violates my rule that says, > "Don't ask the user a question that he's not qualified to answer." Of > course, "notify the user" can mean a lot of things, but too many > clients will implement something like this with a popup that will be > meaningless to 99% of the people who use it. In practice, this advice is meaningless, as the described situation cannot happen. This case happens only when "a natural person has permanently accepted the certificate", which implies the presented certificate is the same as the cached certificate. I think what this section is trying to describe is a situation where the user has permanently accepted _some_ certificate for the service in question. In this situation, the presented certificate should be accepted if it matches the cached one, and should not be accepted if it does not. In the latter case, the UI experience will not end up being noticeably different from that of 4.6.3 -- the presented cert can be accepted temporarily, permanently, or not at all, but someone or some policy has to make that decision. However, I think there does need to be a difference in how the user is presented with a mismatched certificate for a service with an existing cached cert as opposed to one without. In a leap-of-faith model, you want to accept a certificate for a previously-unknown service, but reject a wrong certificate for an already-known service. > -- Page 21, sec 4.6.3, last graf: > Instead, the client MUST proceed as follows. > > I like a colon there, instead of the full stop. > > -- Page 21, sec 4.6.3.1, security note: > caution, for example by first encouraging the user to terminate > the connection, forcing the user to view the entire certification > path, and allowing the user to accept the certificate only on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session). > > Same comment as for 4.6.2. Most users will not understand certificate > problems, and will have no idea what they should do about them. > Always remember the "Barry's mother problem". My mother will *never* > want to see an "entire certification path", let alone appreciate being > "forced" to. In fact, I see two problems with the quoted advice. First, since we're talking about a certificate name mismatch, the rest of the certification chain really isn't relevant. It would be if the problem were a chain that doesn't lead to a suitable trust anchor, but that's not what this document is about. That said, Barry, your mother is not an "advanced user" in the sense intended by this document, and should never even be given the option to accept a certificate that doesn't validate. The second issue is the advice that the user should be allowed to accept a certificate with a mismatched name only on a temporary basis. This is almost certain to be the wrong thing to do; if a name mismatch is acceptable, it's also not likely to change anytime soon, and requiring the user to accept the certificate again in a later session just because the client has restarted is just annoying with no security benefit. If we were talking about path validation rather than server naming, I'd point out that accepting a certificate only temporarily doesn't give you the benefit of being able to detect future changes, and so actually _reduces_ security. With names, this isn't a big deal, as it's relatively easy to decide whether foo.bank.com and foo.attacker.org are the same or not (well, unless the bank and attacker have the same name). > -- Page 22, sec 5.1: > When the connecting application is an interactive client, the source > domain name and service type MUST be provided by a human user (e.g. > when specifying the server portion of the user's account name on the > server or when explicitly configuring the client to connect to a > particular host or URI as in [SIP-LOC]) and MUST NOT be derived from > the user inputs in an automated fashion (e.g., a host name or domain > name discovered through DNS resolution of the source domain). This > rule is important because only a match between the user inputs (in > the form of a reference identifier) and a presented identifier > enables the client to be sure that the certificate can legitimately > be used to secure the connection. > > Does this mean that a client specifically designed for the "gumbo" > service can't automatically use the service type "gumbo", without the > user's involvement? I don't think it does. If a user is running a gumbo client, I think it's implied that he meant to talk to the gumbo service. But if he's running a web browser, the browser should not decide that the user meant to use the gumbo service by the presence of gumbo.example.com (or a corresponding SRV record) in the DNS, any more than it should assume from the presence of an alias www.example.com => gumbo.example.com that gumbo.example.com is an acceptable server name when the user typed www.example.com. > Or that a client put out by example.net can't > assume a host name of services.example.net in the absence of user > input that says otherwise? Again, I think this is fine; the client defines the lack of a user-specified name to mean something specific. What's not fine is to take the name given by the user and apply an insecure translation such as an unprotected DNS lookup. I think the advice in this paragraph is a little over-restrictive. What should be prohibited is not automated rewriting, but automated rewriting based on the use of insecure sources. RFC4120 has the following to say on this subject, as it relates to Kerberos: One can also rely on trusted third parties to make this determination, but only when the data obtained from the third party is suitably integrity-protected while resident on the third-party server and when transmitted. Thus, for example, one should not rely on an unprotected DNS record to map a host alias to the primary name of a server, accepting the primary name as the party that one intends to contact, since an attacker can modify the mapping and impersonate the party. > Further, it's entirely reasonable for a program to have a user enter > something like "gmail", and have the client turn that into something > like "mail.google.com", deriving it from the user's input in an > automated fashion. Not if the client does so by rewriting "gmail" as "www.gmail.com", looking that up in the DNS, and using the target of the resulting alias. Most web browsers already get this right, thankfully. -- Jeff From fernando.gont.netbook.win@gmail.com Thu Sep 16 01:29:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE00C3A68D3; Thu, 16 Sep 2010 01:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikovs6iBZzvn; Thu, 16 Sep 2010 01:29:40 -0700 (PDT) Received: from mail-gw0-f66.google.com (mail-gw0-f66.google.com [74.125.83.66]) by core3.amsl.com (Postfix) with ESMTP id 50B7F3A68C0; Thu, 16 Sep 2010 01:29:40 -0700 (PDT) Received: by gwb11 with SMTP id 11so199710gwb.1 for ; Thu, 16 Sep 2010 01:30:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=9e/H+/CVfJsWRQroIrwzifStSDjbbxIXrUuTDDAqoY0=; b=NSwApBHsVg5gKDM6U7MNMuPg0BT2C+hIwcvPqU7pm/NU+qUTB7KSo1raYcLU+5omHn TwwLZ3epKXEdusWl0F4Hi7EOJgkF0UQAaq2Pe5UIOQJEvBhti46YVUZedqLTnS7MZKQv zNGFKa9+O73Sid0eBjtnJVlkN3s7N5U0SpYyw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=A5qCvmDgQDgSR/Gz0d3V/WILSK/PLk9KheVrwTWKPdku3jtwZYoL20+te9IqYTeDug P0LTQVtombISe8D7rUZYfwdzTLR8jP7c5HmCnQM3Xb95CBnC3FH1F6nXul5qUdVAlzUV PYyRKbFOEoOM7ctAvvG9eeStPQyMJd/QMrPeg= Received: by 10.151.101.18 with SMTP id d18mr3309701ybm.277.1284625805197; Thu, 16 Sep 2010 01:30:05 -0700 (PDT) Received: from [192.168.2.4] (55-173-17-190.fibertel.com.ar [190.17.173.55]) by mx.google.com with ESMTPS id t20sm7241104ybm.17.2010.09.16.01.29.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 16 Sep 2010 01:30:03 -0700 (PDT) Sender: Fernando Gont Message-ID: <4C91C9EE.1000200@gont.com.ar> Date: Thu, 16 Sep 2010 04:40:30 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Dave Cridland References: <2234.1284367866.672579@puncture> In-Reply-To: <2234.1284367866.672579@puncture> X-Enigmail-Version: 1.1.1 OpenPGP: id=D076FFF1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, Security Area Directorate , The IESG , Apps Area Review List Subject: Re: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 08:29:42 -0000 Hi, David, Thanks so much for your feedback! Please find my comments inline.... > Simply dropping TCP Urgent data facilities removes an aspect of TCP > which - whilst not commonly used in most modern protocols - is > nevertheless still used for useful gain in FTP and TELNET. Actually, support for urgent data is not removed. We simply discourage its use. > The TCP urgent mechanism, as implemented, means that a single octet is > lost when the receiver handles the last "Urgent" data section. Thus > particularly when multiple urgent data segments are "in flight", it > becomes difficult to guess which octets will be lost by the receiver. > The SeolMa attack effectively uses these lost octets to pad strings used > in TCP based application protocols, thus defeating naïve NIDS pattern > matching. > > There is no discussion in the draft about SeolMa, indeed there isn't > even a mention of it in the Security Considerations. The security considerations does mention the problem of NIDS-evasion, although it only focuses on the semantics of the UP (but does not consider the OOB vs. in-band thing). Would re-writing the SecCons as follows address this point?: ---- cut here ---- Multiple factors can affect the data flow that is actually delivered to an application when the TCP urgent mechanism is employed; namely, the two possible interpretations of the semantics of the Urgent Pointer in current implementations (e.g., depending on the value of the tcp_stdurg sysctl), the possible implementation of the urgent mechanism as an Out-Of-Band (OOB) facility (vs. in-band as intenteded by the IETF specifications), and middle-boxes (such as packet scrubbers) or the end-systems themselves that could cause the "urgent data" to be processed "in band". This might make it difficult for a Network Intrusion Detection System (NIDS) to track the application-layer data transferred to the destination system, and thus lead to false negatives or false positives in the NIDS [CPNI-TCP] [phrack]. ---- cut here ---- > It's not clear to > me if the recommendation to use SO_OOBINLINE would have an effect here - > my gut feeling is that it would defeat SeolMa by making these "lost" > octets part of the normal data flow again. This wouldn't help for the challenge that NIDS face. This just helps in terms of interoperability: i.e., applications should still work if those "urgent data" are delivered in-band (whether because of setting SO_OOBINLINE or because a packet scrubber cleared the URG bit). > Cisco's solution relies on simply forcing urgent data to be non-urgent, > which will have knock-on effects on TELNET and FTP by default. It's not > clear to me from this document (including reading the references) How about if I replace this sentence of the SecCons: ---- cut here ---- However, this might cause interoperability problems or undesired behavior in the applications running on top of TCP. ---- cut here ---- with this one: ---- cut here ---- However, this might cause interoperability problems or undesired behavior in those applications that rely on the TCP urgent mechanism, such as Telner [telnet] and FTP [ftp] ---- cut here ---- ? > By instituting a blanket ban, in effect, for TCP Urgent data, this > effectively deprecates the entire mechanism. This may prove to be the > only solution, however my general feeling is that this may not be the case. Not that I like it... but in practice, it probably is. As you correctly mentioned before, when multiple segments are in flight, it becomes virtually impossible for a NIDS to be able to do its job. > Niggle: > > The Cisco-PIX reference does not describe the TCP Urgent behaviour > except by implication (it mentions adding rules to allow its use for > TELNET and FTP-PI, but that's it). I have a personal distaste for > product placement in RFCs, and would prefer that this reference pointed > at least at a Cisco paper describing default behaviour, etc. > > As an aside, the Cisco instructions actually show the user how to enable > urgent data on FTP-DTP, rather than FTP-PI, which is incorrect. I leave this one for Andrew to answer ;-) I'd just note that the reason for which Cisco Pix is referenced is probably because it's a widely deployed device that scrubs urgent indications. (i.e., "this thing is widely deployed"). > Specific Recommendations: > > - An informative reference to FTP and TELNET, noting how and why the URG > pointer is used, would make it more obvious what is lost here. Would the re-written text I indicated above do, or do you think we should get into the specifics of what the urgent mechanism is used for in FTP and telnet? > - A more detailed description of SeolMa, and its implications, would be > useful, and I think required in the Security Considerations section. Please let me know if the change indicated above would do. > - I feel that further consideration of the proposed solution to SeolMa > is warranted. You mean what we propose to fix this NIDS evasion technique? Thanks! Kind regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From joelja@bogus.com Thu Sep 16 11:31:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 834FB3A68F3; Thu, 16 Sep 2010 11:31:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43yjuy2NhHzL; Thu, 16 Sep 2010 11:31:28 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) by core3.amsl.com (Postfix) with ESMTP id 3C2653A6998; Thu, 16 Sep 2010 11:31:27 -0700 (PDT) Received: from joelja-mac.local (ip24-252-91-238.no.no.cox.net [24.252.91.238]) (authenticated bits=0) by nagasaki.bogus.com (8.14.4/8.14.4) with ESMTP id o8GIVkAw049215 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT); Thu, 16 Sep 2010 18:31:48 GMT (envelope-from joelja@bogus.com) Message-ID: <4C92628C.2090600@bogus.com> Date: Thu, 16 Sep 2010 11:31:40 -0700 From: Joel Jaeggli User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: "Bhatia, Manav (Manav)" References: <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.com> In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (nagasaki.bogus.com [147.28.0.81]); Thu, 16 Sep 2010 18:31:49 +0000 (UTC) Cc: Samuel Weiler , "draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2010 18:31:29 -0000 On 9/15/10 4:36 PM, Bhatia, Manav (Manav) wrote: > Hi Samuel, > > Thanks for the review. > >> Is there a way to present this information more compactly? I >> suggest a table with routing protocol on one axis, crypto suite on >> another, and requirement status in the elements (perhaps with a >> cite to the doc that sets the requirement). You might separely say >> "MANDATORY to implement, OPTIONAL to use, NOT SUGGESTED for use". > > This is precisely what we were doing till the OPSEC WG members asked > us to change the format to the current one. And the current method is still the right way to do it imho. the doc is not intended to impose the requirement on protocol authors, rather to point out how requirements would shift in the case of prference for another algorithm... >> >> You could also put suggestions and speculation about the future in >> the same table, though you may need to define some terms. And it > > We were using extended 2119 terms like SHOULD+, MUST- and MAY+ > originally and these were again removed because of the strong > consensus in the WG in favor of the current text. They were confusing, and detracted from the recomendations. to cite a particular section that I think underscores this: IS-IS implementations SHOULD provide support for the generic cryptographic authentication scheme [RFC5310] and it is our understanding that interoperability considerations will require change to a MUST as operators migrate to this authentication scheme. which I interpret as: RFC 5310 states that is-is implementations should implement support for the generic cryptographic authentication scheme. If at some future date recommendations were to support a key method other than HMAC-MD5 then it would follow that support for the generic cryptographic authentication scheme would become a requirement. SHOULD- MUST+ makes interpreting that a WTF moment. >> needs to be clear when this doc diverges from past ones or makes a >> new statement. I have not gone back through the previous docs to >> confirm that this doc isn't changing anything. >> >> I see a whole bunch of lower case "may" and "should", and I'm >> wondering what to make of them. that they are not normative language. >> In describing each routing protocol's authentication options, it >> would be helpful to say whether there's any in-band negotiation >> available. > > I am not sure I understand whats being meant by in-band negotiation > here? this document is focused on operational considerations of exist protocols so for example a karp supplied kmp is probably out of scope for the document in it's present form. >> If so, more needs to be said about that in the security >> considerations. If not, it should be documented here. >> >> I don't need to hear three or four separate times that cleartext >> passwords are bad. > > Just making sure that folks don't miss this! :) > >> >> Minor: remove citations from the abstract (per rfc editor policy). > > Sure, will do. > > Cheers, Manav > >> >> -- Sam >> >> > _______________________________________________ Ietf mailing list > Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf > From weiler@watson.org Thu Sep 16 19:34:58 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6B133A6961 for ; Thu, 16 Sep 2010 19:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX3Eg--bxzGg for ; Thu, 16 Sep 2010 19:34:56 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 97BC53A67E5 for ; Thu, 16 Sep 2010 19:34:55 -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 o8H2ZA8p086912 for ; Thu, 16 Sep 2010 22:35:10 -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 o8H2ZA9Y086909 for ; Thu, 16 Sep 2010 22:35:10 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 16 Sep 2010 22:35:09 -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]); Thu, 16 Sep 2010 22:35:10 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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, 17 Sep 2010 02:34:58 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Steve Hanna is next in the rotation. For telechat 2010-09-23 Reviewer LC end Draft Donald Eastlake T 2010-09-21 draft-ietf-mext-nemo-pd-06 Vincent Roca T 2010-08-23 draft-ietf-fecframe-framework-10 Nico Williams T 2010-09-10 draft-ietf-fecframe-sdp-elements-08 Glen Zorn T 2010-07-26 draft-cakulev-mikey-ibake-02 For telechat 2010-10-07 Reviewer LC end Draft David McGrew T 2010-08-05 draft-ietf-pce-manageability-requirements-10 For telechat 2010-10-21 Reviewer LC end Draft Shawn Emery T 2010-10-11 draft-arkko-townsley-coexistence-04 Last calls and special requests: Reviewer LC end Draft Derek Atkins 2010-09-14 draft-ietf-eai-frmwrk-4952bis-07 Rob Austein 2010-09-27 draft-ietf-grow-bgp-graceful-shutdown-requirements-04 Alan DeKok 2010-09-27 draft-ietf-v6ops-cpe-simple-security-12 Stephen Farrell 2010-09-28 draft-ietf-avt-rapid-acquisition-for-rtp-15 Tobias Gondrom 2010-09-27 draft-ietf-mpls-ldp-igp-sync-bcast-04 Phillip Hallam-Baker 2010-10-11 draft-zeilenga-ldap-dontusecopy-08 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 David McGrew - draft-ietf-ecrit-framework-11 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Tom Yu 2010-09-27 draft-gundavelli-v6ops-l2-unicast-04 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From alexey.melnikov@isode.com Fri Sep 17 02:26:15 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBAC03A68C3 for ; Fri, 17 Sep 2010 02:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMVfE4GmVSsf for ; Fri, 17 Sep 2010 02:26:15 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by core3.amsl.com (Postfix) with ESMTP id A20113A696F for ; Fri, 17 Sep 2010 02:26:14 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 17 Sep 2010 10:26:38 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4C933439.5000006@isode.com> Date: Fri, 17 Sep 2010 10:26:17 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: secdir-secretary@mit.edu References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: secdir@ietf.org Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Sep 2010 09:26:15 -0000 Samuel Weiler wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > Steve Hanna is next in the rotation. > > For telechat 2010-09-23 > > Reviewer LC end Draft > Donald Eastlake T 2010-09-21 draft-ietf-mext-nemo-pd-06 > Vincent Roca T 2010-08-23 draft-ietf-fecframe-framework-10 > Nico Williams T 2010-09-10 draft-ietf-fecframe-sdp-elements-08 > Glen Zorn T 2010-07-26 draft-cakulev-mikey-ibake-02 [...] > Last calls and special requests: > > Reviewer LC end Draft > Derek Atkins 2010-09-14 draft-ietf-eai-frmwrk-4952bis-07 Actually, this document should be in IESG review on September 23rd. From manav.bhatia@alcatel-lucent.com Wed Sep 15 16:36:20 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A4923A6AAB; Wed, 15 Sep 2010 16:36:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2LpmjiKc77G; Wed, 15 Sep 2010 16:36:07 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by core3.amsl.com (Postfix) with ESMTP id A4A3C3A6AAD; Wed, 15 Sep 2010 16:36:02 -0700 (PDT) Received: from inbansmailrelay2.in.alcatel-lucent.com (h135-250-11-33.lucent.com [135.250.11.33]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id o8FNaCWL010552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Sep 2010 18:36:15 -0500 (CDT) Received: from INBANSXCHHUB02.in.alcatel-lucent.com (inbansxchhub02.in.alcatel-lucent.com [135.250.12.35]) by inbansmailrelay2.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o8FNaAPq024880 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Sep 2010 05:06:11 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB02.in.alcatel-lucent.com ([135.250.12.35]) with mapi; Thu, 16 Sep 2010 05:06:10 +0530 From: "Bhatia, Manav (Manav)" To: Samuel Weiler , "ietf@ietf.org" , "secdir@ietf.org" , "draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org" Date: Thu, 16 Sep 2010 05:06:00 +0530 Thread-Topic: secdir review of draft-ietf-opsec-igp-crypto-requirements Thread-Index: ActVAcwvbKYGmY2tSU+0WYRYVYCeRgALFctw Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.com> References: 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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.33 X-Mailman-Approved-At: Fri, 17 Sep 2010 05:38:35 -0700 Subject: Re: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Sep 2010 23:36:23 -0000 Hi Samuel, Thanks for the review. =20 > Is there a way to present this information more compactly? I suggest=20 > a table with routing protocol on one axis, crypto suite on another,=20 > and requirement status in the elements (perhaps with a cite=20 > to the doc=20 > that sets the requirement). You might separely say "MANDATORY to=20 > implement, OPTIONAL to use, NOT SUGGESTED for use". This is precisely what we were doing till the OPSEC WG members asked us to = change the format to the current one. >=20 > You could also put suggestions and speculation about the=20 > future in the=20 > same table, though you may need to define some terms. And it=20 We were using extended 2119 terms like SHOULD+, MUST- and MAY+ originally a= nd these were again removed because of the strong consensus in the WG in fa= vor of the current text. > needs to=20 > be clear when this doc diverges from past ones or makes a new=20 > statement. I have not gone back through the previous docs to confirm=20 > that this doc isn't changing anything. >=20 > I see a whole bunch of lower case "may" and "should", and I'm=20 > wondering what to make of them. >=20 > In describing each routing protocol's authentication options,=20 > it would=20 > be helpful to say whether there's any in-band negotiation available.=20 I am not sure I understand whats being meant by in-band negotiation here? > If so, more needs to be said about that in the security=20 > considerations. If not, it should be documented here. >=20 > I don't need to hear three or four separate times that cleartext=20 > passwords are bad. Just making sure that folks don't miss this! :) >=20 > Minor: remove citations from the abstract (per rfc editor policy). Sure, will do. Cheers, Manav >=20 > -- Sam >=20 > = From weiler@watson.org Sun Sep 19 07:29:02 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62FE3A692F; Sun, 19 Sep 2010 07:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.957 X-Spam-Level: X-Spam-Status: No, score=-1.957 tagged_above=-999 required=5 tests=[AWL=0.642, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8fRwXqKvBNy; Sun, 19 Sep 2010 07:29:02 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 0983C3A68BF; Sun, 19 Sep 2010 07:29:01 -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 o8JETM6d064115; Sun, 19 Sep 2010 10:29:23 -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 o8JETMmh064110; Sun, 19 Sep 2010 10:29:22 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sun, 19 Sep 2010 10:29:22 -0400 (EDT) From: Samuel Weiler To: "Bhatia, Manav (Manav)" In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.com> Message-ID: References: <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.com> 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]); Sun, 19 Sep 2010 10:29:23 -0400 (EDT) Cc: "draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2010 14:29:03 -0000 On Thu, 16 Sep 2010, Bhatia, Manav (Manav) wrote: >> In describing each routing protocol's authentication options, it >> would be helpful to say whether there's any in-band negotiation >> available. > > I am not sure I understand whats being meant by in-band negotiation > here? Many protocols negotiate which crypto algorithm (or even more generic security mechanism) to use. Those negotiations, if done poorly, can be subject to downgrade attacks. Given how common security negotiation is, it's worthwhile to point out whether or not each of these protocols do it or whether they depend entirely on static configuration of each endpoint. -- Sam From d3e3e3@gmail.com Sun Sep 19 20:42:24 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3C4D3A6900; Sun, 19 Sep 2010 20:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.293 X-Spam-Level: X-Spam-Status: No, score=-102.293 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjAPfgVfZD2E; Sun, 19 Sep 2010 20:42:23 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 18AA23A686D; Sun, 19 Sep 2010 20:42:23 -0700 (PDT) Received: by gwb20 with SMTP id 20so1685558gwb.31 for ; Sun, 19 Sep 2010 20:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=kboJrnpN2+iJ5QpLojJi1iMHlCXZa7cMELLSVviAdZU=; b=VrrP39s0iohjLt3WBs8xeg5NuTBgtDbxlCJPS/aNQi/d7sqw4jGWwNPrwzixFu0Jib DsEPFAZvUP3vl0Xwcw9+Y4TVM6pEHJy80ykoGdLe2Sj6GixtRWj0NW1PHMqVaEPpFp4j k6clNySaex+Jk/f2Hj73COmiuy1q40xW1coNg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=wt2TwxQg6uDIMB7Tase1jOFNqIIZNQfTgr/SZ0oV9UvrD0cAoEgNMnRZACEQsl9341 nUW4MxkmQEo2sLHbpRzz81NqyOho5bvdl7WIXn5TXfptzmDGjAAJ3bVgTau//l6bnFzq 4pnPE1lMOrlQKitSQJe1YThOmF+uxsEDOeQ2A= MIME-Version: 1.0 Received: by 10.90.120.17 with SMTP id s17mr4932755agc.98.1284954164628; Sun, 19 Sep 2010 20:42:44 -0700 (PDT) Received: by 10.90.117.20 with HTTP; Sun, 19 Sep 2010 20:42:44 -0700 (PDT) Date: Sun, 19 Sep 2010 23:42:44 -0400 Message-ID: From: Donald Eastlake To: secdir@ietf.org, iesg@ietf.org, Ralph Droms , pthubert@cisco.com, Francis Dupont , Wassim.Haddad@ericsson.com, cjbc@it.uc3m.es, julienl@qualcomm.com, marcelo@it.uc3m.es Content-Type: text/plain; charset=ISO-8859-1 Subject: [secdir] draft-ietf-mext-nemo-pd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 03:42:24 -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. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies how to delegate IPv6 prefixes to a Mobile Router in a Mobile Network. It has a reasonably extensive Security Considerations section and appears to appropriately specify protective measures against plausible threats. In particular, when the Mobile Router is away from home, it mandates the use of IPsec a la MIPv6. Possibly someone more familiar with IPsec should look at the specified Security Policy Database and Security Association Database. Trivia: Section 3.1, page 5, "...currently used by the is about to expire..." ? perhaps "...by the Mobile Node..." "an Mobile" -> "a Mobile" Various acronyms, such as BU, HoA, while usually explained when first used, are missing from Section 2. HoA is not explained at all. Even better would be to vastly reduce the overuse of acronyms throughout this document. Thanks, Donald From vincent.roca@inrialpes.fr Mon Sep 20 06:49:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8313A6925; Mon, 20 Sep 2010 06:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.505 X-Spam-Level: X-Spam-Status: No, score=-5.505 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RL6-l92JRjWj; Mon, 20 Sep 2010 06:49:21 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id 9B6143A68E3; Mon, 20 Sep 2010 06:49:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.56,393,1280700000"; d="scan'208";a="67955289" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 20 Sep 2010 15:49:41 +0200 Message-ID: <4C976675.2060302@inrialpes.fr> Date: Mon, 20 Sep 2010 15:49:41 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: IESG , secdir@ietf.org, draft-ietf-fecframe-framework.all@tools.ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [secdir] SecDir review of draft-ietf-fecframe-framework-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Sep 2010 13:49:22 -0000 Mark, all, 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. (NB: to make it clear, I've been randomly selected to review this document, I didn't ask) Main comments: -------------- 1) As a general comment, having a sound, detailed security section in this FECFRAME framework document is critical since this document is referred by all the WG documents and all of them inherit the framework recommendations. From this point of view, the current security discussion is not satisfying IMHO. If we further compare this FECFRAME/framework section to the similar section in the ALC, Flute and NORM RFC (those RMT protocols share some similarities in terms of security requirements), we see major difference in terms of completeness of the discussion. 2) There is no "Minimum security requirement". More precisely this document does not identify a mandatory to implement (but not necessarily to use) security configuration. I think this also applies here. IPsec/ESP is usually a good solution for that... Additional comments: -------------------- I'm okay with the first two paragraphs. Then: 3) I'd like to see a discussion which differentiates the various security requirements of interest: - security WRT the data flow itself, which essentially concerns the content provider; - security WRT the FECFRAME system, which essentially concerns the sending and receiving hosts; - security WRT the network, in the sense "additional risks that the use of FECFRAME may create for the network", which of course concerns all the hosts; The goal of this section is not to solve all these issues but to highlight the risks, the gradation in the risks, and to give some directions on how to mitigate them (or solve them if feasible). 4) paragraph 3 has been largely improved compared to previous versions, however I still find the discussion confusing. So I suggest another organization: - if integrity protection is required, using it above FECFRAME, at the ADU level, is operational since all corrupted ADUs are finally detected as such. But of course there are limits (e.g. DoS as already explained). - if integrity protection is required, using it below FECFRAME has the advantage of reducing DoS risks. This is therefore RECOMMENDED. - however when applied below FECFRAME, this integrity service will not necessarily be end-to-end (depends on how FECFRAME is used, end-to-end or not). Whether it's appropriate or not depends on whether one can tell where the security threats are (which is use-case dependent). BTW: use the "ADU"/"ADU flow" rather than "source packets" to be in-line with the agreed terminology. 5) paragraph 4: I don't like the discussion here. The same comment on resource waste can be made with non encrypted flows. Concerning the second comment of this paragraph, it's clear that giving a copy of plaintext repair packets to non authorized receivers will lead to problems, but is it so different than giving a copy of plaintext source packets? When we say that confidentiality protection is applied after FEC encoding, this is for instance within IPsec, i.e. all source/repair FEC packets are encrypted. That's the assumption (paragraph 2). I suggest to change this discussion as follows: - when ADU flows with different security requirements need to be FEC protected jointly, then each flow MAY be processed appropriately before entering FECFRAME e.g. to encrypt it. (Note that this is not a MUST. E.g. there are situations where the only insecure domain is the one over which FECFRAME operates => this situation may be addressed with IPsec/ESP, for the whole flow) - it is then REQUIRED that the FECFRAME aggregate flow be in line with the maximum security requirements of the individual ADU flows. E.g. if DoS protection is required, since the use of FECFRAME must not add any additional threat, an integrity protection must be provided below FECFRAME. - generally speaking it is often RECOMMENDED to avoid FEC protecting flows with largely different security requirements. 6) A note should be added to highlight the fact that attacks targeting the congestion control building block (when applicable) may severely damage the network. A pointer to section 8 should be added. 7) It should be noted that certain security transforms will add some latency to the ADU flow delivery. This latency may need to be considered when dealing with real-time flows. NB: I don't think ciphering is an issue, but TESLA authentication/integrity will probably not be appropriate! There are other similar examples. Regards, Vincent From manav.bhatia@alcatel-lucent.com Sun Sep 19 10:42:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0003A67F1; Sun, 19 Sep 2010 10:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.244 X-Spam-Level: X-Spam-Status: No, score=-2.244 tagged_above=-999 required=5 tests=[AWL=0.355, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OddEoOlN-J5l; Sun, 19 Sep 2010 10:42:19 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by core3.amsl.com (Postfix) with ESMTP id 031383A672F; Sun, 19 Sep 2010 10:41:43 -0700 (PDT) Received: from inbansmailrelay1.in.alcatel-lucent.com (h135-250-11-31.lucent.com [135.250.11.31]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id o8JHg4u0000967 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 19 Sep 2010 12:42:06 -0500 (CDT) Received: from INBANSXCHHUB01.in.alcatel-lucent.com (inbansxchhub01.in.alcatel-lucent.com [135.250.12.32]) by inbansmailrelay1.in.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id o8JHg1lF010717 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 19 Sep 2010 23:12:03 +0530 Received: from INBANSXCHMBSA1.in.alcatel-lucent.com ([135.250.12.56]) by INBANSXCHHUB01.in.alcatel-lucent.com ([135.250.12.32]) with mapi; Sun, 19 Sep 2010 23:12:01 +0530 From: "Bhatia, Manav (Manav)" To: Samuel Weiler Date: Sun, 19 Sep 2010 23:12:01 +0530 Thread-Topic: secdir review of draft-ietf-opsec-igp-crypto-requirements Thread-Index: ActYBxHLvIX1HJ+IQY6vf1PisXqvFgAGqdxg Message-ID: <7C362EEF9C7896468B36C9B79200D8350CF3BD6026@INBANSXCHMBSA1.in.alcatel-lucent.com> References: <7C362EEF9C7896468B36C9B79200D8350CF3916707@INBANSXCHMBSA1.in.alcatel-lucent.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 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.250.11.31 X-Mailman-Approved-At: Tue, 21 Sep 2010 06:35:20 -0700 Cc: "draft-ietf-opsec-igp-crypto-requirements.all@tools.ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-opsec-igp-crypto-requirements X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Sep 2010 17:42:21 -0000 > > > > I am not sure I understand whats being meant by in-band negotiation=20 > > here? >=20 > Many protocols negotiate which crypto algorithm (or even more generic=20 > security mechanism) to use. Those negotiations, if done poorly, can=20 > be subject to downgrade attacks. >=20 > Given how common security negotiation is, it's worthwhile to=20 > point out=20 > whether or not each of these protocols do it or whether they depend=20 > entirely on static configuration of each endpoint. All the protocols covered in this document provide the Key ID that's carrie= d in the protocol packets that's used by the receiving end to authenticate = the packet. So there is no exchange of crypto algorithms, etc that's done. = We can mention this in the next revision. Cheers, Manav >=20 > -- Sam > = From Nicolas.Williams@oracle.com Tue Sep 21 15:40:00 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE2B3A6847 for ; Tue, 21 Sep 2010 15:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3nlCtLIxQXah for ; Tue, 21 Sep 2010 15:39:49 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 086E83A6782 for ; Tue, 21 Sep 2010 15:39:48 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8LMeAqE004420 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 21 Sep 2010 22:40:12 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8LLOEEj000646; Tue, 21 Sep 2010 22:40:10 GMT Received: from abhmt008.oracle.com by acsmt355.oracle.com with ESMTP id 618745391285108732; Tue, 21 Sep 2010 15:38:52 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 21 Sep 2010 15:38:51 -0700 Date: Tue, 21 Sep 2010 17:38:47 -0500 From: Nicolas Williams To: secdir@ietf.org, watsonm@netflix.com Message-ID: <20100921223846.GT7857@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2010-03-02) Subject: [secdir] Secdir review of draft-ietf-fecframe-sdp-elements-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2010 22:40:00 -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 deals with the encoding of FEC parameters in SDP for unicast and multicast of video and other media. Modulo the COMMENTs and DISCUSSes on the datatracker, I believe this document is ready for publication. Its security considerations section appears to me to be complete. I do have one minor comment regarding this text: 5.1. Declarative Considerations In multicast-based applications, the FEC Framework Configuration Information pertaining to all FEC protection options available at the sender MAY be advertised to the receivers as a part of a session announcement. This way, the sender can let the receivers know all available options for FEC protection. Based on their needs, the receivers MAY choose protection provided by one or more FEC Framework instances and subscribe to the respective multicast session(s) to receive the repair flow(s). Unless explicitly required by the CDP, --> the receivers SHOULD NOT send an answer back to the sender specifying their choices since this can easily overwhelm the sender particularly in large-scale multicast applications. Why not "MUST NOT" instead of "SHOULD NOT"? When would a receiver ever want to send an answer back to a multicast sender? Nico -- From christer.holmberg@ericsson.com Wed Sep 22 02:25:57 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7903A6AEB; Wed, 22 Sep 2010 02:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.839 X-Spam-Level: X-Spam-Status: No, score=-5.839 tagged_above=-999 required=5 tests=[AWL=0.760, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9m4MbED1hdE; Wed, 22 Sep 2010 02:25:56 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 49D533A6AE7; Wed, 22 Sep 2010 02:25:54 -0700 (PDT) X-AuditID: c1b4fb39-b7b0bae000000f9a-46-4c99cbbc89d5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 1D.56.03994.CBBC99C4; Wed, 22 Sep 2010 11:26:20 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.78]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 22 Sep 2010 11:26:20 +0200 From: Christer Holmberg To: Ben Campbell , Cullen Jennings , "draft-ietf-simple-msrp-sessmatch@tools.ietf.org" , Ted Hardie , "secdir@ietf.org" , IESG IESG , The IETF Date: Wed, 22 Sep 2010 11:26:18 +0200 Thread-Topic: Draft new version: draft-ietf-simple-msrp-sessmatch [was: secdir review of draft-ietf-simple-msrp-sessmatch] Thread-Index: ActPo1ki8jw9pVdrTjKfKNpVEucoawASmCuwApJ610A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585017385E2@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585015BCA1D@ESESSCMS0356.eemea.ericsson.se> , <7F2072F1E0DE894DA4B517B93C6A0585015BCA41@ESESSCMS0356.eemea.ericsson.se> <7DA8DA86-792B-44A4-A1AD-8DD6DF3FA985@estacado.net> <7F2072F1E0DE894DA4B517B93C6A05850169444B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850169444B@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: [secdir] Draft new version: draft-ietf-simple-msrp-sessmatch [was: secdir review of draft-ietf-simple-msrp-sessmatch] X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 09:25:57 -0000 =20 Hi, Based on the secdir comments/discussions regarding sessmatch, we have submi= tted a new version of the draft (-07). The major changes are: - It is clarified that the MSRP URI comparison rules are not changed, and t= hat the rules are not used for session matching - It is clarified that the draft does not change the TLS authentication mec= hanisms, and that there are some existing usage restrictions that the draft= does not solve. Regards, Christer From gwz@net-zen.net Wed Sep 22 02:27:41 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47B0B3A6AF6 for ; Wed, 22 Sep 2010 02:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.104 X-Spam-Level: X-Spam-Status: No, score=-102.104 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ahoEY8lveyvF for ; Wed, 22 Sep 2010 02:27:33 -0700 (PDT) Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 509BE3A6AEB for ; Wed, 22 Sep 2010 02:27:33 -0700 (PDT) Received: (qmail 5593 invoked from network); 22 Sep 2010 09:27:59 -0000 Received: from unknown (110.164.147.175) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 22 Sep 2010 09:27:50 -0000 From: "Glen Zorn" To: , , , , "'Tim Polk'" Date: Wed, 22 Sep 2010 16:27:11 +0700 Organization: Network Zen Message-ID: <002801cb5a38$5db4f5c0$191ee140$@net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01CB5A73.0A13CDC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActaOFVRLTmiVrU2Qw28WkPSr1be4A== Content-Language: en-us Subject: [secdir] secdir review of draft-cakulev-mikey-ibake-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 09:27:41 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0029_01CB5A73.0A13CDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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. Editorial Comments General . Articles are missing in a large number of places (too many to specify and correct one-by-one here). For example, "The REQUEST_KEY_INIT message includes Initiator's public identity" which should, presupposing that "Initiator" is not a proper noun, read "The REQUEST_KEY_INIT message includes the Initiator's public identity". Other examples are given below; please correct. Abstract . s/relies on trusted key management service/relies on a trusted key management service/ Section 1 Paragraph 1 . s/Multimedia Internet Keying (MIKEY) [RFC3830] specification/The Multimedia Internet Keying (MIKEY) [RFC3830] specification/ . The last sentence doesn't make a lot of sense to me; suggest changing "Following MIKEY specification, multiple extensions of MIKEY have been specified such as [RFC4650] and [RFC4738]." to "Multiple extensions of MIKEY have been defined, such as HMAC-Authenticated Diffie-Hellman [RFC4650] and MIKEY-RSA-R [RFC4738]." Paragraph 2 . s/key management services will have to be online/such key management services would have to be online/ . The statement that "In some applications, this architecture creates a huge burden on operators to install, and manage these boxes." seems to be unnecessarily evangelistic; suggest deleting it. . I don't know what "operational discomfort on the part of end-users" means. Paragraph 3 . Suggest changing the first sentence to read "This document describes a solution in which the KMS are provided by low availability." . s/identity based/identity-based/ . s/in the date field, is/in the date field is/ . Suggest changing "for a whole month (more generally subscription cycle) at the beginning of a subscription cycle." to "for a whole subscription cycle at the beginning of the cycle." Section 2 . It's not clear why "Definitions and Notation" and "Abbreviations" are sub-sections of "Requirements notation". Suggest that Section 2 be re-titled as "Terminology", with "Requirements Language", "Definitions and Notation" and "Abbreviations" as sub-sections. . s/IBE framework is defined in/The IBE framework is defined in/ . I'm continually amazed by the apparent inability of people who presumably work with objects and pointers thereto to distinguish between a reference and the document to which it refers. [RFC5091] is a pointer; it does not define anything, let alone the IBE framework. . s/Identity Based/Identity-based/g . Add definitions of TGK and TEK to the list of abbreviations. Section 3.2 . It's not clear that "call" and "session" are the same thing. Suggest changing "redirect the call to a different destination" to "redirect the session to a different destination" for the sake of clarity and consistency. . The acronym "IMS" is used w/o being previously defined; suggest adding an entry for IMS to the "Abbreviations" section. Section 4.1 . In the second paragraph, "Key Management Services" is plural but seems to generally referred to in the singular. As an example, how should one read "KMSs"? "Key Management Serviceses"? Suggest s/Key Management Services/Key Management Service/G . Correct grammar: Change "The Initiator and the Responder do not share any credentials, however the Initiator knows Responder's public identity. Below, description of how private keys are obtained using MIKEY messages is provided. Alternative way" to "The Initiator and Responder do not share any credentials; however, the Initiator knows the Responder's public identity. Below, a description of how private keys are obtained using MIKEY messages is provided. An alternative way" Section 4.2.1 . In the first paragraph, s/the user have pre-shared credentials/the user has pre-shared credentials Section 4.2.1.1.1 . s/[RFC3830] Section 4.1.4/Section 4.1.4 of RFC 3830/ Section 4.2.1.1.2 . The first sentence makes no sense. . In the second paragraph, s/PKE payload/The PKE payload/ Section 4.2.1.2 . The second sentence of the first paragraph says "In case of a REQUEST_KEY_INIT_PKE message, the KMS MUST ensure that the IDcert is equal to the identity specified in the certificate." My guess is that IDcert should actually be IDRi here, since IDcert occurs nowhere else in the draft. Section 4.2.2 . s/key mode ,/key mode,/ Technical Comments General . The fourth paragraph of Section 4.1 (and elsewhere) says 'If the Initiator is authorized to make the request' but the criteria for this authorization decision don't seem to be specified anywhere in the document. Since this decision is vital to the successful operation of the protocol, I think it would be nice if the authors gave readers a clue as to how to go about making it. Section 4.1 . The first sentence of paragraph 4 contains rather confusing notation. It says "The Initiator next chooses a random x and computes xP (i.e. adds P to itself x times), where P is a point on elliptic curve E known to all users." The notation "xP" is a conventional one for expressing the multiplication of P by x, which is not the same as the addition of P to itself x times. If the latter interpretation is actually, I think that a better notation should be chosen. Section 4.2.1.1 . The last sentence says "The KEMAC payload SHOULD be used only when the user needs to use specific keys. Otherwise, this payload SHALL not be used." This appears to be self-contradictory, since "SHOULD" allows the usage under certain circumstances while "SHALL NOT" (note typo) absolutely forbids it. Section 4.2.1.2 . The last paragraph says "If the KMS cannot correctly parse the received message, or the user is not authorized to receive the requested Private Keys, the KMS SHOULD send an appropriate Error message." I'm assuming that the term "Error message" here is referring to the Error payload defined in section 6.12 of RFC 3830, but I don't see any Error no values therein that seem appropriate for either of the listed conditions. ------=_NextPart_000_0029_01CB5A73.0A13CDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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.

 

=

Editorial Comments

 

General

·         Articles are missing in a large number of places (too many to specify and correct one-by-one here).  For example, “The REQUEST_KEY_INIT = message includes Initiator’s public identity” which should, = presupposing that “Initiator” is not a proper noun, read =  “The REQUEST_KEY_INIT message includes the Initiator’s public identity”.  Other examples are given below; please = correct.

 

Abstract

·         s/relies = on trusted key management service/relies on a trusted key management = service/

 

Section 1

Paragraph = 1

·         s/Multimedia Internet Keying (MIKEY) [RFC3830] specification/The Multimedia Internet = Keying (MIKEY) [RFC3830] specification/

·         The last = sentence doesn’t make a lot of sense to me; suggest changing = “Following MIKEY specification, multiple  extensions of MIKEY have been = specified such as [RFC4650] and  [RFC4738].” to “Multiple = extensions of MIKEY have been defined, such as HMAC-Authenticated Diffie-Hellman = [RFC4650] and MIKEY-RSA-R [RFC4738].”

Paragraph = 2

·         s/key = management services will have to be online/such key management services would have = to be online/

·         The = statement that “In some applications, this architecture creates a huge = burden on operators to install, and manage these boxes.” seems to be = unnecessarily evangelistic; suggest deleting it.

·         I = don’t know what “operational discomfort on the part of end-users” = means.

Paragraph = 3

·         Suggest changing the first sentence to = read “This document describes a solution in which the KMS are provided = by low availability…”

·         s/identity = based/identity-based/

·         s/in the date field, is/in the date field = is/

·         Suggest changing “for a whole month = (more generally subscription cycle) at the beginning of a subscription = cycle.” to “for a whole subscription cycle at the beginning of the = cycle.”

 

Section 2

·         It’s not clear why = “Definitions and Notation” and “Abbreviations” are sub-sections of “Requirements notation”.   Suggest that Section 2 = be re-titled as “Terminology”, with “Requirements Language”, “Definitions and Notation” and “Abbreviations” as sub-sections.

·         s/IBE framework is defined in/The IBE = framework is defined in/

·         I’m continually amazed by the = apparent inability of people who presumably work with objects and pointers = thereto to distinguish between a reference and the document to which it = refers.  [RFC5091] is a pointer; it does not define anything, let alone = the IBE framework.

·         s/Identity Based/Identity-based/g

·         Add definitions of TGK and TEK to the = list of abbreviations.

 

Section 3.2

·         It’s not clear that = “call” and “session” are the same thing.  Suggest changing “redirect the call to a different destination” to = “redirect the session to a different destination” for the sake of clarity = and consistency.

·         The acronym “IMS” is used w/o = being previously defined; suggest adding an entry for IMS to the = “Abbreviations” section.

 

Section 4.1

·         In the second paragraph, “Key = Management Services” is plural but seems to generally referred to in the singular.  As an example, how should one read “KMSs”? “Key Management Serviceses”?  Suggest s/Key Management Services/Key Management Service/G

·         Correct grammar: Change “The = Initiator and the Responder do not share any credentials, however the Initiator knows Responder's public identity.  Below, description of how private = keys are obtained using MIKEY messages is provided.  Alternative way” = to “The Initiator and Responder do not share any credentials; = however, the Initiator knows the Responder's public identity.  Below, a = description of how private keys are obtained using MIKEY messages is provided.  An = alternative way”

 

Section 4.2.1

·         In the first paragraph, s/the user have pre-shared credentials/the user has pre-shared = credentials

 

Section 4.2.1.1.1

·         s/[RFC3830] Section 4.1.4/Section 4.1.4 = of RFC 3830/

 

Section 4.2.1.1.2

·         The first sentence makes no = sense.

·         In the second paragraph, s/PKE = payload/The PKE payload/

 

Section 4.2.1.2

·         The second sentence of the first = paragraph says “In case of a REQUEST_KEY_INIT_PKE message, the KMS MUST ensure that the = IDcert is equal to the identity specified in the certificate.”  My = guess is that IDcert should actually be IDRi here, since IDcert occurs nowhere = else in the draft.

 

Section 4.2.2

·         s/key mode ,/key mode,/

 

 

Technical Comments

 

General

·         The fourth paragraph of Section 4.1 (and elsewhere) says ‘If the Initiator is authorized to make the request’ but the criteria for this authorization decision = don’t seem to be specified anywhere in the document.  Since this decision = is vital to the successful operation of the protocol, I think it would be nice if = the authors gave readers a clue as to how to go about making it.  =

 

Section 4.1

·         The first sentence of paragraph 4 = contains rather confusing notation.  It says “The Initiator next = chooses a random x and computes xP (i.e. adds P to itself x times), where P is a = point on elliptic curve E known to all users.”  The notation = “xP” is a conventional one for expressing the multiplication of P by x, which = is not the same as the addition of P to itself x times.  If the latter interpretation is actually, I think that a better notation should be = chosen.

 

Section 4.2.1.1

·         The last sentence says “The KEMAC = payload SHOULD be used only when the user needs to use specific keys.  = Otherwise, this payload SHALL not be used.”  This appears to be self-contradictory, since “SHOULD” allows the usage under = certain circumstances while “SHALL NOT” (note typo) absolutely = forbids it.

 

Section 4.2.1.2

·         The last paragraph says “If the KMS = cannot correctly parse the received message, or the user is not authorized to = receive the requested Private Keys, the KMS SHOULD send an appropriate Error = message.”  I’m assuming that the term “Error message” here is = referring to the Error payload defined in section 6.12 of RFC 3830, but I = don’t see any Error no values therein that seem appropriate for either of the = listed conditions.

 

------=_NextPart_000_0029_01CB5A73.0A13CDC0-- From william.polk@nist.gov Wed Sep 22 06:23:07 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BCF13A69DA; Wed, 22 Sep 2010 06:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R7KPz4hp0eoP; Wed, 22 Sep 2010 06:23:06 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id A13833A69C9; Wed, 22 Sep 2010 06:23:05 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (WSXGHUB1.xchange.nist.gov [129.6.18.96]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id o8MDN5L2024652; Wed, 22 Sep 2010 09:23:06 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::41df:f63f:c718:e08]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 22 Sep 2010 09:23:05 -0400 From: "Polk, William T." To: Fernando Gont , Dave Cridland Date: Wed, 22 Sep 2010 09:23:03 -0400 Thread-Topic: SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06 Thread-Index: ActVeWYs8zn5Bzk5TdCwDvjeBWZXwwE3+Kfw Message-ID: In-Reply-To: <4C91C9EE.1000200@gont.com.ar> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: william.polk@nist.gov Cc: "draft-ietf-tcpm-urgent-data.all@tools.ietf.org" , Apps Area Review List , The IESG , Security Area Directorate Subject: Re: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 13:23:07 -0000 Hi Fernando, My comments inline, text pruned to those issues I am responding to... On 9/16/10 3:40 AM, "Fernando Gont" wrote: =20 >> The TCP urgent mechanism, as implemented, means that a single octet is >> lost when the receiver handles the last "Urgent" data section. Thus >> particularly when multiple urgent data segments are "in flight", it >> becomes difficult to guess which octets will be lost by the receiver. >> The SeolMa attack effectively uses these lost octets to pad strings used >> in TCP based application protocols, thus defeating na=EFve NIDS pattern >> matching. >>=20 >> There is no discussion in the draft about SeolMa, indeed there isn't >> even a mention of it in the Security Considerations. >=20 > The security considerations does mention the problem of NIDS-evasion, > although it only focuses on the semantics of the UP (but does not > consider the OOB vs. in-band thing). Would re-writing the SecCons as > follows address this point?: >=20 > ---- cut here ---- > Multiple factors can affect the data flow that is actually delivered to > an application when the TCP urgent mechanism is employed; namely, the > two possible interpretations of the semantics of the Urgent Pointer in > current implementations (e.g., depending on the value of the tcp_stdurg > sysctl), the possible implementation of the urgent mechanism as an > Out-Of-Band (OOB) facility (vs. in-band as intenteded by the IETF > specifications), and middle-boxes (such as packet scrubbers) or the > end-systems themselves that could cause the "urgent data" to be > processed "in band". This might make it difficult for a Network > Intrusion Detection System (NIDS) to track the application-layer data > transferred to the destination system, and thus lead to false negatives > or false positives in the NIDS [CPNI-TCP] [phrack]. > ---- cut here ---- >=20 I think this is a helpful change. >=20 >> It's not clear to >> me if the recommendation to use SO_OOBINLINE would have an effect here - >> my gut feeling is that it would defeat SeolMa by making these "lost" >> octets part of the normal data flow again. >=20 > This wouldn't help for the challenge that NIDS face. This just helps in > terms of interoperability: i.e., applications should still work if those > "urgent data" are delivered in-band (whether because of setting > SO_OOBINLINE or because a packet scrubber cleared the URG bit). >=20 >=20 >=20 >> Cisco's solution relies on simply forcing urgent data to be non-urgent, >> which will have knock-on effects on TELNET and FTP by default. It's not >> clear to me from this document (including reading the references) >=20 > How about if I replace this sentence of the SecCons: >=20 > ---- cut here ---- > However, this > might cause interoperability problems or undesired behavior in the > applications running on top of TCP. > ---- cut here ---- >=20 > with this one: >=20 > ---- cut here ---- > However, this might cause interoperability problems or undesired > behavior in those applications that rely on the TCP urgent mechanism, > such as Telner [telnet] and FTP [ftp] > ---- cut here ---- >=20 > ? I think this is also a helpful change. >=20 >=20 >> Specific Recommendations: >>=20 >> - An informative reference to FTP and TELNET, noting how and why the URG >> pointer is used, would make it more obvious what is lost here. >=20 > Would the re-written text I indicated above do, or do you think we > should get into the specifics of what the urgent mechanism is used for > in FTP and telnet? >=20 >=20 It might be worth highlight FTP and TELNET in Section 5, since these are evidently common applications that use the urgent data feature. >=20 >> - A more detailed description of SeolMa, and its implications, would be >> useful, and I think required in the Security Considerations section. >=20 > Please let me know if the change indicated above would do. >=20 >=20 >> - I feel that further consideration of the proposed solution to SeolMa >> is warranted. >=20 > You mean what we propose to fix this NIDS evasion technique? >=20 At a minimum, I think the implications of this document and any impact on SeolMa are needed to complete the security considerations section. > Thanks! >=20 > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 >=20 >=20 >=20 >=20 >=20 Thanks, Tim From barryleiba@gmail.com Wed Sep 22 09:34:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6651E3A69CA; Wed, 22 Sep 2010 09:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.868 X-Spam-Level: X-Spam-Status: No, score=-2.868 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1lQUfhiQqla; Wed, 22 Sep 2010 09:34:23 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 609F43A6900; Wed, 22 Sep 2010 09:34:23 -0700 (PDT) Received: by gya1 with SMTP id 1so2089gya.31 for ; Wed, 22 Sep 2010 09:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=+COdUx65lKGmMyU4EmpsPQmZQuFbOIB4l81+6dA7Mbg=; b=B4t2onz7GT8Nf5QGYObGs2yY4/h6PJwj88DrvmtGtSD29j5o9hmtlv/b04ZeMzHgUQ g42ZMXgzWG0wQiLqgvkn5eaPLugqu00RW0aL0VMED205uq2YKdjCoBLhXlNOkmC+MIx0 A3mxZ56DonCupjYZ4oWOaxC5S0Xthy20+gDjM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tmktZyA3BwO/yYq4VxKdvPRM16+pSgfhE2IzaaolAbZBHog/v6AO9U43VyL/IOMnvl LlxD4TRasPoWQKJXDDPGkQPq+M8sRBnUAXjmEFC4Wtvq6RQNq2qLQEowxpN3sLg4BlyV e390dJltidgfcqzDBxZjHFcxYOr5rAquNKUGg= MIME-Version: 1.0 Received: by 10.150.217.9 with SMTP id p9mr1441203ybg.80.1285173290320; Wed, 22 Sep 2010 09:34:50 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.199.66 with HTTP; Wed, 22 Sep 2010 09:34:50 -0700 (PDT) In-Reply-To: <4C9A27D0.7030909@stpeter.im> References: <4C9A27D0.7030909@stpeter.im> Date: Wed, 22 Sep 2010 12:34:50 -0400 X-Google-Sender-Auth: kupZ6sAWANBwT_q5CpOlf5olsQ4 Message-ID: From: Barry Leiba To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF discussion list , IETF cert-based identity , tls@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 16:34:26 -0000 Hi, Peter. Thanks for the response, and I'm very happy with nearly all the changes you've adopted. I'll not quote and comment on it all, except to make the general statement: Great work! >> I'd also like to take the security note from section 4.3 and echo it >> here. =A0So maybe this?: >> >> << The list SHOULD NOT include a CN-ID. =A0If a CN-ID is used despite >> this advice, it MUST be constructed only from the source domain and >> never from a target domain. =A0Further, it MUST NOT be used unless there >> are no other supported identifiers present in the certificate. >> > > The last sentence does not apply in Section 4.2, because that section > concerns construction of the list of reference identifiers and as stated > above the client needs to do so without being influenced by the contents > of the certificate presented by the server. I see your point, and I agree. Still, it might be useful at this point to explain WHY the list SHOULD NOT include a CN-ID. I'll leave it there, with no further argument... it's certainly explained later, so perhaps that's good enough, and there's no reason to spend further time on this here. > Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if"). > Jeff is a bit uncomfortable with that because CN-ID is such a common > practice, but I'm comfortable with it because of the hypothetical nature > of the recommendation. He will review the earlier discussions on this > topic before we finalize that text. I agree with you, Peter: I think the text is fine as you've given it. > The part of the text that you have not quoted does say that this > practice is typically offered only to advanced users (and I don't think > that Barry's mother counts as an advanced user). True; I'd missed that point, and I'm happy with the newer, scarier text. The only point I still want to push on is this one: >> =A0 =A0When the connecting application is an interactive client, the sou= rce >> =A0 =A0domain name and service type MUST be provided by a human user (e.= g. >> =A0 =A0when specifying the server portion of the user's account name on = the >> =A0 =A0server or when explicitly configuring the client to connect to a >> =A0 =A0particular host or URI as in [SIP-LOC]) and MUST NOT be derived f= rom >> =A0 =A0the user inputs in an automated fashion (e.g., a host name or dom= ain >> =A0 =A0name discovered through DNS resolution of the source domain). =A0= This >> =A0 =A0rule is important because only a match between the user inputs (i= n >> =A0 =A0the form of a reference identifier) and a presented identifier >> =A0 =A0enables the client to be sure that the certificate can legitimate= ly >> =A0 =A0be used to secure the connection. >> >> Does this mean that a client specifically designed for the "gumbo" >> service can't automatically use the service type "gumbo", without the >> user's involvement? =A0Or that a client put out by example.net can't >> assume a host name of services.example.net in the absence of user >> input that says otherwise? > > IMHO that is a matter of user configuration, or user acknowledgement of > a service agreement, so it falls under the text in this I-D about > allowing the client to check the certificate against a DNS domain name > that is explicitly associated with the source domain by means of user > configuration. > >> Further, it's entirely reasonable for a program to have a user enter >> something like "gmail", and have the client turn that into something >> like "mail.google.com", deriving it from the user's input in an >> automated fashion. =A0Do we really want to forbid that sort of thing? > > Yes, we do, because although you happen to "just know" that > mail.google.com is a legitimate DNS domain name to connect to when > interacting with the gmail.com service, Barry's mother might not have > that kind of knowledge and as a general rule it's a very bad idea to > assume that it's just fine to connect to some domain at foo.com when > interacting with a service at bar.com. However, service delegation is a > difficult topic and there are ongoing discussions among various IETF > participants about how to do service delegation securely; one thing I > think we can safely say is that it's not the task of this I-D to solve > the problem of secure service delegation. There's a distinction, here, between a protocol and a user interface for configuration. My mother doesn't know whom to trust, except that she knows that she (at least kinda-sorta) trusts the mail program she's decided to use, and an entity she calls "gmail" (not "google.com", not "gmail.com", but just "gmail"). She's relying to the mail program's "easy configuration feature" to sort this out. The text I reviewed appeared to be saying normative things about what client software MUST and MUST NOT do with regard to this sort of configuration situation, which goes well beyond what the client software is doing on the wire. Unless I'm mis-reading it, it's explicitly saying that my client software is not allowed to do something like this, for example: 1. Ask the user, "What email service do you use?" 2. Receive the answer "gmail" from the user. 3. Auto-configure itself for the known gmail servers based only on that user input. If I am, indeed, misreading it, please tell me... and perhaps tweak the wording to make it less likely that someone else will misread it the same way. Again, this is my only remaining quibble with the document, and, again, it's a very good piece of work. Barry From jhutz@cmu.edu Wed Sep 22 11:07:04 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 191993A67D4; Wed, 22 Sep 2010 11:07:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvcP5ctfuFE6; Wed, 22 Sep 2010 11:07:03 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (SMTP03.SRV.CS.CMU.EDU [128.2.217.198]) by core3.amsl.com (Postfix) with ESMTP id D2D9B3A6A70; Wed, 22 Sep 2010 11:07:02 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8MI7SjV015791 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 14:07:28 -0400 (EDT) Date: Wed, 22 Sep 2010 14:07:28 -0400 From: Jeffrey Hutzelman To: Peter Saint-Andre Message-ID: <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu> In-Reply-To: <4C9A428C.2030807@stpeter.im> References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> <4C9A428C.2030807@stpeter.im> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.198 Cc: secdir@ietf.org, IETF cert-based identity , tls@ietf.org, iesg@ietf.org, barryleiba@computer.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:07:04 -0000 --On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre wrote: >> The second issue is the advice that the user should be allowed to accept >> a certificate with a mismatched name only on a temporary basis. This is >> almost certain to be the wrong thing to do; if a name mismatch is >> acceptable, it's also not likely to change anytime soon, and requiring >> the user to accept the certificate again in a later session just because >> the client has restarted is just annoying with no security benefit. > > That's an interesting point. In feedback we received from implementers > of interactive user agents (most browsers), we heard that at least some > user agents do enforce a distinction between accepting an identity > mismatch temporarily and accepting it permenantly. The security > properties of that distinction did not come up in previous mailing list > threads about this I-D, but your editorial team will do a bit more > research and might return with proposed text changes. I have no issue with making that distinction, and indeed, many existing user agents do so. I take issue only with the argument that user agents should disallow the "permanent" option in the name of "security", when doing so is in fact counterproductive. >> I think the advice in this paragraph is a little over-restrictive. What >> should be prohibited is not automated rewriting, but automated rewriting >> based on the use of insecure sources. RFC4120 has the following to say >> on this subject, as it relates to Kerberos: >> >> >> One can also rely on trusted third parties to make this >> determination, but only when the data obtained from the third party >> is suitably integrity-protected while resident on the third-party >> server and when transmitted. Thus, for example, one should not rely >> on an unprotected DNS record to map a host alias to the primary name >> of a server, accepting the primary name as the party that one intends >> to contact, since an attacker can modify the mapping and impersonate >> the party. > > Thanks for the pointer to RFC 4120. We're looking into how to > appropriate reference that in the next version of this spec. I'm not sure a reference is the best approach, since in fact we're not talking here about Kerberos and that might just be confusing. But borrowing some of the language might be appropriate. -- Jeff From jhutz@cmu.edu Wed Sep 22 11:13:43 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADA9028C126; Wed, 22 Sep 2010 11:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.543 X-Spam-Level: X-Spam-Status: No, score=-106.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zT1SpgyfQVLa; Wed, 22 Sep 2010 11:13:40 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (SMTP02.SRV.CS.CMU.EDU [128.2.217.197]) by core3.amsl.com (Postfix) with ESMTP id 2649728C121; Wed, 22 Sep 2010 11:13:40 -0700 (PDT) Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o8MIE1nW000952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Sep 2010 14:14:01 -0400 (EDT) Date: Wed, 22 Sep 2010 14:14:01 -0400 From: Jeffrey Hutzelman To: Barry Leiba , Peter Saint-Andre Message-ID: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> In-Reply-To: <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> X-Mailer: Mulberry/4.0.8 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Scanned-By: mimedefang-cmuscs on 128.2.217.197 Cc: secdir@ietf.org, IETF cert-based identity , IETF discussion list , tls@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 18:13:44 -0000 --On Wednesday, September 22, 2010 12:34:50 PM -0400 Barry Leiba wrote: > There's a distinction, here, between a protocol and a user interface > for configuration. My mother doesn't know whom to trust, except that > she knows that she (at least kinda-sorta) trusts the mail program > she's decided to use, and an entity she calls "gmail" (not > "google.com", not "gmail.com", but just "gmail"). She's relying to > the mail program's "easy configuration feature" to sort this out. > > The text I reviewed appeared to be saying normative things about what > client software MUST and MUST NOT do with regard to this sort of > configuration situation, which goes well beyond what the client > software is doing on the wire. Unless I'm mis-reading it, it's > explicitly saying that my client software is not allowed to do > something like this, for example: > 1. Ask the user, "What email service do you use?" > 2. Receive the answer "gmail" from the user. > 3. Auto-configure itself for the known gmail servers based only on > that user input. I think that's reasonable behavior _if_ the mail client knows that "gmail" is "mail.google.com". What's _not_ reasonable is for it to arbitrarily transform "gmail" into a domain by adding ".com", then look up "gmail.com" and see that it is an alias for "mail.google.com" and not only follow the (insecure) alias to mail.google.com but also use it to decide that "mail.google.com" is an appropriate name to find in a certificate. If your mother's mail client does that, then all I have to do to steal her password is convince said client that "gmail.com" is actually an alias for "stealgmailpassword.attacker.org". From dharkins@lounge.org Wed Sep 22 15:51:13 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 783BA3A6809; Wed, 22 Sep 2010 15:51:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TM3mFpr5iDuA; Wed, 22 Sep 2010 15:51:12 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by core3.amsl.com (Postfix) with ESMTP id 7DE2B3A6812; Wed, 22 Sep 2010 15:51:10 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 60A461E00BA; Wed, 22 Sep 2010 15:51:38 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 22 Sep 2010 15:51:38 -0700 (PDT) Message-ID: <2854ac8e63b1bad22adfd01498af694f.squirrel@www.trepanning.net> In-Reply-To: <002801cb5a38$5db4f5c0$191ee140$@net> References: <002801cb5a38$5db4f5c0$191ee140$@net> Date: Wed, 22 Sep 2010 15:51:38 -0700 (PDT) From: "Dan Harkins" To: "Glen Zorn" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: violeta.cakulev@alcatel-lucent.com, 'Tim Polk' , ganesh.sundaram@alcatel-lucent.com, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-cakulev-mikey-ibake-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 22:51:13 -0000 Hello, On Wed, September 22, 2010 2:27 am, Glen Zorn wrote: [snip] > Section 4.1 > > . The first sentence of paragraph 4 contains rather confusing > notation. It says "The Initiator next chooses a random x and computes xP > (i.e. adds P to itself x times), where P is a point on elliptic curve E > known to all users." The notation "xP" is a conventional one for > expressing > the multiplication of P by x, which is not the same as the addition of P > to > itself x times. If the latter interpretation is actually, I think that a > better notation should be chosen. Actually multiplication of P by x is "the addition of P to itself x-1 times" since adding P to itself 1 time would be P + P = 2P. Regarding the notation, it would be nice if there was some convention on how to should show ECC operations in an I-D or RFC. Should it be multiplicative notation or additive notation? Should points on the curve be upper-case and scalars are lower-case, or vice versa? How do you represent the elliptic curve identity element? RFC 5931 uses additive notation, uses upper-case for points and lower-case for scalars and calls it the "point at infinity", respectively, while David McGrew's fundamental ECC draft uses multiplicative notation, uses lower-case for points and upper-case for scalars and defines it as "e", respectively. This draft is proposing "xP" while the additive notation used in RFC 5931 is "x*P". So this is yet another notation for the same old thing. A diktat from the IESG or the Security Area ADs would be helpful. regards, Dan. From barryleiba@gmail.com Wed Sep 22 20:55:39 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BF63A68E1 for ; Wed, 22 Sep 2010 20:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.861 X-Spam-Level: X-Spam-Status: No, score=-2.861 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJixnrlaP42r for ; Wed, 22 Sep 2010 20:55:38 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2B4BC3A686D for ; Wed, 22 Sep 2010 20:55:38 -0700 (PDT) Received: by iwn3 with SMTP id 3so1256362iwn.31 for ; Wed, 22 Sep 2010 20:56:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=I/Q80meyj8cyr1lyYsYk4fj0TQSZoP5NlS1WmlishwE=; b=xurJyY3OZxXVk5F9zrgqrYL7rc7Dn4hhYuzs2AyyQBVQJVLgXL0b1DrA4fbrc6Q3xf JVSkBsvaCNvgv45TxRfQPca/vpZviKyJz9Ptlg2yAtMkUBSU1r5rZXCY6lXXJWFLMHMF oc5NqaWRsoOZa2g1lrAn7cDhygLLlPf4sGz3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=v0mYDCCgWweWzakWqHxSpo/HF5IVQG9rYbor8aOclW8lTqI1rbbPmVLr/nOtlsihGT yPwltaypODvD46kZoLTQW03dIPfLkdng9Ua2uaaFVHBWrmY4zrI1uXzpj3hpXcYekm/T l+5Tup33SZKcjdrZxWWNtLnP3T2sa+SCHnEaY= MIME-Version: 1.0 Received: by 10.231.160.77 with SMTP id m13mr1321636ibx.22.1285214166390; Wed, 22 Sep 2010 20:56:06 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.231.199.66 with HTTP; Wed, 22 Sep 2010 20:56:06 -0700 (PDT) Date: Wed, 22 Sep 2010 23:56:06 -0400 X-Google-Sender-Auth: fRIPx_CYDNpSkCoRAYUcy_-SKeU Message-ID: From: Barry Leiba To: secdir@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [secdir] attn: Sam Weiler; others please ignore X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 03:55:39 -0000 This is a test message to the secdir list. Sam, will you please forward this back to , with full headers? Thanks. Barry -- Barry Leiba=A0 (barryleiba@computer.org) From derek@ihtfp.com Thu Sep 23 09:54:33 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E1713A69D4; Thu, 23 Sep 2010 09:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.058 X-Spam-Level: X-Spam-Status: No, score=-101.058 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4lnaR4PjmL8R; Thu, 23 Sep 2010 09:54:32 -0700 (PDT) Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) by core3.amsl.com (Postfix) with ESMTP id 833BC3A69BD; Thu, 23 Sep 2010 09:54:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 4AAFF26035C; Thu, 23 Sep 2010 12:54:58 -0400 (EDT) Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 20271-05; Thu, 23 Sep 2010 12:54:54 -0400 (EDT) Received: from pgpdev.ihtfp.org (IHTFP-DHCP-100.IHTFP.ORG [192.168.248.100]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "cliodev.ihtfp.com", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by mail2.ihtfp.org (Postfix) with ESMTPS id C185F260358; Thu, 23 Sep 2010 12:54:54 -0400 (EDT) Received: (from warlord@localhost) by pgpdev.ihtfp.org (8.14.4/8.14.3/Submit) id o8NGsidt000798; Thu, 23 Sep 2010 12:54:44 -0400 From: Derek Atkins To: iesg@ietf.org, secdir@ietf.org Date: Thu, 23 Sep 2010 12:54:44 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.2a Cc: john-ietf@jck.com, yw@mrko.pe.kr, eai-chairs@tools.ietf.org Subject: [secdir] sec-dir review of draft-ietf-eai-frmwrk-4952bis-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 16:54: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 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. Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is an update of RFC 4952; it reflects additional issues identified since that document was published. Opening up the internationalized email address can of worms is just that, a can of worms. But this document seems to understand that the topic is a can of worms and tries hard to point out many of the worms in the can. I believe this document does as much as it can to caution people about all the open issues involved in internationalizing email addresses. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From john-ietf@jck.com Thu Sep 23 10:02:50 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 072F83A6943; Thu, 23 Sep 2010 10:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNqKSDUU3pZ7; Thu, 23 Sep 2010 10:02:49 -0700 (PDT) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 0AF693A6812; Thu, 23 Sep 2010 10:02:49 -0700 (PDT) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1OypCW-0004kX-Hh; Thu, 23 Sep 2010 13:03:16 -0400 Date: Thu, 23 Sep 2010 13:03:15 -0400 From: John C Klensin To: Derek Atkins , iesg@ietf.org, secdir@ietf.org Message-ID: <7286BBA4D075997AE8AEBA0E@PST.JCK.COM> In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: yw@mrko.pe.kr, eai-chairs@tools.ietf.org Subject: Re: [secdir] sec-dir review of draft-ietf-eai-frmwrk-4952bis-08.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 17:02:50 -0000 --On Thursday, September 23, 2010 12:54 -0400 Derek Atkins wrote: > 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. >... > Opening up the internationalized email address can of worms is > just that, a can of worms. But this document seems to > understand that the topic is a can of worms and tries hard to > point out many of the worms in the can. > > I believe this document does as much as it can to caution > people about all the open issues involved in > internationalizing email addresses. Derek, Thanks. And, indeed, WGs doing serious internationalization work rapidly become experts in worm taxonomy. What we worry about, and some, including IDNABIS, encounter, is the discovery that, when one opens the can, it is full of poisonous vipers, not merely worms. :-( john From rbarnes@bbn.com Thu Sep 23 11:11:35 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23113A6A85; Thu, 23 Sep 2010 11:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.387 X-Spam-Level: X-Spam-Status: No, score=-97.387 tagged_above=-999 required=5 tests=[AWL=-4.971, BAYES_05=-1.11, FB_WORD2_END_DOLLAR=3.294, HTTP_ESCAPED_HOST=0.134, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, SARE_URI_EQUALS=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A785w47WBaKG; Thu, 23 Sep 2010 11:11:04 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id AA21A3A6943; Thu, 23 Sep 2010 11:11:03 -0700 (PDT) Received: from [192.1.255.185] (port=58400 helo=col-dhcp-192-1-255-185.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OyqFt-0009h1-5x; Thu, 23 Sep 2010 14:10:49 -0400 Message-Id: <93037048-4609-40F7-BCC0-D635301E4042@bbn.com> From: "Richard L. Barnes" To: Marsh Ray In-Reply-To: <4C9A5B13.1040802@extendedsubset.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 23 Sep 2010 14:10:48 -0400 References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> <4C9A5B13.1040802@extendedsubset.com> X-Mailer: Apple Mail (2.936) Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, ArkanoiD Subject: Re: [secdir] [TLS] [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 18:11:36 -0000 There is no black magic here, only the magic of the TLS server_name extension. If the client provides server_name=gmail.com, the server provides a gmail.com cert, otherwise it defaults to mail.google.com. Your browser is following two secure delegations before it lands at www.google.com (gmail.com -> mail.google.com -> www.google.com). My guess based on the anecdotes in the thread is that IE8 doesn't support it. (You should also be more careful about your HTTP emulation! "A client MUST include a Host header field in all HTTP/1.1 request messages .") In full detail: rbarnes$ openssl s_client -connect gmail.com:443 -servername gmail.com [...] subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=gmail.com issuer=/C=US/O=Google Inc/CN=Google Internet Authority [...] GET / HTTP/1.1 Host: gmail.com HTTP/1.1 301 Moved Permanently Location: https://mail.google.com/mail/ [...] rbarnes$ openssl s_client -connect mail.google.com:443 -servername mail.google.com [...] subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ CN=mail.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA [...] GET /mail/ HTTP/1.1 Host: mail.google.com HTTP/1.1 302 Moved Temporarily Location: https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dl&bsv=1eic6yu9oa4y3&ss=1&scc=1<mpl=default<mplcache=2 [...] rbarnes$ openssl s_client -connect www.google.com:443 -servername www.google.com [...] subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA [...] GET /accounts/ServiceLogin? service=mail&passive=true&rm=false&continue=https%3A%2F %2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy %3Dl&bsv=1eic6yu9oa4y3&ss=1&scc=1<mpl=default<mplcache=2 HTTP/1.1 Host: www.google.com HTTP/1.1 200 OK [...] On Sep 22, 2010, at 3:37 PM, Marsh Ray wrote: > On 09/22/2010 01:31 PM, ArkanoiD wrote: >> BTW, slightly offtopic here: whenever i connect to gmail.com, i get >> certificate >> for mail.google.com. But i've yet to see any web browser to >> complain! Where is the magic? > > Seems totally relevant to me. > > Going to https://gmail.com/ I get some kind of redirection to https://www.google.com/accounts/ServiceLogin > ... > > I can confirm the silent redirect behavior on FF, an associate > reports it on IE9. I tried IE8 but get the expected "cert was issued > for a different website's address" error. > > Hopefully I'm overlooking something simple, but at first glance it > would seem like either of these two conditions are true: > > 1. Multiple vendors are putting some kind of override table in their > browsers with an entry for gmail.com. > > 2. Browsers are running script from badly authenticated sources. > > So what does gmail.com have in this situation that an attacker > couldn't obtain for phonygmail.com? > > - Marsh > > > marsh@lamb:/tmp$ dig -t any gmail.com > > ; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2 > > ;; QUESTION SECTION: > ;gmail.com. IN ANY > > ;; ANSWER SECTION: > gmail.com. 300 IN A 74.125.227.22 > gmail.com. 300 IN A 74.125.227.21 > gmail.com. 300 IN A 74.125.227.24 > gmail.com. 300 IN A 74.125.227.23 > gmail.com. 86400 IN NS ns4.google.com. > gmail.com. 86400 IN NS ns1.google.com. > gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. > 1427981 21600 3600 1209600 300 > gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. > gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. > gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" > > ;; ADDITIONAL SECTION: > ns4.google.com. 85092 IN A 216.239.38.10 > ns1.google.com. 85092 IN A 216.239.32.10 > > ;; Query time: 54 msec > ;; SERVER: 192.168.1.3#53(192.168.1.3) > ;; WHEN: Wed Sep 22 14:26:29 2010 > ;; MSG SIZE rcvd: 330 > > > > marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 > ... > subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ > CN=mail.google.com > issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA > ... > --- > GET / HTTP/1.0 > > HTTP/1.0 200 OK > Date: Wed, 22 Sep 2010 19:31:43 GMT > Expires: -1 > Cache-Control: private, max-age=0 > Content-Type: text/html; charset=ISO-8859-1 > Set-Cookie: > PREF > =ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; > expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com > Set-Cookie: > NID > = > 39 > = > nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i > -CvhRU1DrDDYvExygPnpew69GRLaWZeI0; expires=Thu, 24-Mar-2011 19:31:43 > GMT; path=/; domain=.google.com; HttpOnly > Server: gws > X-XSS-Protection: 1; mode=block > > content="text/html; charset=ISO-8859-1">Google</ > title > > > < > script > >window.google={kEI:"n1maTNKCA5O8zAXDpJFW",kEXPI:"24956,26758",kCSI: > {e > :"24956,26758 > ",ei:"n1maTNKCA5O8zAXDpJFW",expi:"24956,26758"},ml:function() > {},kHL:"en",time:function(){return(new > Date).getTime()},log:function(b,d,c){var a=new > Image > ,e=google,g=e.lc,f=e.li;a.onerror=(a.onload=(a.onabort=function() > {delete g[f]}));g[f]=a;c=c||"/gen_204?atyp=i&ct="+b+"&cad="+d > +"&zx="+google.time();a.src=c;e.li=f+1},lc:[],li:0,Toolbelt:{}}; > window.google.sn="webhp";window.google.timers={load:{t:{start:(new > Date).getTime()}}};try{}catch(u){}window.google.jsrt_kill=1; > var _gjwl=location;function _gjuc(){var > e=_gjwl.href.indexOf("#");if(e>=0){var > a=_gjwl.href.substring(e);if(a.indexOf("&q=")>0||a.indexOf("#q=")>=0) > {a=a.substring(1);if(a.indexOf("#")==-1){for(var c=0;c<a.length;) > {var d=c;if(a.charAt(d)=="&")++d;var > b=a.indexOf("&",d);if(b==-1)b=a.length;var > f=a.substring(d,b);if(f.indexOf("fp=")==0){a=a.substring(0,c) > +a.substring(b,a.length);b=c}else if(f=="cad=h")return > 0;c=b}_gjwl.href="/search?"+a+"&cad=h";return 1}}}return 0}function > _gjp(){!(window._gjwl.hash&& > window._gjuc())&&setTimeout(_gjp,500)}; > window._gjp && _gjp()</script><style id=gstyle>body{margin: > 0}#gog{padding:3px 8px 0}td{line-height:.8em}.gac_m td{line-height: > 17px}form{margin-bottom:20px}body,td,a,p,.h{font-family:arial,sans- > serif}.h{color:#36c;font-size:20px}.q{color:#00c}.ts td{padding: > 0}.ts{border-collapse:collapse}em{font-weight:bold;font- > style:normal}.lst{width:496px}.tiah{width:458px}input{font- > family:inherit}a.gb1,a.gb2,a.gb3,a.gb4{color:#11c ! > important}#gog{background:#fff}#gbar,#guser{font-size:13px;padding- > top:1px !important}#gbar{float:left;height:22px}#guser{padding- > bottom:7px !important;text-align:right}.gbh,.gbd{border-top:1px > solid #c9d7f1;font-size:1px}.gbh{height:0;position:absolute;top: > 24px;width:100%}#gbs,.gbm{background:#fff;left: > 0;position:absolute;text-align:left;visibility:hidden;z-index: > 1000}.gbm{border:1px solid;border-color:#c9d7f1 #36c #36c #a2bae7;z- > index:1001}.gb1{margin-right:.5em}.gb1,.gb3{zoom: > 1}.gb2{display:block;padding:.2em .5em}.gb2,.gb3{text- > decoration:none;border- > bottom:none}a.gb1,a.gb2,a.gb3,a.gb4{color:#00c ! > important}a.gb2:hover{background:#36c;color:#fff ! > important}#gbar{display: none}#gbe{display: > none}body{background:#fff;color:black}input{-moz-box-sizing:content- > box}a{color:#11c;text-decoration:none}a:hover,a:active{text- > decoration:underline}.fl > a{color:#4272db}a:visited{color:#551a8b}a.gb1,a.gb4{text- > decoration:underline}a.gb3:hover{text-decoration:none}#ghead > a.gb2:hover{color:#fff!important}.ds{display:-moz-inline- > box}.ds{border-bottom:solid 1px #e7e7e7;border-right:solid 1px > #e7e7e7;display:inline-block;margin:3px 0 4px;margin-left: > 4px}.sblc{padding-top:5px}.sblc a{display:block;margin:2px 0;margin- > left:13px;font-size:11px;}.lsbb{background:#eee;border:solid > 1px;border-color:#ccc #999 #999 #ccc;height: > 30px;display:block}.lsb{background:url(/images/srpr/nav_logo14.png) > bottom;font:15px arial,sans- > serif;border:none;color:#000;cursor:pointer;height:30px;margin: > 0;outline:0;vertical- > align:top > }.lsb:active{background:#ccc}.lst:focus{outline:none}.ftl,#fll > a{margin:0 12px}#addlang a{padding:0 3px}.gac_v > div{display:none}.gac_v .gac_v2,.gac_bt{display:block!important}</ > style><script>google.y={};google.x=function(e,g) > {google.y[e.id]=[e,g];return false};window.gbar={qs:function() > {},tg:function(e){var o={id:'gbar'};for(i in > e)o[i]=e[i];google.x(o,function(){gbar.tg(o)})}};</script></ > head><body bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b > alink=#ff0000 onload="document.f.q.focus();if(document.images)new > Image().src='/images/srpr/nav_logo14.png'" ><textarea id=csi > style=display:none></textarea><iframe name=wgjf style=display:none></ > iframe><div id=ghead><div id=gog><div id=guser > width=100%><nobr><span id=gbn class=gbi></span><span id=gbf > class=gbf></span><span id=gbe><a href="/url?sa=p&pref=ig&pval=3&q=http://www.google.com/ig%3Fhl%3Den%26source%3Diglk&usg=AFQjCNFA18XPfgb7dKnXfKz7x7g1GDH1tg > " class=gb4>iGoogle</a> | </span><a href="/preferences?hl=en" > class=gb4>Search settings</a> | <a href="https://www.google.com/accounts/Login?hl=en&continue=https://www.google.com/ > " class=gb4>Sign in</a></nobr></div><div class=gbh style=left:0></ > div><div class=gbh style=right:0></div></div></div> <center><br > clear=all id=lgpd><div id=lga><img src="images/logos/ > ssl_logo_lg.gif" width=276 height=110 border=0><br></div><font > size=-1>Go to <a href="http://www.google.com/">classic Google</a>.</ > font><form action="/search" name=f><table cell > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From stpeter@stpeter.im Wed Sep 22 08:58:50 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C220428C115; Wed, 22 Sep 2010 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQPO1TcLaW+h; Wed, 22 Sep 2010 08:58:48 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id AB30228C116; Wed, 22 Sep 2010 08:58:48 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1DBCE40074; Wed, 22 Sep 2010 10:04:07 -0600 (MDT) Message-ID: <4C9A27D0.7030909@stpeter.im> Date: Wed, 22 Sep 2010 09:59:12 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: barryleiba@computer.org References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> In-Reply-To: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF cert-based identity <certid@ietf.org>, IETF discussion list <ietf@ietf.org>, Barry Leiba <barryleiba.mailing.lists@gmail.com>, tls@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 15:58:50 -0000 Barry, thank you for your review. Jeff and I are working through all the feedback that's been provided so far, and we'll be replying in various threads and cc'ing all appropriate lists as we (the editorial team) reach agreement on how to proceed. On 9/14/10 3:39 PM, Barry Leiba 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. > > Please forgive the lateness of this review; I really meant to have it > done sooner. > > First, I found the document to be a tough read, and I can't really pin > down why. I started reviewing it several times, and restarted, before > I finally got through it. I can't give any advice with this comment, > so just take it as it is. Thanks for the feedback. The subject-matter is more dense than one might expect, and we attempted to be as thorough as possible so as to remove ambiguities. As a way of orienting the reader, we are thinking about adding a paragraph or two to the introduction briefly outlining our conclusions, but we don't yet have text to propose. > Second, there's a mixture of "natural person" and "human user" in the > document, and my sense is that you mean the same thing by both. If > you do, you should switch to one term (I prefer the latter; "natural > person" sounds odd). If they're meant to be different, you should > make it clear what the difference is. In our working copy we've changed "natural person" to "human user" in all instances. > Third, I'll note the earlier discussion of issues with IDN > comparisons. I have nothing to add to that discussion, and it may be > that the best thing is to leave things as they are. IDN-related topics are indeed always challenging, but we think that the current text meets the needs of this specification. > Comments are in order of appearance, not significance: > > -- Page 16, bullet 6: > The certificate MAY contain more than one DNS-ID, but SHOULD NOT > contain more than one CN-ID. > > Why "SHOULD NOT", and not "MUST NOT" ? I'm not challenging this; it's > a question. In an earlier version of this specification, we had "MUST NOT" instead of "SHOULD NOT". Discussion on the certid@ietf.org list led us to change it to "SHOULD NOT", because folks argued that if a certificate contains multiple DNS-IDs then it might appropriately contain one CN-ID corresponding to each DNS-ID. Jeff said he needs to review the older discussion again before the editors agree on how to proceed. > -- Page 17, sec 4.2, first graf: > Before connecting to the server, the client MUST construct a list of > acceptable reference identifiers. > > Why MUST it be done "before"? Can anyone detect, or does it hurt > interoperability, if it's done, say, in parallel with connection, or > while the client is waiting for the server to return the certificate? The current wording is unfortunate, because it is not temporal order that matters; what matters is that the client constructs its list of reference identifiers without being influenced by the presented identifiers provided in the certificate that's being checked. Therefore Jeff and I propose the following corrected text: Based on the source domain and the type of service to which the client is connecting, the client MUST construct a list of acceptable reference identifiers. > -- Page 18, sec 4.2, last bullet: > o The list SHOULD NOT include a CN-ID; however, the CN-ID (if > included) MUST be constructed only from the source domain and > never from a target domain. > > I find this oddly put. How about "The list SHOULD NOT include a > CN-ID. If a CN-ID is used despite this advice, it MUST be..." ? We have changed it to: o The list SHOULD NOT include a CN-ID; however, if a CN-ID is included despite this advice, it MUST be constructed only from the source domain and never from a target domain. > I'd also like to take the security note from section 4.3 and echo it > here. So maybe this?: > > << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite > this advice, it MUST be constructed only from the source domain and > never from a target domain. Further, it MUST NOT be used unless there > are no other supported identifiers present in the certificate. >> The last sentence does not apply in Section 4.2, because that section concerns construction of the list of reference identifiers and as stated above the client needs to do so without being influenced by the contents of the certificate presented by the server. > -- Page 18, sec 4.3, first graf: > by seeking a match and aborting the search if any presented > identifier matches one of its reference identifiers. > > "Aborting" has the connotation of premature termination, before > completion, and that's not the case here; you're saying that the match > completes the process. How about, simply, "stopping", or "ending" ? In our working copy, that paragraph now reads: Once the client has constructed its list of reference identifiers and has received the server's presented identifiers in the form of a PKIX certificate, the client checks its reference identifiers against the presented identifiers for the purpose of finding a match. The search fails if the client exhausts its list of reference identifiers without finding a match. The search succeeds if any presented identifier matches one of the reference identifiers, at which point the client SHOULD stop the search. > -- Page 19, sec 4.4.3: > I think implementers might think that you're simply allowing any > leading wildcard character, so we should explicitly dissuade them. > > So, in the first graf: > the wildcard character '*', but only as the left-most label of the > domain name, > make it "only as the complete value of the left-most label". > > And in the second graf: > in which the wildcard character is contained within a label fragment > (e.g., baz*.example.net is not allowed and MUST NOT be taken to match > baz1.example.net and baz2.example.net) > change to: > baz1.example.net and baz2.example.net; also, *bozz.example.net is > not allowed and MUST NOT be taken to match frobozz.example.net) We've tightened up that text, as follows: ### A client employing this specification's rules MAY match the reference identifier against a presented identifier in which a traditional domain name or internationalized domain name contains one instance of the wildcard character '*', but only if that character is the complete left-most label of the domain name (as "label" is defined in [DNS]). The following rules apply: 1. The client MUST NOT match a presented identifier in which the wildcard character is not the only character of the label; e.g., baz*.example.net and *baz.example.net and b*z.example.net are not allowed and MUST NOT be taken to match baz1.example.net and foobaz.example.net and buzz.example.net. 2. The client MUST NOT match a presented identifier in which the wildcard character comprises a label other than the left-most label; e.g., bar.*.example.net is not allowed. 3. The client MUST compare the wildcard character only against the left-most label; e.g., *.example.com matches foo.example.com but not bar.foo.example.com or example.com. ### > -- Page 19, sec 4.4.3, last graf: > A specification that references the rules defined in this document > can specify that the wildcard character is not allowed in > certificates used by the relevant application protocol or community > of interest. > > How about “...can strengthen this section by ruling out wildcard > matching altogether for the relevant...†? Changed in our working copy to: A specification that references the rules defined in this document can strengthen the generic recommendations herein by disallowing wildcard matching altogether for the relevant application protocol or community of interest. > -- Page 20, sec 4.4.4, second graf: > entry types supported by the client), the client MAY as a fallback > check for a string whose form matches that of a fully-qualified DNS > domain name in the CN-ID. > > Back in section 4.2, you say that the client SHOULD NOT include CN-ID > in the list, and here you're saying that it MAY make such a > comparison. That seems oddly contradictory to me, though one can > certainly argue that SHOULD NOT implies MAY. I'd prefer to see this > worded differently. Good catch. Jeff and I do indeed mean to say that CN-ID is NOT RECOMMENDED, not that it is OPTIONAL (the two are not equivalent, as I recently learned by re-reading RFC 2119). Therefore we have provisionally modified the text in Section 4.4.4 to read: As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include an SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName entry types supported by the client. Therefore, if and only if the set of identifiers does not include a subjectAltName entry of type dNSName, SRVName, or uniformResourceIdentifier (or any application-specific subjectAltName entry types supported by the client), as a fallback the client is allowed to check the CN-ID for a string whose form matches that of a fully-qualified DNS domain name. Despite the fact that this behavior is NOT RECOMMENDED, if the client does compare a reference identifier of type CN-ID against that string obtained from a CN-ID presented in the certificate, it MUST follow the comparison rules for the source domain of an identifier of type DNS-ID, SRV-ID, or URI-ID, as described under Section 4.4. Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if"). Jeff is a bit uncomfortable with that because CN-ID is such a common practice, but I'm comfortable with it because of the hypothetical nature of the recommendation. He will review the earlier discussions on this topic before we finalize that text. > -- Page 21, sec 4.6.2: > client MUST verify that the presented certificate matches the cached > certificate and (if it is an interactive client) MUST notify the user > if the certificate has changed since the last time a secure > connection was successfully negotiated (where causes of change > include but are not limited to changes in the DNS domain name, > identifiers, issuer, certification path, and expiration date). > > I worry about this kind of advice. It violates my rule that says, > "Don't ask the user a question that he's not qualified to answer." Of > course, "notify the user" can mean a lot of things, but too many > clients will implement something like this with a popup that will be > meaningless to 99% of the people who use it. Based on feedback from other threads, that section now reads: ### 4.6.2. Case #2: No Match Found, Cached Certificate If the client finds no presented identifier that matches any of the reference identifiers but a human user has permanently accepted the certificate during a previous connection attempt or via configured preferences, the certificate has already been cached. In this case, the client MUST verify that the presented certificate matches the cached certificate; if the presented certificate does not match the cached certificate then the client MUST proceed as described under Case #3 below. ### See also our reply below regarding Section 4.3.6.1. > -- Page 21, sec 4.6.3, last graf: > Instead, the client MUST proceed as follows. > > I like a colon there, instead of the full stop. I used to like colons in such places, but I've migrated to full stop. We'll see what the RFC Editor has to say. :) > -- Page 21, sec 4.6.3.1, security note: > caution, for example by first encouraging the user to terminate > the connection, forcing the user to view the entire certification > path, and allowing the user to accept the certificate only on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session). > > Same comment as for 4.6.2. Most users will not understand certificate > problems, and will have no idea what they should do about them. > Always remember the "Barry's mother problem". My mother will *never* > want to see an "entire certification path", let alone appreciate being > "forced" to. The part of the text that you have not quoted does say that this practice is typically offered only to advanced users (and I don't think that Barry's mother counts as an advanced user). However, we've provisionally made the text even more scary, as follows: Security Note: Some existing interactive user agents give advanced users the option of proceeding despite an identity mismatch. Although this behavior can be appropriate in certain specialized circumstances, in general it needs to be exposed only to advanced users and even then needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the connection and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to accept the certificate on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session, but not for connection attempts during future application sessions). Jeff still needs to review that text before we finalize it. > -- Page 22, sec 5.1: > When the connecting application is an interactive client, the source > domain name and service type MUST be provided by a human user (e.g. > when specifying the server portion of the user's account name on the > server or when explicitly configuring the client to connect to a > particular host or URI as in [SIP-LOC]) and MUST NOT be derived from > the user inputs in an automated fashion (e.g., a host name or domain > name discovered through DNS resolution of the source domain). This > rule is important because only a match between the user inputs (in > the form of a reference identifier) and a presented identifier > enables the client to be sure that the certificate can legitimately > be used to secure the connection. > > Does this mean that a client specifically designed for the "gumbo" > service can't automatically use the service type "gumbo", without the > user's involvement? Or that a client put out by example.net can't > assume a host name of services.example.net in the absence of user > input that says otherwise? IMHO that is a matter of user configuration, or user acknowledgement of a service agreement, so it falls under the text in this I-D about allowing the client to check the certificate against a DNS domain name that is explicitly associated with the source domain by means of user configuration. > Further, it's entirely reasonable for a program to have a user enter > something like "gmail", and have the client turn that into something > like "mail.google.com", deriving it from the user's input in an > automated fashion. Do we really want to forbid that sort of thing? Yes, we do, because although you happen to "just know" that mail.google.com is a legitimate DNS domain name to connect to when interacting with the gmail.com service, Barry's mother might not have that kind of knowledge and as a general rule it's a very bad idea to assume that it's just fine to connect to some domain at foo.com when interacting with a service at bar.com. However, service delegation is a difficult topic and there are ongoing discussions among various IETF participants about how to do service delegation securely; one thing I think we can safely say is that it's not the task of this I-D to solve the problem of secure service delegation. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 10:52:53 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E013A685B; Wed, 22 Sep 2010 10:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfzMhVET+LeV; Wed, 22 Sep 2010 10:52:51 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id BF92F3A694D; Wed, 22 Sep 2010 10:52:51 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8624340074; Wed, 22 Sep 2010 11:58:12 -0600 (MDT) Message-ID: <4C9A428C.2030807@stpeter.im> Date: Wed, 22 Sep 2010 11:53:16 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jeffrey Hutzelman <jhutz@cmu.edu> References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> In-Reply-To: <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: tls@ietf.org, barryleiba@computer.org, IETF cert-based identity <certid@ietf.org>, iesg@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 17:52:53 -0000 On 9/15/10 12:30 PM, Jeffrey Hutzelman wrote: > --On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba > <barryleiba.mailing.lists@gmail.com> wrote: <snip/> >> -- Page 21, sec 4.6.3.1, security note: >> caution, for example by first encouraging the user to terminate >> the connection, forcing the user to view the entire certification >> path, and allowing the user to accept the certificate only on a >> temporary basis (i.e., for this connection attempt and all >> subsequent connection attempts for the life of the application >> session). >> >> Same comment as for 4.6.2. Most users will not understand certificate >> problems, and will have no idea what they should do about them. >> Always remember the "Barry's mother problem". My mother will *never* >> want to see an "entire certification path", let alone appreciate being >> "forced" to. > > In fact, I see two problems with the quoted advice. First, since we're > talking about a certificate name mismatch, the rest of the certification > chain really isn't relevant. It would be if the problem were a chain > that doesn't lead to a suitable trust anchor, but that's not what this > document is about. For context, the "quoted advice" is mostly a description of current usage in some existing user agents. Incorporating Barry's suggestions, that text currently reads as follows in our working copy: Security Note: Some existing interactive user agents give advanced users the option of proceeding despite an identity mismatch. Although this behavior can be appropriate in certain specialized circumstances, in general it ought to be exposed only to advanced users and even then needs to be handled with extreme caution, for example by first encouraging even an advanced user to terminate the connection and, if the advanced user chooses to proceed anyway, by forcing the user to view the entire certification path and only then allowing the user to accept the certificate on a temporary basis (i.e., for this connection attempt and all subsequent connection attempts for the life of the application session, but not for connection attempts during future application sessions). Your document editors will take up this issue during our discussion of open issues with the spec. > That said, Barry, your mother is not an "advanced > user" in the sense intended by this document, and should never even be > given the option to accept a certificate that doesn't validate. > > The second issue is the advice that the user should be allowed to accept > a certificate with a mismatched name only on a temporary basis. This is > almost certain to be the wrong thing to do; if a name mismatch is > acceptable, it's also not likely to change anytime soon, and requiring > the user to accept the certificate again in a later session just because > the client has restarted is just annoying with no security benefit. That's an interesting point. In feedback we received from implementers of interactive user agents (most browsers), we heard that at least some user agents do enforce a distinction between accepting an identity mismatch temporarily and accepting it permenantly. The security properties of that distinction did not come up in previous mailing list threads about this I-D, but your editorial team will do a bit more research and might return with proposed text changes. > If we were talking about path validation rather than server naming, I'd > point out that accepting a certificate only temporarily doesn't give you > the benefit of being able to detect future changes, and so actually > _reduces_ security. With names, this isn't a big deal, as it's > relatively easy to decide whether foo.bank.com and foo.attacker.org are > the same or not (well, unless the bank and attacker have the same name). > >> -- Page 22, sec 5.1: >> When the connecting application is an interactive client, the source >> domain name and service type MUST be provided by a human user (e.g. >> when specifying the server portion of the user's account name on the >> server or when explicitly configuring the client to connect to a >> particular host or URI as in [SIP-LOC]) and MUST NOT be derived from >> the user inputs in an automated fashion (e.g., a host name or domain >> name discovered through DNS resolution of the source domain). This >> rule is important because only a match between the user inputs (in >> the form of a reference identifier) and a presented identifier >> enables the client to be sure that the certificate can legitimately >> be used to secure the connection. >> >> Does this mean that a client specifically designed for the "gumbo" >> service can't automatically use the service type "gumbo", without the >> user's involvement? > > I don't think it does. If a user is running a gumbo client, I think > it's implied that he meant to talk to the gumbo service. But if he's > running a web browser, the browser should not decide that the user meant > to use the gumbo service by the presence of gumbo.example.com (or a > corresponding SRV record) in the DNS, any more than it should assume > from the presence of an alias www.example.com => gumbo.example.com that > gumbo.example.com is an acceptable server name when the user typed > www.example.com. > > >> Or that a client put out by example.net can't >> assume a host name of services.example.net in the absence of user >> input that says otherwise? > > Again, I think this is fine; the client defines the lack of a > user-specified name to mean something specific. What's not fine is to > take the name given by the user and apply an insecure translation such > as an unprotected DNS lookup. > > I think the advice in this paragraph is a little over-restrictive. What > should be prohibited is not automated rewriting, but automated rewriting > based on the use of insecure sources. RFC4120 has the following to say > on this subject, as it relates to Kerberos: > > > One can also rely on trusted third parties to make this > determination, but only when the data obtained from the third party > is suitably integrity-protected while resident on the third-party > server and when transmitted. Thus, for example, one should not rely > on an unprotected DNS record to map a host alias to the primary name > of a server, accepting the primary name as the party that one intends > to contact, since an attacker can modify the mapping and impersonate > the party. Thanks for the pointer to RFC 4120. We're looking into how to appropriate reference that in the next version of this spec. >> Further, it's entirely reasonable for a program to have a user enter >> something like "gmail", and have the client turn that into something >> like "mail.google.com", deriving it from the user's input in an >> automated fashion. > > Not if the client does so by rewriting "gmail" as "www.gmail.com", > looking that up in the DNS, and using the target of the resulting > alias. Most web browsers already get this right, thankfully. Again, we agree with you that secure service delegation is outside the scope of this I-D, as we expressed in our reply to Barry's review. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 11:11:19 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933A53A6A46; Wed, 22 Sep 2010 11:11:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz4ZXrdbYQEv; Wed, 22 Sep 2010 11:11:17 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 7EDF53A6A30; Wed, 22 Sep 2010 11:11:17 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 577D540074; Wed, 22 Sep 2010 12:16:38 -0600 (MDT) Message-ID: <4C9A46DD.7010502@stpeter.im> Date: Wed, 22 Sep 2010 12:11:41 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Barry Leiba <barryleiba.mailing.lists@gmail.com> References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> In-Reply-To: <AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF discussion list <ietf@ietf.org>, IETF cert-based identity <certid@ietf.org>, tls@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 18:11:19 -0000 On 9/22/10 10:34 AM, Barry Leiba wrote: > Hi, Peter. Thanks for the response, and I'm very happy with nearly > all the changes you've adopted. I'll not quote and comment on it all, > except to make the general statement: Great work! Thanks! Comments inline. >>> I'd also like to take the security note from section 4.3 and echo it >>> here. So maybe this?: >>> >>> << The list SHOULD NOT include a CN-ID. If a CN-ID is used despite >>> this advice, it MUST be constructed only from the source domain and >>> never from a target domain. Further, it MUST NOT be used unless there >>> are no other supported identifiers present in the certificate. >> >> >> The last sentence does not apply in Section 4.2, because that section >> concerns construction of the list of reference identifiers and as stated >> above the client needs to do so without being influenced by the contents >> of the certificate presented by the server. > > I see your point, and I agree. > Still, it might be useful at this point to explain WHY the list SHOULD > NOT include a CN-ID. I'll leave it there, with no further argument... > it's certainly explained later, so perhaps that's good enough, and > there's no reason to spend further time on this here. You're right, it's not good to baldly state this SHOULD NOT without justification. We'll work to propose appropriate text. >> Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if"). >> Jeff is a bit uncomfortable with that because CN-ID is such a common >> practice, but I'm comfortable with it because of the hypothetical nature >> of the recommendation. He will review the earlier discussions on this >> topic before we finalize that text. > > I agree with you, Peter: I think the text is fine as you've given it. > >> The part of the text that you have not quoted does say that this >> practice is typically offered only to advanced users (and I don't think >> that Barry's mother counts as an advanced user). > > True; I'd missed that point, and I'm happy with the newer, scarier text. In this context, scary is good. :) > The only point I still want to push on is this one: > >>> When the connecting application is an interactive client, the source >>> domain name and service type MUST be provided by a human user (e.g. >>> when specifying the server portion of the user's account name on the >>> server or when explicitly configuring the client to connect to a >>> particular host or URI as in [SIP-LOC]) and MUST NOT be derived from >>> the user inputs in an automated fashion (e.g., a host name or domain >>> name discovered through DNS resolution of the source domain). This >>> rule is important because only a match between the user inputs (in >>> the form of a reference identifier) and a presented identifier >>> enables the client to be sure that the certificate can legitimately >>> be used to secure the connection. >>> >>> Does this mean that a client specifically designed for the "gumbo" >>> service can't automatically use the service type "gumbo", without the >>> user's involvement? Or that a client put out by example.net can't >>> assume a host name of services.example.net in the absence of user >>> input that says otherwise? >> >> IMHO that is a matter of user configuration, or user acknowledgement of >> a service agreement, so it falls under the text in this I-D about >> allowing the client to check the certificate against a DNS domain name >> that is explicitly associated with the source domain by means of user >> configuration. >> >>> Further, it's entirely reasonable for a program to have a user enter >>> something like "gmail", and have the client turn that into something >>> like "mail.google.com", deriving it from the user's input in an >>> automated fashion. Do we really want to forbid that sort of thing? >> >> Yes, we do, because although you happen to "just know" that >> mail.google.com is a legitimate DNS domain name to connect to when >> interacting with the gmail.com service, Barry's mother might not have >> that kind of knowledge and as a general rule it's a very bad idea to >> assume that it's just fine to connect to some domain at foo.com when >> interacting with a service at bar.com. However, service delegation is a >> difficult topic and there are ongoing discussions among various IETF >> participants about how to do service delegation securely; one thing I >> think we can safely say is that it's not the task of this I-D to solve >> the problem of secure service delegation. > > There's a distinction, here, between a protocol and a user interface > for configuration. My mother doesn't know whom to trust, except that > she knows that she (at least kinda-sorta) trusts the mail program > she's decided to use, and an entity she calls "gmail" (not > "google.com", not "gmail.com", but just "gmail"). She's relying to > the mail program's "easy configuration feature" to sort this out. > > The text I reviewed appeared to be saying normative things about what > client software MUST and MUST NOT do with regard to this sort of > configuration situation, which goes well beyond what the client > software is doing on the wire. Unless I'm mis-reading it, it's > explicitly saying that my client software is not allowed to do > something like this, for example: > 1. Ask the user, "What email service do you use?" > 2. Receive the answer "gmail" from the user. > 3. Auto-configure itself for the known gmail servers based only on > that user input. > > If I am, indeed, misreading it, please tell me... and perhaps tweak > the wording to make it less likely that someone else will misread it > the same way. > > Again, this is my only remaining quibble with the document, and, > again, it's a very good piece of work. Aha, thanks for the more detailed description of the scenario you had in mind. I see your point. We certainly don't mean the recommendations in this document to make life more difficult for your mother as she interacts with her auto-configuring email client! Off the top of my head I don't have a proposed solution, but I have added this to the list of open issues that Jeff and I need to discuss, and we'll be back with proposed text just as soon as we're able. Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 11:13:32 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F4DA3A6ABC; Wed, 22 Sep 2010 11:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.555 X-Spam-Level: X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qLy5VWFc+Alc; Wed, 22 Sep 2010 11:13:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 3AD193A6A30; Wed, 22 Sep 2010 11:13:29 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E3DE40074; Wed, 22 Sep 2010 12:18:50 -0600 (MDT) Message-ID: <4C9A4762.6090100@stpeter.im> Date: Wed, 22 Sep 2010 12:13:54 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jeffrey Hutzelman <jhutz@cmu.edu> References: <28916_1284500522_o8ELg0VD004136_AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <9F71309FD32D5FB6CE831823@minbar.fac.cs.cmu.edu> <4C9A428C.2030807@stpeter.im> <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu> In-Reply-To: <0D9B49B0DA9A5830D42DBAC0@lysithea.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: iesg@ietf.org, barryleiba@computer.org, IETF cert-based identity <certid@ietf.org>, tls@ietf.org, secdir@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 18:13:32 -0000 On 9/22/10 12:07 PM, Jeffrey Hutzelman wrote: > --On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre > <stpeter@stpeter.im> wrote: > >>> The second issue is the advice that the user should be allowed to accept >>> a certificate with a mismatched name only on a temporary basis. This is >>> almost certain to be the wrong thing to do; if a name mismatch is >>> acceptable, it's also not likely to change anytime soon, and requiring >>> the user to accept the certificate again in a later session just because >>> the client has restarted is just annoying with no security benefit. >> >> That's an interesting point. In feedback we received from implementers >> of interactive user agents (most browsers), we heard that at least some >> user agents do enforce a distinction between accepting an identity >> mismatch temporarily and accepting it permenantly. The security >> properties of that distinction did not come up in previous mailing list >> threads about this I-D, but your editorial team will do a bit more >> research and might return with proposed text changes. > > I have no issue with making that distinction, and indeed, many existing > user agents do so. I take issue only with the argument that user agents > should disallow the "permanent" option in the name of "security", when > doing so is in fact counterproductive. I had not previously considered the point, but I think you're right. >>> I think the advice in this paragraph is a little over-restrictive. What >>> should be prohibited is not automated rewriting, but automated rewriting >>> based on the use of insecure sources. RFC4120 has the following to say >>> on this subject, as it relates to Kerberos: >>> >>> >>> One can also rely on trusted third parties to make this >>> determination, but only when the data obtained from the third party >>> is suitably integrity-protected while resident on the third-party >>> server and when transmitted. Thus, for example, one should not rely >>> on an unprotected DNS record to map a host alias to the primary name >>> of a server, accepting the primary name as the party that one intends >>> to contact, since an attacker can modify the mapping and impersonate >>> the party. >> >> Thanks for the pointer to RFC 4120. We're looking into how to >> appropriate reference that in the next version of this spec. > > I'm not sure a reference is the best approach, since in fact we're not > talking here about Kerberos and that might just be confusing. But > borrowing some of the language might be appropriate. Yes, that's what I meant -- we shall probably engage in some creative borrowing of the concept, which might be worded similarly or differently (that's yet to be determined). Peter -- Peter Saint-Andre https://stpeter.im/ From stpeter@stpeter.im Wed Sep 22 11:18:28 2010 Return-Path: <stpeter@stpeter.im> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963D73A6A58; Wed, 22 Sep 2010 11:18:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN7CQuKlMNM9; Wed, 22 Sep 2010 11:18:27 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 771133A6A30; Wed, 22 Sep 2010 11:18:27 -0700 (PDT) Received: from moveme.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id C397140074; Wed, 22 Sep 2010 12:23:48 -0600 (MDT) Message-ID: <4C9A488D.20705@stpeter.im> Date: Wed, 22 Sep 2010 12:18:53 -0600 From: Peter Saint-Andre <stpeter@stpeter.im> User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.12) Gecko/20100914 Thunderbird/3.0.8 MIME-Version: 1.0 To: Jeffrey Hutzelman <jhutz@cmu.edu> References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> In-Reply-To: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF cert-based identity <certid@ietf.org>, secdir@ietf.org, Barry Leiba <barryleiba.mailing.lists@gmail.com>, IETF discussion list <ietf@ietf.org>, tls@ietf.org Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 18:18:28 -0000 On 9/22/10 12:14 PM, Jeffrey Hutzelman wrote: > --On Wednesday, September 22, 2010 12:34:50 PM -0400 Barry Leiba > <barryleiba.mailing.lists@gmail.com> wrote: > >> There's a distinction, here, between a protocol and a user interface >> for configuration. My mother doesn't know whom to trust, except that >> she knows that she (at least kinda-sorta) trusts the mail program >> she's decided to use, and an entity she calls "gmail" (not >> "google.com", not "gmail.com", but just "gmail"). She's relying to >> the mail program's "easy configuration feature" to sort this out. >> >> The text I reviewed appeared to be saying normative things about what >> client software MUST and MUST NOT do with regard to this sort of >> configuration situation, which goes well beyond what the client >> software is doing on the wire. Unless I'm mis-reading it, it's >> explicitly saying that my client software is not allowed to do >> something like this, for example: >> 1. Ask the user, "What email service do you use?" >> 2. Receive the answer "gmail" from the user. >> 3. Auto-configure itself for the known gmail servers based only on >> that user input. > > I think that's reasonable behavior _if_ the mail client knows that > "gmail" is "mail.google.com". What's _not_ reasonable is for it to > arbitrarily transform "gmail" into a domain by adding ".com", then look > up "gmail.com" and see that it is an alias for "mail.google.com" and not > only follow the (insecure) alias to mail.google.com but also use it to > decide that "mail.google.com" is an appropriate name to find in a > certificate. > > If your mother's mail client does that, then all I have to do to steal > her password is convince said client that "gmail.com" is actually an > alias for "stealgmailpassword.attacker.org". In my experience, some user agents have interface elements such as a drop-down box that lists popular service providers, and the account configuration wizard behaves differently (e.g., asks for different information) depending on which popular service provider the user chooses. Peter -- Peter Saint-Andre https://stpeter.im/ From ark@eltex.net Wed Sep 22 11:31:26 2010 Return-Path: <ark@eltex.net> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A453A6A92; Wed, 22 Sep 2010 11:31:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lInLHlAxs-2l; Wed, 22 Sep 2010 11:31:25 -0700 (PDT) Received: from lebedev-225.itcwin.com (unknown [88.201.200.225]) by core3.amsl.com (Postfix) with ESMTP id DC8803A6A8E; Wed, 22 Sep 2010 11:31:24 -0700 (PDT) Received: from lebedev-225.itcwin.com (ark@localhost.my.domain [127.0.0.1]) by lebedev-225.itcwin.com (8.14.3/8.14.3) with ESMTP id o8MIVhb2011722; Wed, 22 Sep 2010 22:31:43 +0400 (MSD) Received: (from ark@localhost) by lebedev-225.itcwin.com (8.14.3/8.14.3/Submit) id o8MIVhdV008046; Wed, 22 Sep 2010 22:31:43 +0400 (MSD) X-Authentication-Warning: lebedev-225.itcwin.com: ark set sender to ark@eltex.net using -f Date: Wed, 22 Sep 2010 22:31:43 +0400 From: ArkanoiD <ark@eltex.net> To: Jeffrey Hutzelman <jhutz@cmu.edu> Message-ID: <20100922183143.GA23200@eltex.net> References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF discussion list <ietf@ietf.org>, secdir@ietf.org, Barry Leiba <barryleiba.mailing.lists@gmail.com>, IETF cert-based identity <certid@ietf.org>, tls@ietf.org, Peter Saint-Andre <stpeter@stpeter.im> Subject: Re: [secdir] [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 18:31:26 -0000 BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate for mail.google.com. But i've yet to see any web browser to complain! Where is the magic? From marsh@extendedsubset.com Wed Sep 22 12:37:33 2010 Return-Path: <marsh@extendedsubset.com> X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7DDEB3A69A8; Wed, 22 Sep 2010 12:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.468 X-Spam-Level: *** X-Spam-Status: No, score=3.468 tagged_above=-999 required=5 tests=[AWL=-5.093, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_73=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMS6iU9eKXOT; Wed, 22 Sep 2010 12:37:32 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id CA5183A697E; Wed, 22 Sep 2010 12:37:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OyV8e-000FOA-LT; Wed, 22 Sep 2010 19:37:57 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 4F2C3601B; Wed, 22 Sep 2010 19:37:54 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/McQjaZjnfhlHi92k0Dhlm/+vqXeVrxMo= Message-ID: <4C9A5B13.1040802@extendedsubset.com> Date: Wed, 22 Sep 2010 14:37:55 -0500 From: Marsh Ray <marsh@extendedsubset.com> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: ArkanoiD <ark@eltex.net> References: <AANLkTin6qXBOEJheaG8+SU=3k63Ed+3qXvoLHF5_hb6x@mail.gmail.com> <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> In-Reply-To: <20100922183143.GA23200@eltex.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF discussion list <ietf@ietf.org>, secdir@ietf.org, Barry Leiba <barryleiba.mailing.lists@gmail.com>, IETF cert-based identity <certid@ietf.org>, tls@ietf.org Subject: Re: [secdir] [TLS] [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate <secdir.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/secdir> List-Post: <mailto:secdir@ietf.org> List-Help: <mailto:secdir-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 22 Sep 2010 19:37:33 -0000 On 09/22/2010 01:31 PM, ArkanoiD wrote: > BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate > for mail.google.com. But i've yet to see any web browser to complain! Where is the magic? Seems totally relevant to me. Going to https://gmail.com/ I get some kind of redirection to https://www.google.com/accounts/ServiceLogin... I can confirm the silent redirect behavior on FF, an associate reports it on IE9. I tried IE8 but get the expected "cert was issued for a different website's address" error. Hopefully I'm overlooking something simple, but at first glance it would seem like either of these two conditions are true: 1. Multiple vendors are putting some kind of override table in their browsers with an entry for gmail.com. 2. Browsers are running script from badly authenticated sources. So what does gmail.com have in this situation that an attacker couldn't obtain for phonygmail.com? - Marsh marsh@lamb:/tmp$ dig -t any gmail.com ; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091 ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2 ;; QUESTION SECTION: ;gmail.com. IN ANY ;; ANSWER SECTION: gmail.com. 300 IN A 74.125.227.22 gmail.com. 300 IN A 74.125.227.21 gmail.com. 300 IN A 74.125.227.24 gmail.com. 300 IN A 74.125.227.23 gmail.com. 86400 IN NS ns4.google.com. gmail.com. 86400 IN NS ns1.google.com. gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 1427981 21600 3600 1209600 300 gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" ;; ADDITIONAL SECTION: ns4.google.com. 85092 IN A 216.239.38.10 ns1.google.com. 85092 IN A 216.239.32.10 ;; Query time: 54 msec ;; SERVER: 192.168.1.3#53(192.168.1.3) ;; WHEN: Wed Sep 22 14:26:29 2010 ;; MSG SIZE rcvd: 330 marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 ... subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA ... --- GET / HTTP/1.0 HTTP/1.0 200 OK Date: Wed, 22 Sep 2010 19:31:43 GMT Expires: -1 Cache-Control: private, max-age=0 Content-Type: text/html; charset=ISO-8859-1 Set-Cookie: PREF=ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com Set-Cookie: NID=39=nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i-CvhRU1DrDDYvExygPnpew69GRLaWZeI0; expires=Thu, 24-Mar-2011 19:31:43 GMT; path=/; domain=.google.com; HttpOnly Server: gws X-XSS-Protection: 1; mode=block <!doctype html><html><head><meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"><title>Google


Go to classic Google.
X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D89D83A685B; Wed, 22 Sep 2010 12:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.56 X-Spam-Level: *** X-Spam-Status: No, score=3.56 tagged_above=-999 required=5 tests=[AWL=-4.401, BAYES_50=0.001, FB_WORD2_END_DOLLAR=3.294, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, J_CHICKENPOX_25=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_53=0.6, SARE_URI_EQUALS=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYA6RkyatneU; Wed, 22 Sep 2010 12:42:39 -0700 (PDT) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) by core3.amsl.com (Postfix) with ESMTP id 075393A6B41; Wed, 22 Sep 2010 12:42:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=mRjYM1wYA7MobX4v6rYGypyk4Zaeg2A5fscVcTwbPKUfyOK9emxCOu44dYnFq6E5; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.24] (helo=mswamui-andean.atl.sa.earthlink.net) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OyVDd-00018h-Fk; Wed, 22 Sep 2010 15:43:05 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Wed, 22 Sep 2010 15:43:05 -0400 Message-ID: <20847695.1285184585494.JavaMail.root@mswamui-andean.atl.sa.earthlink.net> Date: Wed, 22 Sep 2010 14:43:05 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Marsh Ray , ArkanoiD Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688b06bb0baee4cfae0c770b9a8809f9c8b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.24 X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org Subject: Re: [secdir] [TLS] [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 19:42:41 -0000 Marsh and all, Thanks for confirming what I have seen far to often in respect to gmail.com. -----Original Message----- >From: Marsh Ray >Sent: Sep 22, 2010 2:37 PM >To: ArkanoiD >Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, Jeffrey Hutzelman >Subject: Re: [TLS] [certid] [secdir] secdir review of draft-saintandre-tls-server-id-check-09 > >On 09/22/2010 01:31 PM, ArkanoiD wrote: >> BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate >> for mail.google.com. But i've yet to see any web browser to complain! Where is the magic? > >Seems totally relevant to me. > >Going to https://gmail.com/ I get some kind of redirection to >https://www.google.com/accounts/ServiceLogin... > >I can confirm the silent redirect behavior on FF, an associate reports >it on IE9. I tried IE8 but get the expected "cert was issued for a >different website's address" error. > >Hopefully I'm overlooking something simple, but at first glance it would >seem like either of these two conditions are true: > >1. Multiple vendors are putting some kind of override table in their >browsers with an entry for gmail.com. > >2. Browsers are running script from badly authenticated sources. > >So what does gmail.com have in this situation that an attacker couldn't >obtain for phonygmail.com? > >- Marsh > > >marsh@lamb:/tmp$ dig -t any gmail.com > >; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com >;; global options: +cmd >;; Got answer: >;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091 >;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2 > >;; QUESTION SECTION: >;gmail.com. IN ANY > >;; ANSWER SECTION: >gmail.com. 300 IN A 74.125.227.22 >gmail.com. 300 IN A 74.125.227.21 >gmail.com. 300 IN A 74.125.227.24 >gmail.com. 300 IN A 74.125.227.23 >gmail.com. 86400 IN NS ns4.google.com. >gmail.com. 86400 IN NS ns1.google.com. >gmail.com. 86400 IN SOA ns1.google.com. dns-admin.google.com. 1427981 >21600 3600 1209600 300 >gmail.com. 3600 IN MX 40 alt4.gmail-smtp-in.l.google.com. >gmail.com. 3600 IN MX 5 gmail-smtp-in.l.google.com. >gmail.com. 3600 IN MX 20 alt2.gmail-smtp-in.l.google.com. >gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com" > >;; ADDITIONAL SECTION: >ns4.google.com. 85092 IN A 216.239.38.10 >ns1.google.com. 85092 IN A 216.239.32.10 > >;; Query time: 54 msec >;; SERVER: 192.168.1.3#53(192.168.1.3) >;; WHEN: Wed Sep 22 14:26:29 2010 >;; MSG SIZE rcvd: 330 > > > >marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443 >... >subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com >issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA >... >--- >GET / HTTP/1.0 > >HTTP/1.0 200 OK >Date: Wed, 22 Sep 2010 19:31:43 GMT >Expires: -1 >Cache-Control: private, max-age=0 >Content-Type: text/html; charset=ISO-8859-1 >Set-Cookie: >PREF=ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; >expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com >Set-Cookie: >NID=39=nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i-CvhRU1DrDDYvExygPnpew69GRLaWZeI0; >expires=Thu, 24-Mar-2011 19:31:43 GMT; path=/; domain=.google.com; HttpOnly >Server: gws >X-XSS-Protection: 1; mode=block > >content="text/html; >charset=ISO-8859-1">Googlebgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000 >onload="document.f.q.focus();if(document.images)new >Image().src='/images/srpr/nav_logo14.png'" >

id=lgpd>
height=110 border=0>
Go to href="http://www.google.com/">classic Google.action="/search" name=f>
>_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From marsh@extendedsubset.com Wed Sep 22 12:57:08 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 933FF3A6A3F; Wed, 22 Sep 2010 12:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[AWL=0.578, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJ9EcCwK8bNJ; Wed, 22 Sep 2010 12:57:05 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 6C5CD3A685B; Wed, 22 Sep 2010 12:57:05 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1OyVRa-000AJk-7L; Wed, 22 Sep 2010 19:57:30 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 632806018; Wed, 22 Sep 2010 19:57:27 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19oex24i/q18w/PsQMTFPY8Pp08N9CCoTs= Message-ID: <4C9A5FA8.7050605@extendedsubset.com> Date: Wed, 22 Sep 2010 14:57:28 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: ArkanoiD References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> <4C9A5B13.1040802@extendedsubset.com> In-Reply-To: <4C9A5B13.1040802@extendedsubset.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org Subject: Re: [secdir] [TLS] [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 19:57:08 -0000 On 09/22/2010 01:31 PM, ArkanoiD wrote: > BTW, slightly offtopic here: whenever i connect to gmail.com, i get > certificate for mail.google.com. But i've yet to see any web browser > to complain! Where is the magic? On 09/22/2010 02:37 PM, Marsh Ray wrote: > > Hopefully I'm overlooking something simple, but at first glance it would > seem like either of these two conditions are true: > > 1. Multiple vendors are putting some kind of override table in their > browsers with an entry for gmail.com. This search http://mxr.mozilla.org/mozilla1.9.2/search?string=[^%40]gmail.com®exp=1&hitlimit=&tree=mozilla1.9.2 Doesn't return any hits. That search page is a little tricky though. It kept wanting to change my "^@" to "\0"! :-) Which suggests that: > 2. Browsers are running script from badly authenticated sources. - Marsh From ayourtch@cisco.com Wed Sep 22 15:32:27 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3A63A6918; Wed, 22 Sep 2010 15:32:27 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uDE8KHUmBcBt; Wed, 22 Sep 2010 15:32:24 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id 8AD2C3A6835; Wed, 22 Sep 2010 15:32:24 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o8MMT4Pa027524; Thu, 23 Sep 2010 00:29:04 +0200 (CEST) Received: from sweet-brew-5.cisco.com (sweet-brew-5.cisco.com [144.254.10.206]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o8MMSxnw014263; Thu, 23 Sep 2010 00:29:00 +0200 (CEST) Date: Thu, 23 Sep 2010 00:28:59 +0200 (CEST) From: Andrew Yourtchenko To: Fernando Gont In-Reply-To: <4C91C9EE.1000200@gont.com.ar> Message-ID: References: <2234.1284367866.672579@puncture> <4C91C9EE.1000200@gont.com.ar> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: draft-ietf-tcpm-urgent-data.all@tools.ietf.org, Apps Area Review List , The IESG , Security Area Directorate Subject: Re: [secdir] SecDir/Apps Review of draft-ietf-tcpm-urgent-data-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 22:32:27 -0000 Hi David, sorry for the delay with the reply - I was off the grid for a couple of weeks due to vacation. On Thu, 16 Sep 2010, Fernando Gont wrote: [snip] >> The Cisco-PIX reference does not describe the TCP Urgent behaviour >> except by implication (it mentions adding rules to allow its use for >> TELNET and FTP-PI, but that's it). I have a personal distaste for >> product placement in RFCs, and would prefer that this reference pointed >> at least at a Cisco paper describing default behaviour, etc. >> I comment on this below at [*] >> As an aside, the Cisco instructions actually show the user how to enable >> urgent data on FTP-DTP, rather than FTP-PI, which is incorrect. Could you unicast me the URL where you saw it, so I can work to get it fixed ? The ones in the command reference for the ASA talk about tcp/513, which is rlogin, e.g.: http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/uz.html#wp1591004 > > I leave this one for Andrew to answer ;-) > > I'd just note that the reason for which Cisco Pix is referenced is > probably because it's a widely deployed device that scrubs urgent > indications. (i.e., "this thing is widely deployed"). > Exactly. [*] - given the contents of the command reference above - would it correspond to what you had in mind if we give e.g. the link above to one of the command references ? > >> Specific Recommendations: >> >> - An informative reference to FTP and TELNET, noting how and why the URG >> pointer is used, would make it more obvious what is lost here. > > Would the re-written text I indicated above do, or do you think we > should get into the specifics of what the urgent mechanism is used for > in FTP and telnet? > > > >> - A more detailed description of SeolMa, and its implications, would be >> useful, and I think required in the Security Considerations section. > > Please let me know if the change indicated above would do. > > >> - I feel that further consideration of the proposed solution to SeolMa >> is warranted. > > You mean what we propose to fix this NIDS evasion technique? SeolMa was in fact one of the initial triggers of this work, though we deemed the NIDS problem as not something practically solvable in a clean way. I'll include the logic below: First the "classic" NIDS: The setup is as follows: Alice --+-- Eva | Nick Eva is trying to exploit Alice using the SeolMa technique. Regardless of the setup, Nick can not do a lot anyway to help - maybe send a reset based on some heuristic, however the damage is possibly already done, might depend on the timing. So we consider a more interesting case of an "inline" setup: Alice -- Nick -- Eva Here, Nick can have the power to reliably do something. But he needs to consider the following degrees of freedom that Alice has: * /proc/sys/net/ipv4/tcp_stdurg setting. This alters the behaviour box-wide, and Nick would need to know the value of this setting (manual configuration), to understand in which of the two ways to interpret the data. * The timing also plays a role, so Nick would need to somehow normalize the timing of the packets before passing them on to Alice. This can either impact the TCP connection itself (if done with bigger safety margins), or be again unreliable. Or the packets need to be sanitized. * Meantime, Alice might have learned about the SO_OOBINLINE and added that to the code of the next version of the application - which gives another point of manual configuration for Nick. Based on that, there are some approaches to tackling this: * Nick manually configures his behavior to match the Alice's and then does the analysis based on that, trying to guess what Alice's stack would do - and then pass the "sanitized" packets to Alice. ==> while technically this looks sound, I think expecting the end user en masse to know about the details about SO_OOBINLINE/tcp_stdurg is impractical. Even if the "security" folks might know it, in a lot of organizations they are different from "application" folks - the latter not possessing the low-level transports knowledge. Side effect of this is the increase of the complexity of the task that Nick would do, therefore increasing the chances of it not emulating the Alice's behaviour correctly. * Nick can evade the evasion by clearing the URG flag - breaking the assumptions of Eve about the processing of the data by Alice. ==> This requires zero configuration, creates loud noise in the logs of Alice due to incorrect input, but breaks the apps that rely on URG mechanism during the legitimate operation. * Nick can be aggressive on those streams that he knows would not use urgent mechanism (e.g. HTTP), and try to handle the ones that may use it, in a more graceful manner. ==> This looks like a possibly ideal scenario, however, from the security point of view for the applications that use the urgent mechanism, it would need to be treated as the first one - i.e. require explicit manual configuration. So the approach with simply clearing the URG looks like the simplest of all from several viewpoints (reliability, and maintenance overhead). Hopefully this gives more details, would be very useful to know your opinion on the above. Thank you very much! kind regards, andrew > > Thanks! > > Kind regards, > -- > Fernando Gont > e-mail: fernando@gont.com.ar || fgont@acm.org > PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 > > > > From cjbc@it.uc3m.es Wed Sep 22 15:38:22 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80C6B28C0F6; Wed, 22 Sep 2010 15:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.634 X-Spam-Level: X-Spam-Status: No, score=-5.634 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hn0anlLzBHq8; Wed, 22 Sep 2010 15:38:20 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 0F39F28C0E8; Wed, 22 Sep 2010 15:38:19 -0700 (PDT) X-uc3m-safe: yes Received: from [IPv6:::1] (luciernaga.it.uc3m.es [163.117.140.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp02.uc3m.es (Postfix) with ESMTP id 6DEDF70E938; Thu, 23 Sep 2010 00:38:41 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Donald Eastlake In-Reply-To: References: Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-C5bzuIDPP8pcAO9ns8Rk" Organization: Universidad Carlos III de Madrid Date: Thu, 23 Sep 2010 00:38:52 +0200 Message-ID: <1285195132.4045.800.camel@acorde.it.uc3m.es> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17660.002 X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: pthubert@cisco.com, Francis Dupont , secdir@ietf.org, julienl@qualcomm.com, Ralph Droms , Wassim.Haddad@ericsson.com, iesg@ietf.org, marcelo@it.uc3m.es Subject: Re: [secdir] draft-ietf-mext-nemo-pd-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2010 22:38:22 -0000 --=-C5bzuIDPP8pcAO9ns8Rk Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi Donald, Thanks for the comments. See below inline. On Sun, 2010-09-19 at 23:42 -0400, Donald Eastlake 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. Document editors and WG chairs should treat > these comments just like any other last call comments. >=20 > This document specifies how to delegate IPv6 prefixes to a Mobile > Router in a Mobile Network. >=20 > It has a reasonably extensive Security Considerations section and > appears to appropriately specify protective measures against plausible > threats. In particular, when the Mobile Router is away from home, it > mandates the use of IPsec a la MIPv6. Possibly someone more familiar > with IPsec should look at the specified Security Policy Database and > Security Association Database. >=20 > Trivia: >=20 > Section 3.1, page 5, "...currently used by the is about to expire..." > ? perhaps "...by the Mobile Node..." Thanks, it should say "by the Mobile Router". >=20 > "an Mobile" -> "a Mobile" Right. >=20 > Various acronyms, such as BU, HoA, while usually explained when first > used, are missing from Section 2. HoA is not explained at all. Even > better would be to vastly reduce the overuse of acronyms throughout > this document. Agree. This has been pointed out by other reviewers and we'll improve this. Thanks again. Kind Regards, Carlos >=20 > Thanks, > Donald --=20 Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-C5bzuIDPP8pcAO9ns8Rk Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iEYEABECAAYFAkyahXwACgkQNdy6TdFwT2dzRACfdLcHMpM1FDhDrJjfZUHr0xMy 2uYAoM5qGAlX4ieKJnGiCNYGcY4elHaR =uHvv -----END PGP SIGNATURE----- --=-C5bzuIDPP8pcAO9ns8Rk-- From marsh@extendedsubset.com Thu Sep 23 11:33:37 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC083A6943; Thu, 23 Sep 2010 11:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.05 X-Spam-Level: X-Spam-Status: No, score=-2.05 tagged_above=-999 required=5 tests=[AWL=0.549, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVmtvTvX55eH; Thu, 23 Sep 2010 11:33:31 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 735E43A69D0; Thu, 23 Sep 2010 11:33:31 -0700 (PDT) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1OyqcI-00039r-Kp; Thu, 23 Sep 2010 18:33:58 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7388D601A; Thu, 23 Sep 2010 18:33:56 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18hrXgaUBVAOwL33tya7/0QAtzYvVEk96E= Message-ID: <4C9B9D92.1060406@extendedsubset.com> Date: Thu, 23 Sep 2010 13:33:54 -0500 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.12) Gecko/20100915 Thunderbird/3.0.8 MIME-Version: 1.0 To: "Richard L. Barnes" References: <4C9A27D0.7030909@stpeter.im> <17472_1285173298_o8MGYvUB005723_AANLkTinAdE0qVxqUEBNe3ZWCry856bresv+x2Ga7Urju@mail.gmail.com> <86E28295D464B450ECA5B1D5@lysithea.fac.cs.cmu.edu> <20100922183143.GA23200@eltex.net> <4C9A5B13.1040802@extendedsubset.com> <93037048-4609-40F7-BCC0-D635301E4042@bbn.com> In-Reply-To: <93037048-4609-40F7-BCC0-D635301E4042@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 24 Sep 2010 08:05:27 -0700 Cc: IETF discussion list , secdir@ietf.org, Barry Leiba , IETF cert-based identity , tls@ietf.org, ArkanoiD Subject: Re: [secdir] [TLS] [certid] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Sep 2010 18:33:37 -0000 On 09/23/2010 01:10 PM, Richard L. Barnes wrote: > There is no black magic here, only the magic of the TLS server_name > extension. If the client provides server_name=gmail.com, the server > provides a gmail.com cert, otherwise it defaults to mail.google.com. > Your browser is following two secure delegations before it lands at > www.google.com (gmail.com -> mail.google.com -> www.google.com). I'd not even considered SNI. > My guess based on the anecdotes in the thread is that IE8 doesn't > support it. Not IE8, but the pre-Vista Windows I was testing it on that doesn't do extensions by default. Which is why I'd not considered that gmail would depend on SNI for its operation. I'd forgotten that this is Google we were talking about and not any other company in the world that would put support for MSIE on Windows XP ahead of protocol standards. :-) > (You should also be more careful about your HTTP emulation! "A client > MUST include a Host header field in all HTTP/1.1 request messages > .") Yep, that's why I requested HTTP/1.0. - Marsh From weiler@watson.org Fri Sep 24 18:34:36 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A1F33A6A90 for ; Fri, 24 Sep 2010 18:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrsJckbPodvl for ; Fri, 24 Sep 2010 18:34:35 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 038833A6A13 for ; Fri, 24 Sep 2010 18:34:34 -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 o8P1Z6Jm004964 for ; Fri, 24 Sep 2010 21:35:06 -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 o8P1Z6vJ004961 for ; Fri, 24 Sep 2010 21:35:06 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Fri, 24 Sep 2010 21:35:06 -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, 24 Sep 2010 21:35:07 -0400 (EDT) Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 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: Sat, 25 Sep 2010 01:34:36 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview Jeffrey Hutzelman is next in the rotation. For telechat 2010-10-07 Reviewer LC end Draft Steve Hanna T - draft-ietf-csi-dhcpv6-cga-ps-04 Love Hornquist-Astrand T 2010-10-07 draft-ietf-tsvwg-sctp-chunk-flags-01 David McGrew T 2010-08-05 draft-ietf-pce-manageability-requirements-10 For telechat 2010-10-21 Reviewer LC end Draft Shawn Emery T 2010-10-11 draft-arkko-townsley-coexistence-04 Phillip Hallam-Baker T 2010-10-11 draft-zeilenga-ldap-dontusecopy-08 Last calls and special requests: Reviewer LC end Draft Rob Austein 2010-09-27 draft-ietf-grow-bgp-graceful-shutdown-requirements-04 Alan DeKok 2010-09-27 draft-ietf-v6ops-cpe-simple-security-12 Stephen Farrell 2010-09-28 draft-ietf-avt-rapid-acquisition-for-rtp-15 Tobias Gondrom 2010-09-27 draft-ietf-mpls-ldp-igp-sync-bcast-04 Dan Harkins 2010-10-04 draft-ietf-dime-capablities-update-05 Sam Hartman 2010-10-04 draft-ietf-netconf-with-defaults-11 Paul Hoffman 2010-10-04 draft-ietf-storm-ifcp-ipn133-updates-02 Love Hornquist-Astrand 2010-07-23 draft-ietf-pkix-ocspagility-09 David McGrew - draft-ietf-ecrit-framework-11 Eric Rescorla 2010-06-21 draft-ietf-simple-msrp-acm-09 Tom Yu 2010-09-27 draft-gundavelli-v6ops-l2-unicast-04 Larry Zhu 2010-09-30 draft-lundberg-app-tei-xml-03 Glen Zorn 2010-09-16 draft-ietf-l3vpn-mvpn-spmsi-joins-01 From mrex@sap.com Fri Sep 24 13:29:29 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CD333A6A8B; Fri, 24 Sep 2010 13:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.817 X-Spam-Level: X-Spam-Status: No, score=-9.817 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLtWF4w-rNkA; Fri, 24 Sep 2010 13:29:28 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 0936E3A69EE; Fri, 24 Sep 2010 13:29:27 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o8OKTr1A002212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 22:29:53 +0200 (MEST) From: Martin Rex Message-Id: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> To: stpeter@stpeter.im (Peter Saint-Andre) Date: Fri, 24 Sep 2010 22:29:52 +0200 (MEST) In-Reply-To: <4C9A428C.2030807@stpeter.im> from "Peter Saint-Andre" at Sep 22, 10 11:53:16 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Scanner: Virus Scanner virwal08 X-SAP: out X-Mailman-Approved-At: Fri, 24 Sep 2010 18:36:44 -0700 Cc: secdir@ietf.org, certid@ietf.org, iesg@ietf.org, tls@ietf.org Subject: Re: [secdir] [TLS] secdir review of X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: mrex@sap.com List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 20:29:29 -0000 Peter Saint-Andre wrote: > > For context, the "quoted advice" is mostly a description of current > usage in some existing user agents. Incorporating Barry's suggestions, > that text currently reads as follows in our working copy: > > Security Note: Some existing interactive user agents give advanced > users the option of proceeding despite an identity mismatch. > Although this behavior can be appropriate in certain specialized > circumstances, in general it ought to be exposed only to advanced > users and even then needs to be handled with extreme caution, for > example by first encouraging even an advanced user to terminate > the connection and, if the advanced user chooses to proceed > anyway, by forcing the user to view the entire certification path > and only then allowing the user to accept the certificate on a > temporary basis (i.e., for this connection attempt and all > subsequent connection attempts for the life of the application > session, but not for connection attempts during future application > sessions). This whole paragraph is evil and completely wrong. It's bad enough that the web browser crowds replaced a useful option and important security feature with an extremely evil scary page. The IETF should definitely not put this non-sense into a BCP or standard. Offering to end-users, in a single-time-only leap-of-faith approach similar to what SSH has been successfully doing since its invention to memorize the peers certificate is magnitudes more secure than the endpoint identification linking to one of a hundred trust anchors, provisionally preconfigured by your software supplier. The IETF, its standards & BCPs ought to stand clear from recommendations that impair the usability or incur additional cost for using the TLS technology between components of home networks. The scary-pages presented by newer Browsers and the UI suggestions in the quoted paragraph amounts to turning the entire TLS technology into "nagware" for commercial pre-trusted CAs. The most recent browser scary-pages are worse than most nagware. I'm not intimidated on the initial install of my DSL-router, neither when logging in to the webadmin page for the first time, nor when configuring my WPA2-PSK key. Why on earth am I intimidated so badly when I activate TLS for the webadmin UI of my home NAS and connect to it with my browser for the first time? Can't we do better than specifying the use of HTTP over TLS instead of HTTP-only to access devices on my home network should not be allowed to users that are not "advanced", and even those must be badly intimidated when they try? Even when servers use server certs from commercial pre-trusted CAs, the options for end users to manually confirm the server cert to have it cached/memorized and verified on future visits will significantly improve the security for the user, because it protects from later subversion of (the issuing procedures) of any of the thousands CAs signed by any of the hundred preconfigured trust anchors as well as bugs such as the OID-integer wraparound and NUL-character in Hostname. -Martin From rrelyea@redhat.com Fri Sep 24 15:00:18 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 399603A6AA7; Fri, 24 Sep 2010 15:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.008 X-Spam-Level: X-Spam-Status: No, score=-110.008 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH79sicS8fHQ; Fri, 24 Sep 2010 15:00:17 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by core3.amsl.com (Postfix) with ESMTP id 169963A6A9C; Fri, 24 Sep 2010 15:00:16 -0700 (PDT) Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o8OM0ihY007067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 24 Sep 2010 18:00:44 -0400 Received: from [10.14.54.215] (dhcp-215.sjc.redhat.com [10.14.54.215]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o8OM0efJ003448; Fri, 24 Sep 2010 18:00:40 -0400 Message-ID: <4C9D1F8E.70608@REDHAT.COM> Date: Fri, 24 Sep 2010 15:00:46 -0700 From: Robert Relyea User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10) Gecko/20100621 Fedora/3.0.5-1.fc13 Lightning/1.0b2pre Thunderbird/3.0.5 MIME-Version: 1.0 To: mrex@sap.com References: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> In-Reply-To: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070600000007040902010805" X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Mailman-Approved-At: Fri, 24 Sep 2010 18:36:44 -0700 Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, Peter Saint-Andre Subject: Re: [secdir] [TLS] secdir review of X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 22:00:18 -0000 This is a cryptographically signed message in MIME format. --------------ms070600000007040902010805 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 09/24/2010 01:29 PM, Martin Rex wrote: > Peter Saint-Andre wrote: > =20 >> For context, the "quoted advice" is mostly a description of current >> usage in some existing user agents. Incorporating Barry's suggestions,= >> that text currently reads as follows in our working copy: >> >> Security Note: Some existing interactive user agents give advanc= ed >> users the option of proceeding despite an identity mismatch. >> Although this behavior can be appropriate in certain specialized= >> circumstances, in general it ought to be exposed only to advance= d >> users and even then needs to be handled with extreme caution, fo= r >> example by first encouraging even an advanced user to terminate >> the connection and, if the advanced user chooses to proceed >> anyway, by forcing the user to view the entire certification pat= h >> and only then allowing the user to accept the certificate on a >> temporary basis (i.e., for this connection attempt and all >> subsequent connection attempts for the life of the application >> session, but not for connection attempts during future applicati= on >> sessions). >> =20 > This whole paragraph is evil and completely wrong. > > It's bad enough that the web browser crowds replaced a useful option > and important security feature with an extremely evil scary page. > =20 No, this paragraph is exactly what should happen. Click through dialogs are demonsterably useless. They train users to ignore them. The only place for them is if you decide that validation is not necessary. > Offering to end-users, in a single-time-only leap-of-faith approach sim= ilar > to what SSH has been successfully doing since its invention to memorize= > the peers certificate is magnitudes more secure than the endpoint > identification linking to one of a hundred trust anchors, provisionally= > preconfigured by your software supplier. > =20 SSH is good for small numbers of point to point connections where the user controls both sides. SSH model is not appropriate for the general population connection to millions of webservers. That is why SSH is used extensively in admin deployments (where the admin controls both machines) and is not used for e-commerce. If you want that semantic use SSH. If you want security for the masses, use SSL (with full PKI). [ case where SSL is being used for an SSH use case deleted] bob --------------ms070600000007040902010805 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIV7DCC Bv8wggXnoAMCAQICAwCrKTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBMB4XDTA5MTAxNDAwMDAwMVoXDTEwMTAxNDIwNTQyMVowbjEeMBwGA1UE ChMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMSkwJwYDVQQDEyBTdGFydENvbSBGcmVlIENlcnRp ZmljYXRlIE1lbWJlcjEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRoYXQuY29tMIIBIjAN BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAx9dBmw8V94Rx84iwE5RpiO+uHKS5e91CHnKf JsbEOzPxS7Hgizt78ratBbhkudQ7bJIH1o9nh0Q5c/LdOlWUF1Jn+3+JNGvs6h/vlmfCYGPK TZpUbwPm8Rmik+bDNlAOUkDieZHfUg8HOdGrqvp1prqqwLMzgovi5YiETf28SO9kxNqjkbBL VxsBlHrnjG1dmn8jAYZ1XPctXMEsHV+2EISDOPYWl/CE2jt7km6Hkxq7D6p/z8Ef9Zn/uZ1z onthvoDp+BJOIIa6s68r9rLGNtAQ5/OtxXKpk6Cz5SAUgZIo0p2tNyQ2hFy8ojUZm2hNKVfu 6lN9DcSU0sri8I0S1QIDAQABo4IDhTCCA4EwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBT6fisKv/TEZ8c96u/L+x4d RtrwdjCBqAYDVR0jBIGgMIGdgBRTcu2SnODaywFcfH6WNU7y1LhRgqGBgaR/MH0xCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9u IEF1dGhvcml0eYIBDTAdBgNVHREEFjAUgRJycmVseWVhQHJlZGhhdC5jb20wggFCBgNVHSAE ggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNz bC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRDb20gTHRk LjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0 aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8E XDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMCugKaAn hiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9j bGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1 Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAOBrTD2DJvI0rP6phlUjV0JU6owP2XLQ2fZZ42J LHqfJ+yJWqpprzbHK7c7oJjy/TlNUQzFQZvtQM0WAcopsOzvqeXyB9lt6Zqq1ULMG9s5yMM0 rq/dpYFE2ju9WY8+7962iSkqGmMwrq9ZwO8J37zmMDS3ifw3/n3/Ns1t7MK6tanzkugScuW9 TQr/zQNNanLQmeuvU6Fbru6UFZI6c1qW0G4B1ptfTEQiAQ+E7PdIdjI9SYd24uU6/OdPlGrV tgl0UUnwLuCwA+D84xtc4+TjkLFxuqKCTi0NDONzosPzrNGJ7Kcau5bqV5AUxVz6bUifqQ3a X7xgD7Vq0EGCCK4wggb/MIIF56ADAgECAgMAqykwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRh bCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1h cnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0wOTEwMTQwMDAwMDFaFw0xMDEwMTQyMDU0 MjFaMG4xHjAcBgNVBAoTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEpMCcGA1UEAxMgU3RhcnRD b20gRnJlZSBDZXJ0aWZpY2F0ZSBNZW1iZXIxITAfBgkqhkiG9w0BCQEWEnJyZWx5ZWFAcmVk aGF0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMfXQZsPFfeEcfOIsBOU aYjvrhykuXvdQh5ynybGxDsz8Uux4Is7e/K2rQW4ZLnUO2ySB9aPZ4dEOXPy3TpVlBdSZ/t/ iTRr7Oof75ZnwmBjyk2aVG8D5vEZopPmwzZQDlJA4nmR31IPBznRq6r6daa6qsCzM4KL4uWI hE39vEjvZMTao5GwS1cbAZR654xtXZp/IwGGdVz3LVzBLB1fthCEgzj2FpfwhNo7e5Juh5Ma uw+qf8/BH/WZ/7mdc6J7Yb6A6fgSTiCGurOvK/ayxjbQEOfzrcVyqZOgs+UgFIGSKNKdrTck NoRcvKI1GZtoTSlX7upTfQ3ElNLK4vCNEtUCAwEAAaOCA4UwggOBMAkGA1UdEwQCMAAwCwYD VR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU+n4r Cr/0xGfHPervy/seHUba8HYwgagGA1UdIwSBoDCBnYAUU3Ltkpzg2ssBXHx+ljVO8tS4UYKh gYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQ0wHQYDVR0RBBYwFIEScnJlbHllYUByZWRoYXQu Y29tMIIBQgYDVR0gBIIBOTCCATUwggExBgsrBgEEAYG1NwECATCCASAwLgYIKwYBBQUHAgEW Imh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbcGCCsGAQUFBwICMIGqMBQW DVN0YXJ0Q29tIEx0ZC4wAwIBARqBkUxpbWl0ZWQgTGlhYmlsaXR5LCBzZWUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGlj eS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3dy5zdGFydHNzbC5jb20vY3J0dTEt Y3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNybDCB jgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDov L3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQADga0w9gybyNKz+qYZVI1d CVOqMD9ly0Nn2WeNiSx6nyfsiVqqaa82xyu3O6CY8v05TVEMxUGb7UDNFgHKKbDs76nl8gfZ bemaqtVCzBvbOcjDNK6v3aWBRNo7vVmPPu/etokpKhpjMK6vWcDvCd+85jA0t4n8N/59/zbN bezCurWp85LoEnLlvU0K/80DTWpy0Jnrr1OhW67ulBWSOnNaltBuAdabX0xEIgEPhOz3SHYy PUmHduLlOvznT5Rq1bYJdFFJ8C7gsAPg/OMbXOPk45Cxcbqigk4tDQzjc6LD86zRieynGruW 6leQFMVc+m1In6kN2l+8YA+1atBBggiuMIIH4jCCBcqgAwIBAgIBDTANBgkqhkiG9w0BAQUF ADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2Vy dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNz IDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIa FHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7 Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQ PEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVj GcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID AQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB/zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc 4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAwgZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGB pH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAwPQYIKwYBBQUHAQEEMTAvMC0G CCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwYAYDVR0fBFkw VzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNybC5jcmwwJ6AloCOG IWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASCAVQwggFQMIIB TAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNvbS5v cmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9w b2xpY3kucGRmMBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0 ZXMwDQYJKoZIhvcNAQEFBQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP /4H/Bc8FFDTgoJR+nX2Li0EP3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhp cqMr3OyzK3aYGJP5RIeZ6vLT3fQaDZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyR WTTX6mWSv+TraOwuj3zrrddSpgUEi2WqwM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNh HeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsgD/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG8 59MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYihmm28UHOvND2G3kK0LvnuieLqjQMc6Gu UcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2xAuVRkM4kB9/+iieA1D/OTiRJwsf 6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3DsLhpDSYdejb74SKjtuqLDIO uAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr/i/8F8wDwdyzas7oxkdC taW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/TyxV/stlehMYID0DCC A8wCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYD VQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMAkGBSsO AwIaBQCgggIQMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDkyNDIyMDA0NlowIwYJKoZIhvcNAQkEMRYEFOtidkjS6BikRuNHtB4ALmY7eawBMF8GCSqG SIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpQYJKwYBBAGCNxAEMYGX MIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwCrKTCBpwYLKoZIhvcN AQkQAgsxgZeggZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDAKspMA0G CSqGSIb3DQEBAQUABIIBAJfiL29MZ3MUi9xWIQkWENNLk6TkHp55v/VyezpHbeeXM1InFMCk Brw9SKKv/20HeIkKSQqlCkUVuQRT7pKpD+wRiWPA8HQineQW6qAwn94j/Bg9s2NlV3GC0WUY KZZtWwYa+ngemVM3oYlq8bN5FjV+6AXiWGEZ1ZeOdosht5fff306yaThdmWmY5MaWcNF4py2 xOcgZxZSvTpXU+wRegf+8N7IGFpHK81LrkNWbcQ2h2OV9bTSLo/43R2r19unpR9WBheVFy/q /sDLasHZoVTJoSAJKk3fdbFDbmeBJjpk4uRQhZutN0Vp2bj3a01+eAgvpDobVoymhEdkGow1 RUoAAAAAAAA= --------------ms070600000007040902010805-- From jwkckid1@ix.netcom.com Fri Sep 24 15:15:21 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D3283A6AC0; Fri, 24 Sep 2010 15:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.464 X-Spam-Level: X-Spam-Status: No, score=-1.464 tagged_above=-999 required=5 tests=[AWL=0.820, BAYES_00=-2.599, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0--0CpZLpnt; Fri, 24 Sep 2010 15:15:16 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 345863A6A91; Fri, 24 Sep 2010 15:15:05 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=I8hsuBhNeUkoFqFeoP9Fn9By1K3xWOzCmQYrq/KFrNqN8WxY8PuGYwHceJsKTpWE; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.42] (helo=elwamui-muscovy.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1OzGYK-00071t-8I; Fri, 24 Sep 2010 18:15:36 -0400 Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Fri, 24 Sep 2010 18:15:35 -0400 Message-ID: <7248432.1285366536103.JavaMail.root@elwamui-muscovy.atl.sa.earthlink.net> Date: Fri, 24 Sep 2010 17:15:35 -0500 (GMT-05:00) From: "Jeffrey A. Williams" To: Robert Relyea , mrex@sap.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e51960688c2c6bf9cb4ca647aad8afc34653425aa350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.42 X-Mailman-Approved-At: Fri, 24 Sep 2010 18:36:44 -0700 Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org Subject: Re: [secdir] [TLS] secdir review of X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "Jeffrey A. Williams" List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 22:15:22 -0000 bob and all, I think Bob's exactly right here. Thanks bob for being so concise. >:) -----Original Message----- >From: Robert Relyea >Sent: Sep 24, 2010 5:00 PM >To: mrex@sap.com >Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, jhutz@cmu.edu >Subject: Re: [TLS] [secdir] secdir review of > >On 09/24/2010 01:29 PM, Martin Rex wrote: >> Peter Saint-Andre wrote: >> >>> For context, the "quoted advice" is mostly a description of current >>> usage in some existing user agents. Incorporating Barry's suggestions, >>> that text currently reads as follows in our working copy: >>> >>> Security Note: Some existing interactive user agents give advanced >>> users the option of proceeding despite an identity mismatch. >>> Although this behavior can be appropriate in certain specialized >>> circumstances, in general it ought to be exposed only to advanced >>> users and even then needs to be handled with extreme caution, for >>> example by first encouraging even an advanced user to terminate >>> the connection and, if the advanced user chooses to proceed >>> anyway, by forcing the user to view the entire certification path >>> and only then allowing the user to accept the certificate on a >>> temporary basis (i.e., for this connection attempt and all >>> subsequent connection attempts for the life of the application >>> session, but not for connection attempts during future application >>> sessions). >>> >> This whole paragraph is evil and completely wrong. >> >> It's bad enough that the web browser crowds replaced a useful option >> and important security feature with an extremely evil scary page. >> > >No, this paragraph is exactly what should happen. Click through dialogs >are demonsterably useless. They train users to ignore them. The only >place for them is if you decide that validation is not necessary. >> Offering to end-users, in a single-time-only leap-of-faith approach similar >> to what SSH has been successfully doing since its invention to memorize >> the peers certificate is magnitudes more secure than the endpoint >> identification linking to one of a hundred trust anchors, provisionally >> preconfigured by your software supplier. >> >SSH is good for small numbers of point to point connections where the >user controls both sides. SSH model is not appropriate for the general >population connection to millions of webservers. That is why SSH is used >extensively in admin deployments (where the admin controls both >machines) and is not used for e-commerce. If you want that semantic use >SSH. If you want security for the masses, use SSL (with full PKI). > > >[ case where SSL is being used for an SSH use case deleted] > >bob > Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 300k members/stakeholders and growing, strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com Phone: 214-244-4827 From Jeff.Hodges@KingsMountain.com Fri Sep 24 15:39:25 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59FBC3A6AF8 for ; Fri, 24 Sep 2010 15:39:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.119 X-Spam-Level: X-Spam-Status: No, score=-102.119 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zP-t3Y7z1hEg for ; Fri, 24 Sep 2010 15:39:23 -0700 (PDT) Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 746513A6AEE for ; Fri, 24 Sep 2010 15:39:23 -0700 (PDT) Received: (qmail 15512 invoked by uid 0); 24 Sep 2010 22:39:55 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 24 Sep 2010 22:39:55 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=QsdB4qDzlq7iIgDlWq/z12+aJU7Hyt1GUx21EJdL0kgHycejmkMfBJHeus4Moc+mI0Pg074FBGsvYdD41IeYXTDf4peNZYc5onN1UazBGT6me/C9OiZE0v95o874+mlo; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.48.179]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1OzGvr-0000Mn-JM; Fri, 24 Sep 2010 16:39:55 -0600 Message-ID: <4C9D28BB.7010604@KingsMountain.com> Date: Fri, 24 Sep 2010 15:39:55 -0700 From: =JeffH User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Martin Rex Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} X-Mailman-Approved-At: Fri, 24 Sep 2010 18:36:44 -0700 Cc: tls@ietf.org, secdir@ietf.org, certid@ietf.org, iesg@ietf.org Subject: Re: [secdir] [TLS] secdir review of draft-saintandre-tls-server-id-check-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2010 22:39:25 -0000 On 09/24/2010 01:29 PM, Martin Rex wrote: > Peter Saint-Andre wrote: > >> For context, the "quoted advice" is mostly a description of current >> usage in some existing user agents. Incorporating Barry's suggestions, >> that text currently reads as follows in our working copy: >> >> Security Note: Some existing interactive user agents give advanced >> users the option of proceeding despite an identity mismatch. >> Although this behavior can be appropriate in certain specialized >> circumstances, in general it ought to be exposed only to advanced >> users and even then needs to be handled with extreme caution, for >> example by first encouraging even an advanced user to terminate >> the connection and, if the advanced user chooses to proceed >> .... > > This whole paragraph is evil and completely wrong. PeterSA and I disagree, and echo rrelyea's sentiments. For some background context, see.. ForceHTTPS: Protecting High-Security Web Sites from Network Attacks Collin Jackson and Adam Barth In Proceedings of the 17th International World Wide Web Conference (WWW2008) https://crypto.stanford.edu/forcehttps/forcehttps.pdf See also.. HTTP Strict Transport Security (HSTS) http://tools.ietf.org/html/draft-hodges-strict-transport-sec Firefox 4.0 beta 5 "HTTP Strict Transport Security (HSTS) is a new security protocol in Firefox 4 Beta..." =JeffH From Nicolas.Williams@oracle.com Fri Sep 24 21:21:55 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82D173A68BB; Fri, 24 Sep 2010 21:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCGswl0JCHub; Fri, 24 Sep 2010 21:21:54 -0700 (PDT) Received: from rcsinet10.oracle.com (rcsinet10.oracle.com [148.87.113.121]) by core3.amsl.com (Postfix) with ESMTP id 78EAF3A6886; Fri, 24 Sep 2010 21:21:54 -0700 (PDT) Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o8P4MNCh031176 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 25 Sep 2010 04:22:24 GMT Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o8ONQ7iA028003; Sat, 25 Sep 2010 04:22:23 GMT Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 629328651285388542; Fri, 24 Sep 2010 21:22:22 -0700 Received: from oracle.com (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 24 Sep 2010 21:22:22 -0700 Date: Fri, 24 Sep 2010 23:22:17 -0500 From: Nicolas Williams To: Robert Relyea Message-ID: <20100925042217.GI9501@oracle.com> References: <201009242029.o8OKTqcc023470@fs4113.wdf.sap.corp> <4C9D1F8E.70608@REDHAT.COM> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C9D1F8E.70608@REDHAT.COM> User-Agent: Mutt/1.5.20 (2010-03-02) Cc: mrex@sap.com, secdir@ietf.org, certid@ietf.org, iesg@ietf.org, barryleiba@computer.org, tls@ietf.org Subject: Re: [secdir] [TLS] secdir review of X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Sep 2010 04:21:55 -0000 On Fri, Sep 24, 2010 at 03:00:46PM -0700, Robert Relyea wrote: > SSH is good for small numbers of point to point connections where the > user controls both sides. SSH model is not appropriate for the general > population connection to millions of webservers. That is why SSH is used > extensively in admin deployments (where the admin controls both > machines) and is not used for e-commerce. If you want that semantic use > SSH. If you want security for the masses, use SSL (with full PKI). It shall not surprise anyone that I don't quite agree with the above. That is, I agree with the part about the pre-shared public keys (ssh known_hosts files) not scaling (not even to a corporate network), and the part about ssh leap-of-faith not being a great model (though you were not that specific). In particular, what PKI is this that you speak of? The PKI we have is not really. Even leap-of-faith is better than the "PKI" we have now. The PKI we will have (DNSSEC) (one hopes) won't be a joke. But even a true PKI, with one root (or one root per-country or region of the world) is not quite what we need -- though it just might well do well enough. I would much prefer federated authentication mechanisms + channel binding to TLS -- TLS is the secure transport that we have for HTTP, and TLS is a decent enough secure transport, if you don't care about authentication. Yes, a combination of "PKI" (and "stickiness") may well be part of how federated authentication mechanisms work, but even so, the impact of "PKI" on the user agent and UIs would be minimized, and that'd be a very good thing. Nico -- From paul.hoffman@vpnc.org Sun Sep 26 08:57:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B643A6A08 for ; Sun, 26 Sep 2010 08:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.138 X-Spam-Level: X-Spam-Status: No, score=-100.138 tagged_above=-999 required=5 tests=[AWL=-0.506, BAYES_40=-0.185, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGnNokr50zXq for ; Sun, 26 Sep 2010 08:57:11 -0700 (PDT) Received: from hoffman.proper.com (Hoffman.Proper.COM [207.182.41.81]) by core3.amsl.com (Postfix) with ESMTP id 9E7C73A6923 for ; Sun, 26 Sep 2010 08:57:11 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id o8QFvh3n036244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Sep 2010 08:57:44 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 26 Sep 2010 08:57:42 -0700 To: secdir@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Cc: david.peterson@brocade.com, Black_David@emc.com Subject: [secdir] Secdir review of draft-ietf-storm-ifcp-ipn133-updates-02 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 15:57:12 -0000 Greetings again. This is an admittedly-trivial document that removes an unused mode from an earlier document, and instantiates the protocol number that was earlier allocated by IANA. The security considerations are unchanged from the earlier RFP, which is appropriate. --Paul Hoffman, Director --VPN Consortium From Sandra.Murphy@cobham.com Sun Sep 26 13:24:26 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13CF63A6BAD for ; Sun, 26 Sep 2010 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Fl5fNA-SQkp for ; Sun, 26 Sep 2010 13:24:24 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 774EF3A6B82 for ; Sun, 26 Sep 2010 13:24:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o8QKP0FX003194 for ; Sun, 26 Sep 2010 15:25:00 -0500 Received: from mailbin2.ads.sparta.com (mailbin.sparta.com [157.185.85.6]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o8QKP06S006919 for ; Sun, 26 Sep 2010 15:25:00 -0500 Received: from SMURPHY-LT.columbia.ads.sparta.com ([192.168.1.103]) by mailbin2.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Sun, 26 Sep 2010 16:25:00 -0400 Date: Sun, 26 Sep 2010 16:24:59 -0400 (Eastern Daylight Time) From: Sandra Murphy To: secdir@ietf.org Message-ID: X-X-Sender: sandy@mailbin.sparta.com MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 26 Sep 2010 20:25:00.0113 (UTC) FILETIME=[E49E3410:01CB5DB8] Subject: [secdir] [karp] FW: Non IPSec Authentication mechanism for OSPFv3 (fwd) X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Sep 2010 20:24:26 -0000 Authentication in OSPFv3 (for IPv6) differs from OSPFv2. OSPFv2 has an authentication mechanism in-band in the mechanism (recently updated in 5709). OSPFv3 relies on IPSec, but with manual keying so it has no replay protection. That's been an issue. The draft below suggests a new authentication mechanism for ospfv3 other than ipsec. I note that the abstact says: Currently OSPFv3 uses IPSec for authenticating the protocol packets. This draft proposes an alternative ? Generic Authentication that can be used so that OSPFv3 does not depend upon IPSec for security. The mechanism introduced in this draft is generic and can be used by any protocol that currently uses IPSec for authentication. The proposed use of this mechanism for uses beyond ospfv3 seems like it might be interesting to this group. I note also that the name given the proposed extension header is "Generic Authentication". The draft is http://tools.ietf.org/html/draft-bhatia-karp-non-ipsec-ospfv3-auth-00 --Sandy ---------- Forwarded message ---------- Date: Sat, 25 Sep 2010 06:05:11 +0530 From: "Bhatia, Manav (Manav)" To: "karp@ietf.org" Subject: [karp] FW: Non IPSec Authentication mechanism for OSPFv3 Hi, Currently OSPFv3 uses only IPSec for authentication. I have written a small draft that uses provides a different authentication mechanism - non IPSec based, for OSPFv3 as IPSec is generally considered inadequate for routing protocols. Would be great if folks can review and provide some feedback on this. http://tools.ietf.org/html/draft-bhatia-karp-non-ipsec-ospfv3-auth-00 Cheers, Manav _______________________________________________ karp mailing list karp@ietf.org https://www.ietf.org/mailman/listinfo/karp From tlyu@mit.edu Sun Sep 26 20:21:12 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 49D963A6C41; Sun, 26 Sep 2010 20:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.56 X-Spam-Level: X-Spam-Status: No, score=-103.56 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWHDitz3na90; Sun, 26 Sep 2010 20:21:11 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (DMZ-MAILSEC-SCANNER-2.MIT.EDU [18.9.25.13]) by core3.amsl.com (Postfix) with ESMTP id 29D513A6AA8; Sun, 26 Sep 2010 20:21:10 -0700 (PDT) X-AuditID: 1209190d-b7b38ae000006976-c7-4ca00de5082a Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-2.mit.edu (Symantec Brightmail Gateway) with SMTP id 03.B3.26998.5ED00AC4; Sun, 26 Sep 2010 23:22:13 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id o8R3LkwS003773; Sun, 26 Sep 2010 23:21:47 -0400 Received: from cathode-dark-space.mit.edu (CATHODE-DARK-SPACE.MIT.EDU [18.18.1.96]) (authenticated bits=56) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id o8R3LiT6003304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 26 Sep 2010 23:21:45 -0400 (EDT) Received: (from tlyu@localhost) by cathode-dark-space.mit.edu (8.12.9.20060308) id o8R3Li28015542; Sun, 26 Sep 2010 23:21:44 -0400 (EDT) To: secdir@ietf.org, iesg@ietf.org, draft-gundavelli-v6ops-l2-unicast.all@tools.ietf.org From: Tom Yu Date: Sun, 26 Sep 2010 23:21:44 -0400 Message-ID: Lines: 4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: AAAAAA== Subject: [secdir] secdir review of draft-gundavelli-v6ops-l2-unicast-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 03:21:12 -0000 This document is a fairly straightforward clarification stating that implementations may transmit an IPv6 multicast packet to a link-layer unicast address. The Security Considerations section states that the change does not introduce any new vulnerabilities, and I agree. From tobias.gondrom@gondrom.org Mon Sep 27 04:40:47 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCAB3A6CED for ; Mon, 27 Sep 2010 04:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.918 X-Spam-Level: X-Spam-Status: No, score=-94.918 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OC0v7d8awemv for ; Mon, 27 Sep 2010 04:40:43 -0700 (PDT) Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id CF98C3A6C99 for ; Mon, 27 Sep 2010 04:39:24 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=Qog6Z0TvqqBW7qC5rQzHAEeYIEpDZyyIWSUwzhJRdWyZuycGZN6pefrrEUx8gn9fmJd7GylKOVcIy8GrfZ3q9roayrqRkpsqMscSmHrZGGqjBO1bNWtVvw37XOuJ3gUp; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding; Received: (qmail 20026 invoked from network); 27 Sep 2010 13:36:34 +0200 Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 27 Sep 2010 13:36:34 +0200 Message-ID: <4CA081F7.60304@gondrom.org> Date: Mon, 27 Sep 2010 12:37:27 +0100 From: Tobias Gondrom User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100914 SUSE/3.1.4 Lightning/1.0b2 Thunderbird/3.1.4 MIME-Version: 1.0 To: iesg@ietf.org, secdir@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: swallow@cisco.com, wenhu.lu@ericsson.com, draft-ietf-mpls-ldp-igp-sync-bcast.all@tools.ietf.org, adrian.farrel@huawei.com, sriganesh.kini@ericsson.com, martin.vigoureux@alcatel-lucent.com, loa@pi.nu Subject: [secdir] Secdir review of draft-ietf-mpls-ldp-igp-sync-bcast-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Sep 2010 11:40:47 -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. draft-ietf-mpls-ldp-igp-sync-bcast-04 LDP IGP Synchronization for broadcast networks the draft updates RFC 5443 (LDP IGP Synchronization) It basically proposes the following mechanism: "If an interface is not a 'cut-edge' then the updating of the LSA with that link to the pseudo-node is postponed until LDP is operational." The document states that there would be no security considerations beyond RFC5443. I am not certain of that. Although the idea behind bcast is good, it adds a new mechanism beyond 5443. To make sure the security considerations are accurate, I'd like to raise two questions for the authors/WG: 1. Which security implications does the WG see for removing a coming up link from the LSDB? 2. Can there be a gap between the algorithm to determine "cut-edge" and TTL (e.g. may not qualify for "cut-edge" and thus be removed from LSDB, but have a large number of links and effectively not be reachable)? and three minor editorial comments: - section 3, last paragraph: s/Since A's cost to reach B not high/Since A's cost to reach B is not high - Appendix A: Computation of 'cut-edge' there should be an informative reference for mentioned "Dijkstra's algorithm" - abbreviation "SPF" should list the its expanded term (Shortest Path First) at first mentioning. Best regards, Tobias From alberto@it.uc3m.es Tue Sep 28 08:04:11 2010 Return-Path: X-Original-To: secdir@core3.amsl.com Delivered-To: secdir@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D07C43A6953; Tue, 28 Sep 2010 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.505 X-Spam-Level: X-Spam-Status: No, score=-4.505 tagged_above=-999 required=5 tests=[AWL=-0.807, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90+fogAeJm0e; Tue, 28 Sep 2010 08:03:38 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by core3.amsl.com (Postfix) with ESMTP id 35F223A6D23; Tue, 28 Sep 2010 08:03:36 -0700 (PDT) X-uc3m-safe: yes Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp03.uc3m.es (Postfix) with ESMTP id E4601872084; Tue, 28 Sep 2010 17:04:16 +0200 (CEST) From: =?ISO-8859-15?Q?Alberto_Garc=EDa?= To: "'Sandra Murphy'" , , , References: <701EC68E5B2A43EB90CF83025269E464@bombo> Date: Tue, 28 Sep 2010 17:04:12 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_006F_01CB5F2F.2EE43340" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <701EC68E5B2A43EB90CF83025269E464@bombo> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 Thread-Index: AcsZfeJj2nmQCHGdTLucfKH28VDnuAAQqY0wDAaCrEA= X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17672.000 X-Mailman-Approved-At: Tue, 28 Sep 2010 10:31:32 -0700 Cc: csi-chairs@tools.ietf.org Subject: Re: [secdir] (MAIN) secdir review of draft-ietf-csi-proxy-send-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 15:04:11 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_006F_01CB5F2F.2EE43340 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable Hi, I have posted a new version of the draft, draft-ietf-csi-proxy-send, = version -05, with the changes resulting from this review, which have also = resulted in a new version of draft-ietf-csi-send-cert, recently issued. =20 Regarding to the comments made by Sandra, here I enclose (inline) a = summary of the changes being made according to them (for those items which I = don't explicitly answer in this email, I have preferred not to make any = change). =20 I hope that the document addresses your concerns and it is ready to = proceed - however, if you have any other comments, please let me know. =20 | -----Mensaje original----- | De: Alberto Garc=EDa [mailto:alberto@it.uc3m.es] | Enviado el: martes, 06 de julio de 2010 17:33 | Para: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy- | send.all@tools.ietf.org | CC: csi-chairs@tools.ietf.org | Asunto: RE: (MAIN) secdir review of draft-ietf-csi-proxy-send-04 | =20 | Hi Sandra | =20 | First of all, thanks for your thorough review. You have included very relevant | comments to improve the document. | =20 | I think the first part of this email should be discussed with authors = of draft-ietf- | csi-send-cert, so I have split in two pieces this email, and copied = the authors of | draft-ietf-csi-send-cert in the part affecting them. =20 Sandra made some comments about the need for clarifying authorization capabilities.=20 The changes to address this issue affect draft-ietf-csi-send-cert-07 and draft-ietf-csi-proxy-send =20 In draft-ietf-csi-send-cert-07 (document specifying the certificate enhancements for proxy support): Now there are 2 KeyPurposeIDs (instead = of 1) for proxy operation to separate the authorization to sign RA and = Redirect (id-kp-sendProxiedRouter), and to sign NS, NA and RS messages (id-kp-sendProxiedOwner). The detail of which messages can be signed and = for which purpose is also included. =20 In draft-ietf-csi-proxy-send-05 we have made changes to detail this in - 'Processing rules for senders' "A Secure ND Proxy MUST NOT use a key to sign NDP message types which do not correspond to the authorization granted to the considered key. NA, NS and RS messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeId value [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source addresses of the messages MUST be encompassed in the prefix associated to the certificate. RA and Redirect messages MUST be signed with a key corresponding to a Secure Proxy ND certificate with a KeyPurposeId value of id-kp-sendProxiedRouter. The prefix included in the RA message for on-link determination and/or stateless address autoconfiguration, and the Target Address of the Redirect message, MUST be encompassed in the prefix associated to that certificate." =20 - 'Processing rules for receivers'. Similar to the previous one - Modification of the application scenarios to detail how the = certificates are configured. (for example, for the MIPv6 case only id-kp-ProxiedOwner = is required, while for the other two both id-kp-sendProxiedRouter and id-kp-sendProxiedOwner are used) - A paragraph in the security considerations section stating that the authorization capabilities provided by the KeyPurposeId should not = exceed the minimum required by the scenario =20 =20 | =20 | The rest of the text is discussed in this email (I've included in the subject of this | email '(MAIN)' to distinguish both threads). | =20 | | -----Mensaje original----- | | De: Sandra Murphy [mailto:Sandra.Murphy@sparta.com] | | Enviado el: viernes, 02 de julio de 2010 2:31 | | Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org | | Asunto: secdir review of draft-ietf-csi-proxy-send-04 | =20 | =20 | | This draft validates the use of its new PS option against a proxy | | KeyPurposeId in the certificate. However, I could not find that = it | | validates the prefixes in the proxied messages against the = prefixes | | mentioned in the certificate. Surely it should. RFC3971 requires that | | the prefixes in a PI option match the router cert prefixes, but = I'm not | | sure that carries through to the proxied messages or those (like = NA) that | | refer to an address and have no PI option. | =20 | Yes, definitely prefixes should be checked. New text should be added, since | RFC3971 did not detail how certificates could be used to substitute = CGA. =20 Done in previous change =20 | =20 | | I was curious as to the topological scenarios possible with = proxies. | | RFC4861 notes that multiple proxies might respond on a single = link, | | draft-csi-sndp-prob-04.txt discusses proxies that are nested, = RFC4389 says | | that a proxy never receives RAs from other proxies (which = restricts | =20 | I understand (RFC4389: 4.1.3.3) that there is a 'direction' in which = RA flows | (from upstream to downstream), and there are rules to control that = only the | appropriate interface propagates RA. | =20 | | topologies), and this draft mentions proxying messages that = already | | contain a PS option. In Sec 5.2.2 of this draft, steps 6 and 7 of = the | | rules for receivers of the Proxy Signature option imply that there might | | be multiple proxies on a link as well as proxy responses colliding with | | direct responses. While there is a discussion of scenarios for proxying | | ND messages, they are not discussions of topologies of the proxies | | themselves. I believe that I would have benefited from an = explanation of | | the topology envisioned here. | =20 | =20 | Well, we thought that a generic discussion of the topologies of the proxies would | have been out of the scope of the document and the working group. | =20 | | Each SPND proxy must be able to distinguish secure nodes (RFC3971 = or SPND | | nodes) from insecure nodes (non-SEND) on the link for which it = serves as | | proxy. It decides whether to securely proxy ND messages received = from | | those nodes based on that info. Is there any thought as to how = the SPND | | proxy would know this? If this is manual configuration, that = could be a | | lot of work or impossible depending on the scenario. And if there = are | | multiple proxies on the link in some topologies, they must be consistent. | =20 | =20 | Well, I think this is specific to each deployment scenario, and I = think it is risky to | include text going further than presenting the security = considerations. | =20 | Considering the 3 scenarios presented in the draft: | =20 | - RFC4389 involves translating messages, so it is trivial to know the SEND/non- | SEND nature of the node. This is general for translating scenarios, = as commented | in the draft in section 7. | =20 | - PMIPv6 is very infrastructure dependent. The proxied element is the router. I | would expect the provider to know if all MAGs support SEND or not (if = any does | not support SEND... then non-SEND operation should be used). | =20 | - MIPv6. Here hosts are proxied, and the HA synthesizes messages on behalf of | the hosts. This is for me the most complex scenario, and I'm not = aware of any | other solution than any kind of manual configuration (besides all = nodes being | required to be SEND). | =20 | I think the previous info can be derived directly from the text of = the draft. | =20 | However, new scenarios may arise, and this could be handled easier. = For | example, assume proxy elements for saving energy by allowing hosts to = go to | sleep when not being heavily used (a-la ProxZZZy - www.ecma- | international.org/publications/files/ECMA-ST/ECMA-393.pdf). In this = case the host | would be in the same link as the proxy, so previous communication = should have | occurred (in particular, to allow the host to tell the proxy that it = goes to sleep), | so the proxy may know in advance if the host is SEND or not. | =20 | =20 | =20 | | | | I was curious as to whether unsigned ND messages could be proxied securely | | by a SPND node. Section 5.2.1 p 10 says the PS option MUST be = added, | | which satisfied me, but then Section 7.2 p 20 says there are cases where | | the PS option MUST NOT be added. If that's a contradiction, it = needs to | | be addressed | =20 | =20 | Well, 5.2.1 describes operation considering that the originating = message is | protected by SEND, so the proxied message is also secured. So it MUST = be added | to be secured. I can add some words to clarify that. | =20 | The part in which non-SEND hosts appear is section 7. | =20 | This structure is analogous to the SEND specification. | =20 In section 5.2.1, added comment at the end of paragraph: "A secured NDP message sent by a Secure ND Proxy for a proxied = address MUST contain a PS option and MUST NOT contain either CGA or RSA Signature options. Section 7 discusses in which cases a NDP message has to be secured in an scenario including non-SEND nodes." =20 =20 =20 | =20 | | The text seems to make a distinction between "locally generated"/"issued" | | messages for a proxied address and "forwarding" or "translating" a message | | from a proxied address. I was never certain what cases might = cause the | | local generation of an address. RFC4389 seem to me to refer only = to the | | forwarding of messages. Perhaps the "local generate" term refers = to the | | scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the term | | refers to some of the exchanges in RFC4389 proxying. I'm not = sure. | =20 | Well, what it is trying to say is not that the address is being = generated or not, but | the message. | =20 | The "forwarding" or "translating" case stands for the case in which a message is | received by the proxy through one interface, and relayed to other. = This is the | case of RFC4389. | =20 | The "locally generated"/"issued" or "synthesized" stands for messages that are | generated by the proxy without receiving a message from the proxy. = This is the | MIPv6 and PMIP case. | =20 | Do you think it would be more clear if this is included in the 'Terminology' | section? | =20 =20 'Translated NDP message' and 'Synthetic NDP message' have been included = in the 'Terminology' section. These terms are now used consistently all = over the document. =20 | | | | After reading this, I was not sure that I had an adequate idea of = the | | error processing when different information has the potential to conflict. | | I was particularly interested in the RA message. RFC4389 = introduces a "P" | | bit for the RA messages to indicate a proxied message. This draft | | introduces a PS option to secure proxied messages. The new cert format | | has a "proxy" value for the KeyPurposeId. I tried to work out the | | combinations: | =20 | | | | P bit PS opt cert:"proxy" action | | 0 no no no proxy needed (can use 3791) | | 0 no yes no proxy needed (can use 3971) | | 0 yes no silent discard of message | | 0 yes yes weird but OK? | | 1 no no "unsecured", even if 3971 signed? | | cert says not a proxy, so drop? | | 1 no yes "unsecured", even if 3971 signed? | | If 3971 signed, check 3971 cert | | prefixes or new cert prefixes? | | 1 yes no silent discard of message | | 1 yes yes secure proxy - all OK | =20 | =20 | Well, the fourth case in the table needs some though, while the = others are ok: | =20 | The "P" bit of RFC4389 is only meaningful for proxies, i.e. hosts = does not process | it: the way the behavior of the receivers is defined in section = 4.1.3.3 is "When | [...] arrives on the upstream interface" or "[...] on the downstream interface"... | The description always refers to upstream and downstream, which are = only | relevant for RFC4389 proxies. | =20 | Then, for hosts the first column is irrelevant. | =20 | Assume an RFC 4389 proxy with SPND enabled receives any message (in = this | case, the 3 'switches' - P bit, PS opt, cert opt- would be = meaningful). | =20 | First, security is checked, which means that the P bit should not be processed | until the message is verified, and a "security level" ('secured' or 'unsecured') is | defined for the message. Then I don't think a table in which the = three elements | are mixed together is a good representation of the problem. Instead, = I think its | better to view the process as a sequence of tie-breaking rules: 5.2.2 specifies the | requirements for having a messages validated as secured. Rule #1 just discards | parts of the message that must not be considered when analyzing its security. | =20 | Rule #2 requires a valid certificate with 'proxy' value, and this certificate being | linked to the message through the 'Key Hash' field. If this fails, = then the message | is unsecured. | =20 | The rest of the rules check for the validity of the PS option. So, I would say: | =20 | cert:"proxy" PS opt action | =20 | no no unsecured | no yes unsecured | yes no This does not have much = sense: you cannot | know to which cert is referring a message if there is no PS opt with = a Key Hash | pointing to a cert. | yes yes secured | =20 | Then, the question stated in your table: ""unsecured", even if 3971 signed? | | cert says not a proxy, so drop?" | =20 | Would be 'unsecured', and then discard or not according to the configuration of | the host regarding to backward compatibility (accept 'unsecured' if configured to | do so, and in any case do not replace 'secured' information with 'unsecured' one) | =20 | Now we can look at the P (RFC4389) bit. The case in which a secured message | from a proxy is received, but the bit P is set to 0... this MUST NOT = have been | generated by a RFC4389 proxy (since RFC4389 proxies always set the P bit). It | could have been generated by other proxy type - for example, a PMIPv6 MAG, | which for the RFC4389 proxy would look as a 'regular' router. | =20 | If the proxy were sure that only RFC4389 proxy operation is allowed, = then this | situation is really strange (a proxy that sends a RA message = secured... that | should be a RFC4389 proxy, but does not set the bit P to 1), and probably, it | should discard the message. | =20 | Does this fully address your question? | =20 | =20 | =20 | Do you think it would clarify to add some text to the document? (I'm thinking | specifically in the part of the scenarios, probably adding to section 6.3, 'rule' 1, in | which a summary of the processing which RFC4863 proxies do before = sending | the packet, that the P bit must be set. | =20 | And maybe a new sentence saying that proxies receiving this info, if = they are | sure that only RFC4389 proxy operation is allowed, could discard = messages with | valid PSO option but without the P bit? (<-- not sure that this is = very clarifying...) | =20 | | As acknowledged in the Section 7.1, a RFC3971 message from a = RFC3971 | node | | to another RFC3971 node proxied through a SPND proxy appears = unsecured to | | the receiver. That's no worse than proxying the message through a RFC3971 | | proxy, so no harm done, for most messages. For Router = Solicitation | | messages, which according to RFC3489 don't get altered and can = retain | | their signatures, the outcome is worse. I think. | =20 | I see your point. | =20 | RFC 4389, section 4.1 (and also draft-ietf-csi-proxy-send) states = that | =20 | "This document covers the following types: | Neighbor Solicitations, Neighbor Advertisements, Router | Advertisements, and Redirects. These packets are ones that can = carry | link-layer addresses, and hence must be proxied [...]" | =20 | But I think this is not completely true, since RFC4861 states that = Router | Solicitations can also carry source link-layer addresses: | =20 | "4.1. Router Solicitation Message Format | =20 | [...] | =20 | Source link-layer address The link-layer address of the sender, if | known. MUST NOT be included if the Source = Address | is the unspecified address. Otherwise, it = SHOULD | be included on link layers that have addresses." | =20 | It is clear for me that if the RS message includes a "Source = link-layer address | option", it must also include a PS option. | =20 | But, could a SEND-protected RS message which does not include a link-layer | address be copied as-is in the other interface? I think yes, since = CGAs would be | validated consistently. | =20 | This would be the device you mention as "RFC3971 proxy", which by the way, I | don't think has been defined. I mean, should this "RFC3971 proxy" = check for the | validity of the original message, or just let it pass and let the receiver doing the | check? I think it should check (as the SPND proxy does), but I don't = have a clear | opinion on this. | =20 | Then, I see two options for proxying secure messages not including link-layer | addresses: | =20 | 1- Process as defined for the SPND proxy (which is check for validity = of the | original message, include PS option...) | =20 | 2- check for validity of the original message, and if it is valid, forward as-is | =20 | The first option seems more homogeneous. The second one allows the validation | of some messages by nodes which are RFC3971 but not SPND. However, = this is | only for a very limited subset of the proxied information, which is = the one not | including link-layer addresses. | =20 | I tend to prefer 1, but without a clear opinion. | =20 | What do you think? | =20 | Once clarified, the text of the RFC4389 scenario should be updated. | =20 =20 Done, (for Choice 1) =20 | =20 | | Detailed comments: | =20 | | Sec 4, p 6: | | Proxy ND's certificate. When a ND message contains a PS option, | | it MUST NOT contain CGA and RSA Signature options. This = option | | can be appended to any ND message: NA, NS, RS, RA and = Redirect. | | | =20 | | Is that a "MAY" be appended? Page 10 says "MUST" be added, but section | | 7.2 p 20 talks of cases where it MUST NOT be added. | =20 | MUST be added to be secured. | MUST NOT for non-SEND nodes. | =20 =20 Changed =20 | =20 | =20 | Obviously, (as commented above), a clarification saying that = processing rules of | section 5 are for generating/processing secured messages must be = included | =20 | =20 | | o A modification of the SEND processing rules for all ND messages: | | NA, NS, RS, RA, and Redirect. | | | | This draft and RFC4389 do not mention - if the proxied message is = a NA, | | and the proxy is a router, does the router bit get set? | =20 | I think it should be set (I don't see any reason for not being set). | Not sure if I should 'complement' RFC4389 in this document... | =20 | | | | Sec 5.2.1 p 10 | | | | 5.2.1. Processing rules for senders | | A ICMPv6 message sent by a Secure ND Proxy for a proxied = address MUST | | contain a PS option and MUST NOT contain either CGA or RSA Signature | | options. | | | | Note contradiction in section 7.2 p 20. | =20 | Commented above | =20 | =20 | | Sec 5.2.1 p 11 | | | | C. If the Secure ND Proxy is forwarding a SEND message already | | containing a PS option, first the authenticity of the | | intercepted message is verified as specified in = Section 5.2.2 | | of this specification. If the SEND message is valid, = the | | original PS option MUST be removed from the message. = The | | intercepted message is finally modified as described = in | | Section 4 of the ND Proxy specification [RFC4389]. | | | =20 | | Does this disagree with the RFC4389 statement that RA messages can = not be | | received from other proxies? That is, if an RA message P bit is = set (and | | if it contains a PS option, one hopes the P bit is set), RFC4389 = sec | | 4.1.3.3 says the interface must not be used as a proxy interface. | =20 | No, I understand in a different way: RA messages can be proxied many times. | Assume | =20 | I1 I2 | =20 | Router ------ P1 ------- P2 -----P3 | =20 | =20 | With I1 being the interface of P2 connected to the router, and I2 the interface of | P2 connected to P3. | =20 | What RFC4389 says is that when P1 receives a RA, then it cannot be proxied to | I1 (but it can to I2) | =20 | =20 | I think there is no disagreement. | =20 | =20 | | 2. Timestamp and Nonce options MUST be included according to = the | | rules specified in SEND [RFC3971]. The value in the = Timestamp | | option MUST be generated by the proxy. If the proxy is | | forwarding a message, the Nonce value in the proxied = message MUST | | be the same as in the forwarded message, otherwise it is | | generated by the proxy. | | | =20 | | What is the "otherwise" here? If the proxy is *not* forwarding, = which | | might be if it is "locally generating" a message? If the Nonce is = not | | present in the forwarded messages? | =20 | =20 | 'Otherwise' refers to synthesizing locally the message. I thing this = two behaviors | ('forwarding', 'generating locally') should be presented more clearly before this | rule (although this concepts are somehow presented in rule 1). | =20 | 'Otherwise' does not refer to the nonce. RFC3971 states that it is = not present for | unsolicited advertisements. If a proxy is receiving a message to be forwarded | without the nonce (or otherwise), where it should be, it will be = marked as | unsecured. Then the proxy will include it "according to the | rules specified in SEND [RFC3971]", as says the previous text. | =20 | I can also change 'otherwise' with "If the proxy is synthesizing a message .", so | ambiguity is definitely resolved. =20 Done. Also the 'forwarding'/'generating locally' terms have been removed (see a comment above) =20 | | | | Sec 6.2 p 16 | | | | This scenario seems to be using the SPND feature because the MAG = is using | | a source address that does not really belong to it. It is not forwarding | | any ND messages. So perhaps this is the case where the "locally | | generated" terminology applies. | =20 | Yes, this is one of the cases (the other is MIPv6 - note that in this case, although | the MN and HA is communicating, when a host in the link of the HA generates a | NS for the MN, the HA responds without retransmitting the request to = the MN | and then waiting back for the answer) | =20 | | To provide SEND protection, each MAG is configured to act as a proxy | | by means of a certificate associated to the PMIPv6 domain, | | authorizing each MAG to proxy securely ND messages. In = addition, the | | certificate must also authorize the MAG to advertise prefixes. Note | | that the inclusion of multiple KeyPurposeId values is = supported by | | [I-D.ietf-csi-send-cert]. | =20 | | I believe that means that the new cert format must show both the router | | and the proxy KeyPurposeID values because it is generating a RA. = But no | | such check is mentioned anywhere. | =20 | Yes, you are right. Once clarified which KeyPurposeId should be used, this | should be changed also | =20 =20 This has been already clarified=20 =20 | =20 | | Sec 6.2 p 16 | | | | A node receiving a message from the MAG containing the PS = option MUST | | apply the rules defined in Section 5.2.2. Note that = unsolicited | | messages sent by MAG are validated by the host according to timestamp | | values specific to the MAG serving the link, not to any other = MAG to | | which the host has been connected before in other links. | | | =20 | | The host does not see any difference in the MAG, since the MAG is using | | the same source IP address as all other MAGs to which the host has been | | connected. According to my reading of RFC3971, that means that there's a | | chance that unsolicited messages from the MAG would appear stale - = as long | | as the unsolicited message was received before a solicited advertisement. | | Receipt of a solicited advertisement should update the timestamp = at the | | host, based on the nonce matching, by RFC3971 rules | =20 | Well, there is a risk that unsolicited messages where considered unsecured due | to different clocks in different proxies. Then, what is suggested in section 5.2.2, | rule 6, is that "The receiver SHOULD store the peer-related timing information | [.] separately for each different proxy (which can be identified by = the different | Key Hash values of the proxied message) and separately from the = timing | information associated to the IP of node for which the message is proxied". | =20 | Maybe in section 6.2, a reference to section 5.2.2, rule 6 could be added, so this | issue would be clarified. | =20 =20 Done =20 | =20 | | Sec 6.3 p 17/18 | | | | A Secure ND Proxy shall parse any IPv6 packet it receives on a proxy | | interface to check whether it contains one of the following secured | | ICMPv6 messages: NS, NA, RA, or Redirect. | | | =20 | | This seems to disagree with Section 5.2.1, p 10, which says the PS option | | is added to *all* messages. However, it does agree with the discussion in | | section 7.2 p 19/20, which says that the PS option is only = generated on | | behalf of RFC3917 nodes and SPND nodes. | =20 | =20 | Yes, this sentence implicitly assumes that there may be unsecured messages, | which is not the style of the rest of the document, and only appears clearly in | section 7. | =20 | I think it would be best to reword it so that it does not suggest yet = the possibility | of unsecured messages. | =20 =20 Done =20 | =20 | | | | Section 7.1 p 19 | | | | In the scenarios in which the proxy translates ND messages, = the | | messages to translate can either be originated in a RFC3971 = node or | | in an SPND node, without interoperability issues. | | | =20 | | The discussion immediately above this text says that RFC3971 nodes drop a | | PS option in a proxied message and treat the message as unsecured, = so I am | | not sure what this is talking about. A secure proxied NA reply, = for | | example, would appear unsecured to the RFC3971 host and secure to = the | SPND | | proxied host. Is "translates" an ND message different from | | "forwards"/"proxies" an ND message - i.e., the PS option is not applied? | =20 | =20 | The key word of this paragraph (the third) is 'originated', while in = the first | paragraph of section 7.1 the key word is 'received'. What this is = saying is that a | proxy can secure a message generated either in a RFC3971 or SPND = node, since | regarding to the rules of generating ND messages, both behave exactly = the same | (the difference is in the receiving rules for PS options). | =20 | I can clarify a bit this differences | =20 =20 Added "(note that the difference between RFC3971 nodes and SPND nodes = only affect to the ability to process received NDP messages containing a PS option, not in the way they generate messages secured by SEND)" at the = end of the paragraph. =20 =20 | =20 | | | | sec 7.2 p 20 | | | | Therefore, the Secure ND Proxy MUST generate messages = containing the | | PS option for SPND and RFC3971 hosts, and MUST NOT generate messages | | containing the PS option for non-SEND nodes. | | | | This (and other places in the subsequent paragraphs) seems to contradict | | sec 5.2.1 p 10 which says the PS option is a MUST, period. | =20 | This is related with the acceptance of secured/unsecured message, and = as | discussed above, should be clarified, starting in section 5. | =20 | | What does the "for SPND and RFC3971 hosts" and the "for non-SEND hosts" | | mean? I believe that it means that the proxy is forwarding = messages on | | their behalf. The use of the term "generate" here doesn't seem to mean | | the same as "locally generated" elsewhere. | =20 | Yes, you are right, this is imprecise. In this case "generate" means = both | 'forwarding' and 'synthesizing'. This should be clarified. =20 Done =20 | | I am not sure how the SPND would know which of the nodes on the = proxy | | interface were non-SEND, RFC3917, or SPND nodes. But if it can be | This is not addressed in this document. I have commented about this = above in | this email, in a paragraph starting by "Well, I think this is = specific to each | deployment scenario [.]" | =20 | | configured with that information, could it also be configured to = know the | | status of nodes on the outgoing interface? It might then detect = that | | doing the computation to add the PS option was a waste of effort because | | there were no SPND nodes on that side. | | | =20 | | If the RFC3971 node produces a solicitation that needs to be = forwarded | | through the SPND proxy, and the SPND proxy forwards the = advertisement it | | received in reply along with the PS option, the RFC3971 will drop = the PS | | option. True? Should the SPND still produce the (wasted) = signature? | =20 | Yes, this is true. Of course this could optimize SPND operation. | =20 | However, this may or may not be reasonable, depending on the scenario = and | particular configuration. For example, for PMIPv6, the proxy only performs its | function for the MAG, not for any host, so it is not evident that the proxy knows if | a node is SPND or not. For MIPv6, the proxy may or may not know the = SPND or | not (maybe, it knows when the node moves away, by accessing to some | database, but not if the node is in the link.) | =20 | I feel that this is too related with optimization, that should not be included in the | document. Another option is to include a MAY statement in section 7 commenting | this possibility, in a generic way, just for the sake of = completeness. What do you | think? | =20 | =20 | | Sec 7.2 page 20 | | | | o For translating ND messages for nodes that can arrive to the link | | in which the proxy operates, | | . | =20 | | o For synthesizing ND messages on behalf of remote nodes, | | | | I think "translating" here means forwarding through the proxy and doing | | the RFC4389 changes, while "synthesizing ND messages" means the = mobile | | node scenarios where no message is received for forwarding but one = is | | created (PMIPv6 and MIPv6?). | | | | An explanation of this difference and a consistent set of terms = would have | | helped a lot. | =20 | Yes, I'm really convinced. I will | =20 | =20 | | | | o For translating ND messages for nodes that can arrive to = the link | | in which the proxy operates, the rule can be easily = applied: only | | messages validated in the Secure ND Proxy according to the = SEND | | specification [RFC3971] MUST be proxied securely by the inclusion | | of a PS option. Unsecured ND messages could be proxied if | | unsecured operation is enabled in the proxy, but the = message | | generated by the Secure ND Proxy for the received message = MUST NOT | | include a PS option. | | | | Is it possible for a proxy to receive a message with a PS option? | =20 | Yes it is, for example for the RFC4389 case | =20 | | Previous text (sec 5.2.1 part C) seems to indicate so. If the = "MUST be | | proxied securely" applies to SPND protected messages as well as RFC3971 | | protected messages, then this case is the same as the previous paragraph | | "MUST generate messages containing the PS option for SPND and = RFC3971 | | hosts . . .". Unless this is a difference between translating messages | | and generating messages, of course. | =20 | Yes. I include the PS option here. | =20 =20 The following text has been included: "For scenarios in which ND messages are translated for nodes that can arrive to the link in which the proxy operates, the rule can be easily applied: only for messages validated in the Secure ND Proxy according to the SEND specification [RFC3971], or according to Section 5.2.2 of this specification for messages containing a PS option (which means that another proxy previously checked that the original message was secured) [.]" =20 | | Sec 8 p 22 | | | | However, when two on-link hosts communicate using | | their respective link-local addresses, the threats involved = with a | | compromised router and a compromised proxy ND differs because = the | | router is not able to siphon off traffic exchanged between the hosts | | or mount a man-in-the-middle attack, while the proxy ND can, = even if | | the hosts use SEND. | | | | This should be explained in more detail. I believe that the = reason is | | that a SEND router would not be able to produce a NA reply to an = NS that | | would be believed, but the SPND could pretend to be proxying a NA reply | | believably - as long as the recipient used SPND and could accept = the PS | | option. | =20 | Yes, that's the reason why. I will include a text similar to this to explain. | =20 =20 I have substituted the cited text with this: " A compromised Secure ND Proxy provisioned with an authorization certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is able, like a compromised router to siphon off traffic from the host, or mount a man-in-the-middle attack, for hosts communicating to off- link hosts. A compromised Secure ND Proxy provisioned with an authorization certificate with a KeyPurposeId value of id-kp- sendProxiedOwner can siphon off traffic or mount a man-in-the-middle attack for communication between on-link hosts, even if the hosts use SEND. Note that different application scenarios may require one type of authorization, the other, or both. To minimize security risks, authorization capabilities SHOULD NOT exceed the ones strictly required by the application scenario to be deployed." =20 =20 | =20 | | | | Proper configuration of when the PS option must or must not be | | included, depending on the proxied nodes being SEND or = non-SEND may | | result in security considerations which are discussed in = Section 7. | | | =20 | | This is pretty contorted. I believe that this is trying to say = that | | Section 7 discusses some of the security considerations resulting = from the | | decision to append or omit PS protections depending on the SEND awareness | | of the proxied nodes. But I'm not sure. | =20 | Yes, yours is a more accurate wording. I include, thanks | =20 Done =20 | =20 | | Attacks to the timestamp of the secured ND message can be performed | | as described in section 7.3 of [I-D.ietf-csi-sndp-prob]. | | | | I found that section of that draft to be particularly unclear. = And it is | | not normatively cited here. I'm not saying that it should be, but = if that | | draft does not progress (giving opportunity to improve the discussion), | | the reader of this draft would be lost. Is there any way to = summarize the | | vulnerabilities so that the reader of this draft have some hint of what | | can go wrong and why? | =20 | =20 | [I-D.ietf-csi-sndp-prob] is in AUTH48 status, so. I assume it will progress. | I agree that some hints should be included in = draft-ietf-csi-proxy-send, and also | indicating how the particular way Timestamp is handled here affects = to security. | Then, I suggest substituting the text you cited with the text below. | =20 | I also think the detail (and credit) of the problem statement could = be that of [I- | D.ietf-csi-sndp-prob], so I end the paragraph referring to it, and = I'm not | explaining completely its text. | =20 | Do you think this is ok? | =20 | "Protection against reply attacks from unsolicited messages such as Neighbor | Advertisements, Router Advertisements, and Redirects is provided by = the use of | the Timestamp option. When Secure ND Proxy is used, each proxy and = the host | for which a proxy acts on behalf are considered to be different peers = in terms of | Timestamp verification. Since the information provided by the host = and a proxy | maybe different, including different link-layer addresses, a reply = attack could | affect the operation of a third node: replying messages issued by a = host that is | no longer in the link can prevent the use of a proxy, and replying messages of a | proxy when the host is back in the link can prevent the access to the host. This | kind of attacks can be performed until the timestamp of the peer = (either the host | or a proxy) is no longer valid for the receiver. The window of vulnerability is in | general larger for the first message received from a new peer than = for | subsequent messages received from the same peer (see RFC3971). A more | detailed analysis of the possible attacks is described in section 7.3 = of [I-D.ietf-csi- | sndp-prob]." | =20 =20 Included =20 | =20 | | =20 The rest of the email referred to NITS, which I have changed. =20 Regards, Alberto ------=_NextPart_000_006F_01CB5F2F.2EE43340 Content-Type: text/html; charset="ISO-8859-15" Content-Transfer-Encoding: quoted-printable

Hi,

I have posted a new version of the draft, = draft-ietf-csi-proxy-send, version -05, with the changes resulting from this review, which have = also resulted in a new version of draft-ietf-csi-send-cert, recently = issued.

 

Regarding to the comments made by Sandra, = here I enclose (inline) a summary of the changes being made according to them = (for those items which I don’t explicitly answer in this email, I have preferred not to make any change).

 

I hope that the document addresses your = concerns and it is ready to proceed – however, if you have any other comments, = please let me know.

 

|=A0 -----Mensaje original-----

|=A0 De: Alberto = Garc=EDa [mailto:alberto@it.uc3m.es]

|=A0 Enviado el: martes, 06 de julio de 2010 = 17:33

|=A0 Para: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org; = draft-ietf-csi-proxy-

|=A0 send.all@tools.ietf.org

|=A0 CC: csi-chairs@tools.ietf.org

|=A0 Asunto: RE: (MAIN) secdir review of draft-ietf-csi-proxy-send-04

|=A0

|=A0 Hi Sandra

|=A0

|=A0 First of all, thanks for your thorough = review. You have included very relevant

|=A0 comments to improve the = document.

|=A0=A0

|=A0 I think the first part of this email = should be discussed with authors of draft-ietf-

|=A0 csi-send-cert, so I have split in two = pieces this email, and copied the authors of

|=A0 draft-ietf-csi-send-cert in the part = affecting them.

 

Sandra made some comments about the need for clarifying authorization capabilities.

The changes to address this issue affect = draft-ietf-csi-send-cert-07 and draft-ietf-csi-proxy-send

 

In draft-ietf-csi-send-cert-07 (document = specifying the certificate enhancements for proxy support): Now there are 2 = KeyPurposeIDs (instead of 1) for proxy operation to separate the authorization to sign = RA and Redirect (id-kp-sendProxiedRouter), and to sign NS, NA and RS messages (id-kp-sendProxiedOwner). The detail of which messages can be signed and = for which purpose is also included.

 

In draft-ietf-csi-proxy-send-05 we have made = changes to detail this in

- 'Processing rules for = senders'

=A0=A0 “A Secure ND Proxy MUST NOT use = a key to sign NDP message types which

=A0=A0 do not correspond to the authorization = granted to the considered key.

=A0=A0 NA, NS and RS messages MUST be signed = with a key corresponding to a

=A0=A0 Secure Proxy ND certificate with a KeyPurposeId value

=A0=A0 [I-D.ietf-csi-send-cert] of = id-kp-sendProxiedOwner, and the source

=A0=A0 addresses of the messages MUST be = encompassed in the prefix

=A0=A0 associated to the certificate.=A0 RA = and Redirect messages MUST be

=A0=A0 signed with a key corresponding to a = Secure Proxy ND certificate with

=A0=A0 a KeyPurposeId value of = id-kp-sendProxiedRouter.=A0 The prefix included

=A0=A0 in the RA message for on-link = determination and/or stateless address

=A0=A0 autoconfiguration, and the Target = Address of the Redirect message,

=A0=A0 MUST be encompassed in the prefix = associated to that certificate.”

 

- 'Processing rules for receivers'. Similar = to the previous one

- = Modification of the application scenarios to detail how the certificates are configured. = (for example, for the MIPv6 case only id-kp-ProxiedOwner is required, while for the = other two both id-kp-sendProxiedRouter and id-kp-sendProxiedOwner are = used)

- A paragraph = in the security considerations section stating that the authorization = capabilities provided by the KeyPurposeId should not exceed the minimum required by = the scenario

 

 

|=A0

|=A0 The = rest of the text is discussed in this email (I’ve included in the subject of = this

|=A0 email ‘(MAIN)’ to = distinguish both threads).

|=A0

|=A0 |=A0 -----Mensaje original-----

|=A0 |=A0 De: Sandra Murphy = [mailto:Sandra.Murphy@sparta.com]

|=A0 |=A0 Enviado el: viernes, 02 de julio de 2010 = 2:31

|=A0 |=A0 Para: iesg@ietf.org; secdir@ietf.org; draft-ietf-csi-proxy-send.all@tools.ietf.org

=

|=A0 |=A0 Asunto: secdir review of = draft-ietf-csi-proxy-send-04

|=A0

|=A0

|=A0 |=A0 This draft validates the use of its = new PS option against a proxy

|=A0 |=A0 KeyPurposeId in the certificate.=A0 = However, I could not find that it

|=A0 |=A0 = validates the prefixes in the proxied messages against the = prefixes

|=A0 |=A0 mentioned in the certificate.=A0 = Surely it should.=A0 RFC3971 requires that

|=A0 |=A0 = the prefixes in a PI option match the router cert prefixes, but I’m = not

|=A0 |=A0 = sure that carries through to the proxied messages or those (like NA) = that

|=A0 |=A0 = refer to an address and have no PI option.

|=A0

|=A0 Yes, definitely prefixes should be = checked. New text should be added, since

|=A0 RFC3971 did not detail how certificates = could be used to substitute CGA.

 

Done in previous change

 

|=A0

|=A0 |=A0 I = was curious as to the topological scenarios possible with = proxies.

|=A0 |=A0 = RFC4861 notes that multiple proxies might respond on a single = link,

|=A0 |=A0 draft-csi-sndp-prob-04.txt discusses proxies that are nested, RFC4389 = says

|=A0 |=A0 = that a proxy never receives RAs from other proxies (which = restricts

|=A0

|=A0 I understand (RFC4389: 4.1.3.3) that = there is a 'direction' in which RA flows

|=A0 (from upstream to downstream), and there = are rules to control that only the

|=A0 appropriate interface propagates RA.

|=A0

|=A0 |=A0 = topologies), and this draft mentions proxying messages that already

|=A0 |=A0 contain a PS option.=A0 In Sec = 5.2.2 of this draft, steps 6 and 7 of the

|=A0 |=A0 = rules for receivers of the Proxy Signature option imply that there = might

|=A0 |=A0 be = multiple proxies on a link as well as proxy responses colliding = with

|=A0 |=A0 direct responses.=A0 While there is = a discussion of scenarios for proxying

|=A0 |=A0 ND = messages, they are not discussions of topologies of the proxies

|=A0 |=A0 themselves.=A0 I believe that I = would have benefited from an explanation of

|=A0 |=A0 the topology envisioned = here.

|=A0

|=A0

|=A0 Well, we thought that a generic = discussion of the topologies of the proxies would

|=A0 have been out of the scope of the = document and the working group.

|=A0

|=A0 |=A0 Each SPND proxy must be able to = distinguish secure nodes (RFC3971 or SPND

|=A0 |=A0 = nodes) from insecure nodes (non-SEND) on the link for which it serves = as

|=A0 |=A0 proxy.=A0 It decides whether to = securely proxy ND messages received from

|=A0 |=A0 = those nodes based on that info.=A0 Is there any thought as to how the = SPND

|=A0 |=A0 proxy would know this?=A0 If this = is manual configuration, that could be a

|=A0 |=A0 = lot of work or impossible depending on the scenario.=A0 And if there = are

|=A0 |=A0 = multiple proxies on the link in some topologies, they must be = consistent.

|=A0

|=A0

|=A0 Well, I think this is specific to each = deployment scenario, and I think it is risky to

|=A0 include text going further than = presenting the security considerations.

|=A0

|=A0 Considering the 3 scenarios presented in = the draft:

|=A0

|=A0 - RFC4389 involves translating messages, = so it is trivial to know the SEND/non-

|=A0 SEND nature of the node. This is general = for translating scenarios, as commented

|=A0 in the draft in section = 7.

|=A0

|=A0 - PMIPv6 is very infrastructure = dependent. The proxied element is the router. I

|=A0 would expect the provider to know if all = MAGs support SEND or not (if any does

|=A0 not support SEND... then non-SEND = operation should be used).

|=A0

|=A0 - MIPv6. Here hosts are proxied, and the = HA synthesizes messages on behalf of

|=A0 the hosts. This is for me the most = complex scenario, and I'm not aware of any

|=A0 other solution than any kind of manual configuration (besides all nodes being

| =A0required to be SEND).

|=A0

|=A0 I think = the previous info can be derived directly from the text of the = draft.

|=A0

|=A0 However, new scenarios may arise, and this could be handled easier. = For

|=A0 example, assume proxy elements for = saving energy by allowing hosts to go to

|=A0 sleep when not being heavily used (a-la = ProxZZZy - www.ecma-

|=A0 international.org/publications/files/ECMA-ST/ECMA-393.pdf). In this case = the host

|=A0 would be in the same link as the proxy, = so previous communication should have

|=A0 occurred (in particular, to allow the = host to tell the proxy that it goes to sleep),

|=A0 so the proxy may know in advance if the = host is SEND or not.

|=A0

|=A0

|=A0

|=A0 |

|=A0 |=A0 I = was curious as to whether unsigned ND messages could be proxied = securely

|=A0 |=A0 by a SPND node. =A0Section 5.2.1 p = 10 says the PS option MUST be added,

|=A0 |=A0 = which satisfied me, but then Section 7.2 p 20 says there are cases = where

|=A0 |=A0 = the PS option MUST NOT be added.=A0 If that’s a contradiction, it needs = to

|=A0 |=A0 be = addressed

|=A0

|=A0

|=A0 Well, 5.2.1 describes operation = considering that the originating message is

|=A0 protected by SEND, so the proxied = message is also secured. So it MUST be added

|=A0 to be secured. I can add some words to = clarify that.

|=A0

|=A0 The part in which non-SEND hosts appear = is section 7.

|=A0

|=A0 This structure is analogous to the SEND specification.

|=A0

In section 5.2.1, added comment at the end of paragraph:

=A0=A0 “A secured NDP message sent by a Secure =
ND Proxy for a proxied address
=A0=A0 MUST contain a PS =
option and MUST NOT contain either CGA or =
RSA
=A0=A0 Signature =
options.=A0 Section 7 discusses in which cases a NDP =
message
=A0=A0 has to be secured =
in an scenario including non-SEND =
nodes.”

 

 

 

|=A0

|=A0 |=A0 = The text seems to make a distinction between "locally = generated"/"issued"

|=A0 |=A0 = messages for a proxied address and "forwarding" or "translating" a = message

|=A0 |=A0 from a proxied address.=A0 I was = never certain what cases might cause the

|=A0 |=A0 = local generation of an address.=A0 RFC4389 seem to me to refer only to = the

|=A0 |=A0 forwarding of messages.=A0 Perhaps = the "local generate" term refers to the

|=A0 |=A0 = scenario discussion in section 6.2 of Proxy Mobile IP, perhaps the = term

|=A0 |=A0 = refers to some of the exchanges in RFC4389 proxying.=A0 I’m not = sure.

|=A0

|=A0 Well, what it is trying to say is not = that the address is being generated or not, but

|=A0 the message.

|=A0

|=A0 The "forwarding" or "translating" case stands for the case in which a message = is

|=A0 received by the proxy through one = interface, and relayed to other. This is the

|=A0 case of RFC4389.

|=A0

|=A0 The "locally generated"/"issued" or "synthesized" stands for messages that are

|=A0 generated by the proxy without receiving = a message from the proxy. This is the

|=A0 MIPv6 and PMIP case.

|=A0

|=A0 Do you think it would be more clear if = this is included in the 'Terminology'

|=A0 section?

|=A0

 

‘Translated NDP message’ and ‘Synthetic NDP message’ have been included in the ‘Terminology’ section. These terms are now used consistently = all over the document.

 

|=A0 |

|=A0 |=A0 = After reading this, I was not sure that I had an adequate idea of = the

|=A0 |=A0 = error processing when different information has the potential to = conflict.

|=A0 |=A0 I = was particularly interested in the RA message. RFC4389 introduces a "P"

|=A0 |=A0 = bit for the RA messages to indicate a proxied message.=A0 This = draft

|=A0 |=A0 = introduces a PS option to secure proxied messages.=A0 The new cert = format

|=A0 |=A0 = has a "proxy" value for the KeyPurposeId.=A0 I tried to work out = the

|=A0 |=A0 combinations:

|=A0

|=A0 |

|=A0 |=A0 P = bit=A0=A0 PS opt=A0=A0 cert:"proxy" action

|=A0 |=A0=A0=A0=A0 0=A0 =A0=A0=A0=A0=A0no=A0=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 no proxy needed (can use = 3791)

|=A0 |=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 no proxy needed (can use = 3971)

|=A0 |=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 silent discard of = message

|=A0 |=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 weird but = OK?

|=A0 |=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 "unsecured", even if 3971 = signed?

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cert says not a proxy, so drop?

|=A0 |=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 "unsecured", = even if 3971 signed?

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 If 3971 signed, check 3971 cert

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 prefixes or new cert prefixes?

|=A0 |=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0 silent discard of = message

|=A0 |=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0 secure proxy – all = OK

|=A0

|=A0

|=A0 Well, the fourth case in the table needs = some though, while the others are ok:

|=A0

|=A0 The = "P" bit of RFC4389 is only meaningful for proxies, i.e. hosts does not = process

|=A0 it: the way the behavior of the = receivers is defined in section 4.1.3.3 is "When

|=A0 [...] arrives on the upstream = interface" or "[...] on the downstream interface"...

|=A0 The description always refers to = upstream and downstream, which are only

|=A0 relevant for RFC4389 = proxies.

|=A0

|=A0 Then, for hosts the first column is = irrelevant.

|=A0

|=A0 Assume = an RFC 4389 proxy with SPND enabled receives any message (in = this

|=A0 case, the 3 'switches' - P bit, PS opt, = cert opt- would be meaningful).

|=A0

|=A0 First, security is checked, which means = that the P bit should not be processed

|=A0 until the message is verified, and a = "security level" ('secured' or 'unsecured') is

|=A0 defined for the message. Then I don't = think a table in which the three elements

|=A0 are mixed together is a good = representation of the problem. Instead, I think its

|=A0 better to view the process as a sequence = of tie-breaking rules: 5.2.2 specifies the

|=A0 requirements for having a messages = validated as secured. Rule #1 just discards

|=A0 parts of the message that must not be = considered when analyzing its security.

|=A0

|=A0 Rule #2 requires a valid certificate = with 'proxy' value, and this certificate being

|=A0 linked to the message through the 'Key = Hash' field. If this fails, then the message

|=A0 is unsecured.

|=A0

|=A0 The rest of the rules check for the = validity of the PS option. So, I would say:

|=A0

|=A0 cert:"proxy"=A0=A0=A0=A0=A0 PS = opt=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 action

|=A0

|=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 unsecured

|=A0 no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = unsecured

|=A0 yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 no=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 This does = not have much sense: you cannot

|=A0 know to which cert is referring a = message if there is no PS opt with a Key Hash

|=A0 pointing to a cert.

|=A0 = yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = yes=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = secured

|=A0

|=A0 Then, = the question stated in your table: ""unsecured", even if 3971 = signed?

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 cert says not a proxy, so drop?"

|=A0

|=A0 Would be 'unsecured', and then discard = or not according to the configuration of

|=A0 the host regarding to backward = compatibility (accept 'unsecured' if configured to

|=A0 do so, and in any case do not replace = 'secured' information with 'unsecured' one)

|=A0

|=A0 Now we = can look at the P (RFC4389) bit. The case in which a secured = message

|=A0 from a proxy is received, but the bit P = is set to 0... this MUST NOT have been

|=A0 generated by a RFC4389 proxy (since = RFC4389 proxies always set the P bit). It

|=A0 could have been generated by other proxy = type - for example, a PMIPv6 MAG,

|=A0 which for the RFC4389 proxy would look = as a 'regular' router.

|=A0

|=A0 If the proxy were sure that only RFC4389 = proxy operation is allowed, then this

|=A0 situation is really strange (a proxy = that sends a RA message secured... that

|=A0 should be a RFC4389 proxy, but does not = set the bit P to 1), and probably, it

|=A0 should discard the = message.

|=A0

|=A0 Does this fully address your = question?

|=A0

|=A0

|=A0

|=A0 Do you think it would clarify to add = some text to the document? (I'm thinking

|=A0 specifically in the part of the = scenarios, probably adding to section 6.3, 'rule' 1, in

|=A0 which a summary of the processing which = RFC4863 proxies do before sending

|=A0 the packet, that the P bit must be = set.

|=A0

|=A0 And maybe a new sentence saying that = proxies receiving this info, if they are

|=A0 sure that only RFC4389 proxy operation = is allowed, could discard messages with

|=A0 valid PSO option but without the P bit? = (<-- not sure that this is very clarifying...)

|=A0

|=A0 |=A0 As = acknowledged in the Section 7.1, a RFC3971 message from a = RFC3971

|=A0 node

|=A0 |=A0 to = another RFC3971 node proxied through a SPND proxy appears unsecured = to

|=A0 |=A0 the receiver.=A0 That’s no = worse than proxying the message through a RFC3971

|=A0 |=A0 = proxy, so no harm done, for most messages.=A0 For Router = Solicitation

|=A0 |=A0 = messages, which according to RFC3489 don’t get altered and can = retain

|=A0 |=A0 = their signatures, the outcome is worse. I think.

|=A0

|=A0 I see your point.

|=A0

|=A0 RFC 4389, section 4.1 (and also draft-ietf-csi-proxy-send) states that

|=A0

|=A0 "This document covers the following = types:

|=A0=A0=A0=A0 Neighbor Solicitations, = Neighbor Advertisements, Router

|=A0=A0=A0=A0 Advertisements, and = Redirects. These packets are ones that can = carry

|=A0=A0=A0=A0 link-layer addresses, and hence = must be proxied [...]"

|=A0

|=A0 But I = think this is not completely true, since RFC4861 states that = Router

|=A0 Solicitations can also carry source = link-layer addresses:

|=A0

|=A0 "4.1.=A0 Router Solicitation = Message Format

|=A0

|=A0 [...]

|=A0

|=A0 Source link-layer address The link-layer = address of the sender, if

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 known.=A0 MUST NOT be included if the Source Address

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 is the unspecified address.=A0 Otherwise, it SHOULD

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 be included on link layers that have addresses."

|=A0

|=A0 It is clear for me that if the RS = message includes a "Source link-layer address

|=A0 option", it must also include a PS = option.

|=A0

|=A0 But, = could a SEND-protected RS message which does not include a = link-layer

|=A0 address be copied as-is in the other = interface? I think yes, since CGAs would be

|=A0 validated = consistently.

|=A0

|=A0 This would be the device you mention as "RFC3971 proxy", which by the way, I

|=A0 don't think has been defined. I mean, = should this "RFC3971 proxy" check for the

|=A0 validity of the original message, or = just let it pass and let the receiver doing the

|=A0 check? I think it should check (as the = SPND proxy does), but I don't have a clear

|=A0 opinion on this.

|=A0

|=A0 Then, I see two options for proxying = secure messages not including link-layer

|=A0 addresses:

|=A0

|=A0 1- Process as defined for the SPND proxy = (which is check for validity of the

|=A0 original message, include PS = option...)

|=A0

|=A0 2- check for validity of the original = message, and if it is valid, forward as-is

|=A0

|=A0 The first option seems more homogeneous. = The second one allows the validation

|=A0 of some messages by nodes which are = RFC3971 but not SPND. However, this is

|=A0 only for a very limited subset of the = proxied information, which is the one not

|=A0 including link-layer = addresses.

|=A0

|=A0 I tend to prefer 1, but without a clear = opinion.

|=A0

|=A0 What do you think?

|=A0

|=A0 Once clarified, the text of the RFC4389 = scenario should be updated.

|=A0

 

Done, (for Choice = 1)

 

|=A0

|=A0 |=A0 Detailed = comments:

|=A0

|=A0 |=A0 Sec 4, p 6:

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 Proxy ND's certificate.=A0 = When a ND message contains a PS option,

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 it MUST NOT contain CGA and RSA Signature options.=A0 This = option

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 can be appended to any ND message: NA, NS, RS, RA and = Redirect.

|=A0 |

|=A0

|=A0 |=A0 Is that a "MAY" be = appended?=A0 Page 10 says "MUST" be added, but section

|=A0 |=A0 = 7.2 p 20 talks of cases where it MUST NOT be added.

|=A0

|=A0 MUST be added to be = secured.

|=A0 MUST = NOT for non-SEND nodes.

|=A0

 

Changed

 

|=A0

|=A0

|=A0 Obviously, (as commented above), a = clarification saying that processing rules of

|=A0 section 5 are for generating/processing = secured messages must be included

|=A0

|=A0

|=A0 |=A0=A0=A0=A0=A0 o=A0 A modification of the SEND processing rules for all ND = messages:

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 NA, NS, RS, RA, and Redirect.

|=A0 |

|=A0 |=A0 = This draft and RFC4389 do not mention – if the proxied message is a = NA,

|=A0 |=A0 = and the proxy is a router, does the router bit get set?

|=A0

|=A0 I think = it should be set (I don't see any reason for not being set).

|=A0 Not = sure if I should 'complement' RFC4389 in this document...

|=A0

|=A0 |

|=A0 |=A0 Sec 5.2.1 p 10

|=A0 |

|=A0 |=A0 5.2.1.=A0 Processing rules for = senders

|=A0 |=A0=A0=A0=A0=A0 A ICMPv6 message sent by a Secure ND Proxy for a proxied address = MUST

|=A0 |=A0=A0=A0=A0=A0 contain a PS option and MUST NOT contain either CGA or RSA = Signature

|=A0 |=A0=A0=A0=A0=A0 = options.

|=A0 |

|=A0 |=A0 Note contradiction in section 7.2 p = 20.

|=A0

|=A0 Commented above

|=A0

|=A0

|=A0 |=A0 Sec 5.2.1 p 11

|=A0 |

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 C.=A0 If = the Secure ND Proxy is forwarding a SEND message already

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 containing a PS option, first the authenticity of = the

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 intercepted message is verified as specified in Section = 5.2.2

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = of this specification.=A0 If the SEND message is valid, the

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 original PS option MUST be removed from the message.=A0 = The

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 intercepted message is finally modified as described = in

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Section 4 of the ND Proxy specification [RFC4389].

|=A0 |

|=A0

|=A0 |=A0 Does this disagree with the RFC4389 = statement that RA messages can not be

|=A0 |=A0 received from other proxies?=A0 = That is, if an RA message P bit is set (and

|=A0 |=A0 if = it contains a PS option, one hopes the P bit is set), RFC4389 = sec

|=A0 |=A0 = 4.1.3.3 says the interface must not be used as a proxy interface.

|=A0

|=A0 No, I understand in a different way: RA = messages can be proxied many times.

|=A0 Assume

|=A0

|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 I1=A0 I2

|=A0

|=A0 Router ------ P1 ------- P2 = -----P3

|=A0

|=A0

|=A0 With I1 being the interface of P2 = connected to the router, and I2 the interface of

|=A0 P2 connected to P3.

|=A0

|=A0 What RFC4389 says is that when P1 = receives a RA, then it cannot be proxied to

|=A0 I1 (but it can to I2)

|=A0

|=A0

|=A0 I think there is no = disagreement.

|=A0

|=A0

|=A0 |=A0=A0=A0=A0=A0 2.=A0 Timestamp and = Nonce options MUST be included according to the

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 rules specified in SEND [RFC3971].=A0 The value in the = Timestamp

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 option MUST be generated by the proxy.=A0 If the proxy is

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 forwarding a message, the Nonce value in the proxied message = MUST

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 be the same as in the forwarded message, otherwise it is

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0 generated = by the proxy.

|=A0 |

|=A0

|=A0 |=A0 What is the "otherwise" = here?=A0 If the proxy is *not* forwarding, which

|=A0 |=A0 = might be if it is "locally generating" a message?=A0 If the Nonce is = not

|=A0 |=A0 = present in the forwarded messages?

|=A0

|=A0

|=A0 ‘Otherwise’ refers to = synthesizing locally the message. I thing this two behaviors

|=A0 (‘forwarding’, = ‘generating locally’) should be presented more clearly before = this

|=A0 rule (although this concepts are somehow = presented in rule 1).

|=A0

|=A0 = ‘Otherwise’ does not refer to the nonce. RFC3971 states that it is not = present for

|=A0 unsolicited advertisements. If a proxy = is receiving a message to be forwarded

|=A0 without the nonce (or otherwise), where = it should be, it will be marked as

|=A0 unsecured. Then the proxy will include = it “according to the

|=A0=A0=A0=A0=A0=A0=A0 rules specified in = SEND [RFC3971]”, as says the previous text.

|=A0

|=A0 I can = also change ‘otherwise’ with “If the proxy is synthesizing a = message …”, so

|=A0 ambiguity is definitely = resolved.

 

Done. Also = the ‘forwarding’/’generating locally’ terms have been removed (see a comment = above)

 

|=A0 |

|=A0 |=A0 = Sec 6.2 p 16

|=A0 |

|=A0 |=A0 = This scenario seems to be using the SPND feature because the MAG is = using

|=A0 |=A0 a = source address that does not really belong to it.=A0 It is not = forwarding

|=A0 |=A0 any ND messages.=A0 So perhaps this = is the case where the "locally

|=A0 |=A0 generated" terminology applies.

| =A0

|=A0 Yes, = this is one of the cases (the other is MIPv6 – note that in this case, = although

|=A0 the MN and HA is communicating, when a = host in the link of the HA generates a

|=A0 NS for the MN, the HA responds without retransmitting the request to the MN

|=A0 and then waiting back for the = answer)

|=A0

|=A0 |=A0=A0=A0=A0=A0 To provide SEND protection, each MAG is configured to act as a = proxy

|=A0 |=A0=A0=A0=A0=A0 by means of a certificate associated to the PMIPv6 domain,

|=A0 |=A0=A0=A0=A0=A0 authorizing each MAG to proxy securely ND messages.=A0 In addition, = the

|=A0 |=A0=A0=A0=A0=A0 certificate must also authorize the MAG to advertise prefixes.=A0 = Note

|=A0 |=A0=A0=A0=A0=A0 that the inclusion of multiple KeyPurposeId values is supported = by

|=A0 |=A0=A0=A0=A0=A0 [I-D.ietf-csi-send-cert].

|=A0

|=A0 |=A0 I = believe that means that the new cert format must show both the = router

|=A0 |=A0 = and the proxy KeyPurposeID values because it is generating a RA.=A0 But = no

|=A0 |=A0 = such check is mentioned anywhere.

|=A0

|=A0 Yes, you are right. Once clarified which KeyPurposeId should be used, this

|=A0 should be changed = also

|=A0

 

This has been already clarified =

 

|=A0

|=A0 |=A0 = Sec 6.2 p 16

|=A0 |

|=A0 |=A0=A0=A0=A0=A0 A node receiving a message from the MAG containing the PS option = MUST

|=A0 |=A0=A0=A0=A0=A0 apply the rules defined in Section 5.2.2.=A0 Note that = unsolicited

|=A0 |=A0=A0=A0=A0=A0 messages sent by MAG are validated by the host according to = timestamp

|=A0 |=A0=A0=A0=A0=A0 values specific to the MAG serving the link, not to any other MAG = to

|=A0 |=A0=A0=A0=A0=A0 which the host has been connected before in other links.

|=A0 |

|=A0

|=A0 |=A0 The host does not see any = difference in the MAG, since the MAG is using

|=A0 |=A0 = the same source IP address as all other MAGs to which the host has = been

|=A0 |=A0 connected.=A0 According to my = reading of RFC3971, that means that there’s a

|=A0 |=A0 = chance that unsolicited messages from the MAG would appear stale – as = long

|=A0 |=A0 as = the unsolicited message was received before a solicited = advertisement.

|=A0 |=A0 = Receipt of a solicited advertisement should update the timestamp at = the

|=A0 |=A0 = host, based on the nonce matching, by RFC3971 rules

|=A0

|=A0 Well, there is a risk that unsolicited = messages where considered unsecured due

|=A0 to different clocks in different = proxies. Then, what is suggested in section 5.2.2,

|=A0 rule 6, is that “The receiver = SHOULD store the peer-related timing information

|=A0 […] separately for each different = proxy (which can be identified by the different

|=A0 Key Hash values of the proxied message) = and separately from the timing

|=A0 information associated to the IP of node = for which the message is proxied”.

|=A0

|=A0 Maybe in section 6.2, a reference to = section 5.2.2, rule 6 could be added, so this

|=A0 issue would be = clarified.

|=A0

 

Done

 

|=A0

|=A0 |=A0 Sec 6.3 p 17/18

|=A0 |

|=A0 |=A0=A0=A0=A0=A0 A Secure ND Proxy shall parse any IPv6 packet it receives on a = proxy

|=A0 |=A0=A0=A0=A0=A0 interface to check whether it contains one of the following = secured

|=A0 |=A0=A0=A0=A0=A0 ICMPv6 messages: NS, = NA, RA, or Redirect.

|=A0 |

|=A0

|=A0 |=A0 This seems to disagree with Section = 5.2.1, p 10, which says the PS option

|=A0 |=A0 is = added to *all* messages.=A0 However, it does agree with the discussion = in

|=A0 |=A0 = section 7.2 p 19/20, which says that the PS option is only generated = on

|=A0 |=A0 = behalf of RFC3917 nodes and SPND nodes.

|=A0

|=A0

|=A0 Yes, this sentence implicitly assumes = that there may be unsecured messages,

|=A0 which is not the style of the rest of = the document, and only appears clearly in

|=A0 section 7.

|=A0

|=A0 I think it would be best to reword it so = that it does not suggest yet the possibility

|=A0 of unsecured = messages.

|=A0

 

Done

 

|=A0

|=A0 |

|=A0 |=A0 = Section 7.1 p 19

|=A0 |

|=A0 |=A0=A0=A0=A0=A0 In the scenarios in which the proxy translates ND messages, = the

|=A0 |=A0=A0=A0=A0=A0 messages to translate can either be originated in a RFC3971 node = or

|=A0 |=A0=A0=A0=A0=A0 in an SPND node, without interoperability issues.

|=A0 |

|=A0

|=A0 |=A0 The discussion immediately above = this text says that RFC3971 nodes drop a

|=A0 |=A0 PS = option in a proxied message and treat the message as unsecured, so I = am

|=A0 |=A0 = not sure what this is talking about.=A0 A secure proxied NA reply, = for

|=A0 |=A0 = example, would appear unsecured to the RFC3971 host and secure to = the

|=A0 SPND

|=A0 |=A0 proxied host. Is = "translates" an ND message different from

|=A0 |=A0 "forwards"/"proxies" an ND message – i.e., the = PS option is not applied?

|=A0

|=A0

|=A0 The key word of this paragraph (the = third) is ‘originated’, while in the first

|=A0 paragraph of section 7.1 the key word is ‘received’. What this is saying is that a

|=A0 proxy can secure a message generated = either in a RFC3971 or SPND node, since

|=A0 regarding to the rules of generating ND = messages, both behave exactly the same

|=A0 (the difference is in the receiving = rules for PS options).

|=A0

|=A0 I can clarify a bit this = differences

|=A0

 

Added “(note that the difference = between RFC3971 nodes and SPND nodes only affect to the ability to process received NDP messages containing a PS option, not in the way they generate messages = secured by SEND)” at the end of the = paragraph.

 

=A0

|=A0

|=A0 |

|=A0 |=A0 = sec 7.2 p 20

|=A0 |

|=A0 |=A0=A0=A0=A0=A0 Therefore, the Secure ND Proxy MUST generate messages containing = the

|=A0 |=A0=A0 = =A0=A0=A0PS option for SPND and RFC3971 hosts, and MUST NOT generate = messages

|=A0 |=A0=A0=A0=A0=A0 containing the PS option for non-SEND nodes.

|=A0 |

|=A0 |=A0 = This (and other places in the subsequent paragraphs) seems to = contradict

|=A0 |=A0 = sec 5.2.1 p 10 which says the PS option is a MUST, period.

|=A0

|=A0 This is related with the acceptance of secured/unsecured message, and as

|=A0 discussed above, should be clarified, = starting in section 5.

|=A0

|=A0 |=A0 = What does the "for SPND and RFC3971 hosts" and the "for non-SEND = hosts"

|=A0 |=A0 mean?=A0 I believe that it means = that the proxy is forwarding messages on

|=A0 |=A0 their behalf.=A0 The use of the = term "generate" here doesn’t seem to mean

|=A0 |=A0 = the same as "locally generated" elsewhere.

|=A0

|=A0 Yes, you are right, this is imprecise. = In this case “generate” means both

|=A0 ‘forwarding’ and ‘synthesizing’. This should be clarified.

=A0

Done

=A0

|=A0 |=A0 I = am not sure how the SPND would know which of the nodes on the = proxy

|=A0 |=A0 = interface were non-SEND, RFC3917, or SPND nodes.=A0 But if it can = be

|=A0 This is = not addressed in this document. I have commented about this above = in

|=A0 this email, in a paragraph starting by = “Well, I think this is specific to each

|=A0 deployment scenario […]”

|=A0

|=A0 |=A0 = configured with that information, could it also be configured to know = the

|=A0 |=A0 = status of nodes on the outgoing interface?=A0 It might then detect = that

|=A0 |=A0 = doing the computation to add the PS option was a waste of effort = because

|=A0 |=A0 = there were no SPND nodes on that side.

|=A0 |

|=A0

|=A0 |=A0 If the RFC3971 node produces a = solicitation that needs to be forwarded

|=A0 |=A0 = through the SPND proxy, and the SPND proxy forwards the advertisement = it

|=A0 |=A0 = received in reply along with the PS option, the RFC3971 will drop the = PS

|=A0 |=A0 option.=A0 True?=A0 Should the SPND = still produce the (wasted) signature?

|=A0

|=A0 Yes, this is true. Of course this could = optimize SPND operation.

|=A0

|=A0 However, this may or may not be reasonable, depending on the scenario = and

|=A0 particular configuration. For example, = for PMIPv6, the proxy only performs its

|=A0 function for the MAG, not for any host, = so it is not evident that the proxy knows if

|=A0 a node is SPND or not. For MIPv6, the = proxy may or may not know the SPND or

|=A0 not (maybe, it knows when the node moves = away, by accessing to some

|=A0 database, but not if the node is in the link…)

|=A0

|=A0 I feel = that this is too related with optimization, that should not be included in = the

|=A0 document. Another option is to include a = MAY statement in section 7 commenting

|=A0 this possibility, in a generic way, just = for the sake of completeness. What do you

|=A0 think?

|=A0

|=A0

|=A0 |=A0 Sec 7.2 page 20

|=A0 |

|=A0 |=A0=A0=A0=A0 o=A0 For translating ND messages for nodes that can arrive to the = link

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 in which the proxy operates,

|=A0 |=A0 …

|=A0

|=A0 |=A0=A0=A0=A0=A0 o=A0 For synthesizing = ND messages on behalf of remote nodes,

|=A0 |

|=A0 |=A0 I = think "translating" here means forwarding through the proxy and = doing

|=A0 |=A0 = the RFC4389 changes, while "synthesizing ND messages" means the = mobile

|=A0 |=A0 = node scenarios where no message is received for forwarding but one = is

|=A0 |=A0 = created (PMIPv6 and MIPv6?).

|=A0 |

|=A0 |=A0 An = explanation of this difference and a consistent set of terms would = have

|=A0 |=A0 helped a lot.

|=A0

|=A0 Yes, I’m really convinced. = I will

|=A0

|=A0

|=A0 |

|=A0 |=A0=A0=A0=A0=A0 o=A0 For translating ND messages for nodes that can arrive to the = link

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 in which the proxy operates, the rule can be easily applied: = only

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 messages validated in the Secure ND Proxy according to the = SEND

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 specification [RFC3971] MUST be proxied securely by the = inclusion

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 of a PS = option.=A0 Unsecured ND messages could be proxied if

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 unsecured operation is enabled in the proxy, but the message

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 generated by the Secure ND Proxy for the received message MUST = NOT

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0 include a PS option.

|=A0 |

|=A0 |=A0 Is = it possible for a proxy to receive a message with a PS option?

|=A0

|=A0 Yes it is, for example for the RFC4389 = case

|=A0

|=A0 |=A0 = Previous text (sec 5.2.1 part C) seems to indicate so.=A0 If the "MUST = be

|=A0 |=A0 = proxied securely" applies to SPND protected messages as well as = RFC3971

|=A0 |=A0 = protected messages, then this case is the same as the previous = paragraph

|=A0 |=A0 = "MUST generate messages containing the PS option for SPND and = RFC3971

|=A0 |=A0 hosts . . .".=A0 Unless this = is a difference between translating messages

|=A0 |=A0 = and generating messages, of course.

|=A0

|=A0 Yes. I include the PS option = here.

|=A0

 

The following text has been = included:

“For scenarios in which ND messages are translated for nodes that

=A0=A0=A0=A0=A0 can arrive to the link in = which the proxy operates, the rule can

=A0=A0=A0=A0=A0 be easily applied: only for = messages validated in the Secure ND

=A0=A0=A0=A0=A0 Proxy according to the SEND = specification [RFC3971], or according

=A0=A0=A0=A0=A0 to Section 5.2.2 of this = specification for messages containing a

=A0=A0=A0=A0=A0 PS option (which means that = another proxy previously checked that

=A0=A0=A0=A0=A0 the original message was = secured) […]”

 

|=A0 |=A0 = Sec 8 p 22

|=A0 |

|=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 However, when two on-link hosts communicate using

|=A0 |=A0=A0=A0=A0=A0 their respective link-local addresses, the threats involved with = a

|=A0 |=A0=A0=A0=A0=A0 compromised router and a compromised proxy ND differs because = the

|=A0 |=A0=A0=A0=A0=A0 router is not able to siphon off traffic exchanged between the = hosts

|=A0 |=A0=A0=A0=A0=A0 or mount a man-in-the-middle attack, while the proxy ND can, even = if

|=A0 |=A0=A0=A0=A0=A0 the hosts use SEND.

| =A0|

|=A0 |=A0 = This should be explained in more detail.=A0 I believe that the reason = is

|=A0 |=A0 = that a SEND router would not be able to produce a NA reply to an NS = that

|=A0 |=A0 = would be believed, but the SPND could pretend to be proxying a NA = reply

|=A0 |=A0 = believably – as long as the recipient used SPND and could accept the = PS

|=A0 |=A0 option.

|=A0

|=A0 Yes, that’s the reason why. I will = include a text similar to this to explain.

|=A0

 

I have substituted the cited text with = this:

“=A0=A0 A compromised Secure ND Proxy = provisioned with an authorization

=A0=A0 certificate with a KeyPurposeId value = of id-kp-sendProxiedRouter is

=A0=A0 able, like a compromised router to = siphon off traffic from the host,

=A0=A0 or mount a man-in-the-middle attack, = for hosts communicating to off-

=A0=A0 link hosts.=A0 A compromised Secure ND = Proxy provisioned with an

=A0=A0 authorization certificate with a = KeyPurposeId value of id-kp-

=A0=A0 sendProxiedOwner can siphon off = traffic or mount a man-in-the-middle

=A0=A0 attack for communication between = on-link hosts, even if the hosts use

=A0=A0 SEND.=A0 Note that different = application scenarios may require one type

=A0=A0 of authorization, the other, or = both.=A0 To minimize security risks,

=A0=A0 authorization capabilities SHOULD NOT = exceed the ones strictly

=A0=A0 required by the application scenario = to be deployed.”

 

 

|=A0

|=A0 |

|=A0 |=A0=A0=A0=A0=A0 Proper configuration of when the PS option must or must not = be

|=A0 |=A0=A0=A0=A0=A0 included, depending on the proxied nodes being SEND or non-SEND = may

|=A0 |=A0=A0=A0=A0=A0 result in security considerations which are discussed in Section = 7.

|=A0 |

|=A0

|=A0 |=A0 This is pretty contorted.=A0 I = believe that this is trying to say that

|=A0 |=A0 = Section 7 discusses some of the security considerations resulting from = the

|=A0 |=A0 = decision to append or omit PS protections depending on the SEND = awareness

|=A0 |=A0 of the proxied nodes.=A0 But = I’m not sure.

|=A0

|=A0 Yes, yours is a more accurate wording. = I include, thanks

|=A0

Done

 

|=A0

|=A0 |=A0=A0=A0=A0=A0 Attacks to the timestamp of the secured ND message can be = performed

|=A0 |=A0=A0=A0=A0=A0 as described in section 7.3 of [I-D.ietf-csi-sndp-prob].

|=A0 |

|=A0 |=A0 I = found that section of that draft to be particularly unclear.=A0 And it = is

|=A0 |=A0 not normatively cited here.=A0 = I’m not saying that it should be, but if that

|=A0 |=A0 = draft does not progress (giving opportunity to improve the = discussion),

|=A0 |=A0 = the reader of this draft would be lost.=A0 Is there any way to summarize = the

|=A0 |=A0 = vulnerabilities so that the reader of this draft have some hint of = what

|=A0 |=A0 = can go wrong and why?

|=A0

|=A0

|=A0 [I-D.ietf-csi-sndp-prob] is in AUTH48 = status, so… I assume it will progress.

|=A0 I agree = that some hints should be included in draft-ietf-csi-proxy-send, and = also

|=A0 indicating how the particular way = Timestamp is handled here affects to security.

|=A0 Then, I suggest substituting the text = you cited with the text below.

|=A0

|=A0 I also think the detail (and credit) of = the problem statement could be that of [I-

|=A0 D.ietf-csi-sndp-prob], so I end the = paragraph referring to it, and I’m not

|=A0 explaining completely its = text.

|=A0

|=A0 Do you think this is = ok?

|=A0

|=A0 “Protection against reply attacks from unsolicited messages such as = Neighbor

|=A0 Advertisements, Router Advertisements, = and Redirects is provided by the use of

|=A0 the Timestamp option. When Secure ND = Proxy is used, each proxy and the host

|=A0 for which a proxy acts on behalf are = considered to be different peers in terms of

|=A0 Timestamp verification. Since the = information provided by the host and a proxy

|=A0 maybe different, including different = link-layer addresses, a reply attack could

|=A0 affect the operation of a third node: = replying messages issued by a host that is

|=A0 no longer in the link can prevent the = use of a proxy, and replying messages of a

|=A0 proxy when the host is back in the link = can prevent the access to the host. This

|=A0 kind of attacks can be performed until = the timestamp of the peer (either the host

|=A0 or a proxy) is no longer valid for the = receiver. The window of vulnerability is in

|=A0 general larger for the first message = received from a new peer than for

|=A0 subsequent messages received from the = same peer (see RFC3971). A more

|=A0 detailed analysis of the possible = attacks is described in section 7.3 of [I-D.ietf-csi-

|=A0 sndp-prob].”

|=A0

 

Included

 

|=A0

|=A0 |

 

The rest of the email referred to = NITS, which I have changed.

 

Regards,<= /p>

Alberto

------=_NextPart_000_006F_01CB5F2F.2EE43340-- From new-work-bounces@ietf.org Tue Sep 28 10:00:11 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EB533A6DF9; Tue, 28 Sep 2010 10:00:11 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5776F3A6D6C; Tue, 28 Sep 2010 10:00:03 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100928170003.5776F3A6D6C@core3.amsl.com> Date: Tue, 28 Sep 2010 10:00:03 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 10:31:32 -0700 Subject: [secdir] [new-work] WG Review: Application Bridging for Federated Access Beyond web (abfab) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 17:00:11 -0000 A new IETF working group has been proposed in the Security 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, October 5, 2010. Application Bridging for Federated Access Beyond web (abfab) ------------------------------------------------------------ Status: Proposed Working Group Last updated: 2010-09-16 v7 Chairs Leif Johansson Klaas Wierenga Security Area Directors: Sean Turner Tim Polk Security Area Advisor: Sean Turner Mailing Lists: General Discussion: abfab@ietf.org To Subscribe: Archive: Problem Statement Federated identity facilitates the controlled sharing of information about principals, commonly across organisational boundaries. This avoids redundant registration of principals who operate in multiple domains, reducing administrative overheads and improving usability while addressing privacy-related concerns and regulatory and statutory requirements of some jurisdictions. A number of such mechanisms are in use for the Web. This working group will specify a federated identity mechanism for use by other Internet protocols not based on HTML/HTTP, such as for instance IMAP, XMPP, SSH and NFS. The design will combine existing protocols, specifically the Extensible Authentication Protocol (EAP - RFC 3748), Authentication, Authorization and Account Protocols (RADIUS - RFC 2865 and Diameter - RFC 3588), and the Security Assertion Markup Language (SAML). Specifically EAP will be used to authenticate the subject to a trusted party, AAA (RADIUS and Diameter) will be used to authenticate and convey information from that party to a relying party and SAML and SAML message formats are used to carry subject information that can be used for authorization and personalization by a relying party. Any change in the choices for these three technical roles is out of scope for this charter. Constraints ----------- Initially the working group will focus on using GSS-API (RFC2743) as a mechanism for integrating the developed solution for federated identity into application protocols but other technologies for application interface are in scope of the working group and may be adopted as deliverables subject to the normal IETF consensus and (re)charter process. In order to be usable in all current Internet protocols, GSS-API mechanism must provide the following features: mutual authentication, key confirmation, host-based service naming, per-message tokens ("security layers") and channel binding. Support for Pseudo Random Function (PRF) is desirable, and generally feasible whenever per-message tokens are supported. As a result, all of those features are required for GSS-API mechanisms produced by this WG. Note also that some of these requirements derive from SASL (RFC 4422) applications, which can use GSS- API mechanisms through GS2 (RFC5081). Other application integration strategies are very likely to mirror these constraints. In particular, host-based service naming, mutual authentication and support for channel binding are likely to be important for defense against phishing attacks. The working group will ensure that any solution developed has technical controls for privacy protection. Other than a change to its applicability statement and the development of EAP mechanisms, the working group may not change EAP, RADIUS or Diameter without establishing consensus with the appropriate community within the IETF. The working group will use the following documents as a starting point for its work: - draft-howlett-eap-gss-00, - draft-howlett-radius-saml-attr-00 - draft-hartman-gss-eap-naming-00 Concerns have been raised that additional work is required in keying AAA associations in a federated environment. The working group is chartered to explore these concerns and if needed, specify protocols that use existing AAA key management mechanisms to address these concerns. Coordination with other SDOs ---------------------------- The Working Group will work in conjunction with the IAB to establish appropriate liaison relationships with the OASIS Security Services Technical Committee (SSTC) and take care that any changes or profiling required in SAML can be properly coordinated across the different organizations. In particular coordination is required with respect to the SAML-RADIUS binding. Deliverables ------------ 1. Descriptions of applicable use cases (informational). 2. An architecture that describes how the components of the solution fit together to address the use cases and open issues that will require future changes to the architecture (informational). 3. A standards-track update to the EAP applicability statement in RFC 3748 describing the applicability of EAP to application authentication and placing appropriate requirements on this new EAP use case. 4. A standards-track solution for using EAP methods to provide authentication within the application. 5. A standards-track update to the EMSK root key applicability statement in RFC 5295. 6. A standards-track description of GSS names and name attributes required by the solution. 7. Descriptions of usability and user-interface concerns related to this work (informational). 8. A standards-track protocol for carrying SAML messages in RADIUS and Diameter. Goals and Milestones -------------------- Oct 2010 Submit Internet draft describing applicable use cases as initial WG item. Oct 2010 Submit Internet draft describing the architecture as initial WG item. Oct 2010 Submit Internet draft that updates the EAP applicability statement as initial WG item. Oct 2010 Submit Internet draft for using EAP methods to provide authentication within the application as initial WG item. Oct 2010 Submit Internet draft that updates the EMSK root key applicability statement as initial WG item. Oct 2010 Submit Internet draft that describes GSS names and name attributes as initial WG item. Oct 2010 Submit Internet draft for usability and user-interface concerns as initial WG item. Oct 2010 Submit Internet draft for SAML messages in Radius and Diameter as an initial WG item. Dec 2010 Submit Internet draft describing applicable use cases to the IESG for consideration. Dec 2010 Submit Internet draft describing the architecture to the IESG for consideration. May 2011 Submit Internet draft that updates the EAP applicability statement to the IESG for consideration. May 2011 Submit Internet draft for using EAP methods to provide authentication within the application to the IESG for consideration. Aug 2011 Submit Internet draft that updates the EMSK root key applicability statement to the IESG for consideration. Aug 2011 Submit Internet draft that describes GSS names and name attributes to the IESG for consideration. Aug 2011 Submit Internet draft for usability and user-interface concerns to the IESG for consideration. Dec 2011 Submit Internet draft for SAML messages in Radius and Diameter to the IESG for consideration. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Sep 28 10:15:29 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECC533A6E0C; Tue, 28 Sep 2010 10:15:29 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6A5033A6B5A; Tue, 28 Sep 2010 10:15:08 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100928171511.6A5033A6B5A@core3.amsl.com> Date: Tue, 28 Sep 2010 10:15:08 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 10:31:32 -0700 Subject: [secdir] [new-work] WG Review: Web Security (websec) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 17:15:30 -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, October 5, 2010. Web Security (websec) --------------------------------------------- Status: Proposed Working Group Last updated: 2010-09-23 Chairs(s) Tobias Gondrom Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Security Area Advisor: Sean Turner Mailing Lists: General Discussion: hasmat@ietf.org To Subscribe: Archive: [to be changed to websec@ietf.org if approved] Problem Statement Although modern Web applications are built on top of HTTP, they provide rich functionality and have requirements beyond the original vision of static web pages. HTTP, and the applications built on it, have evolved organically. Over the past few years, we have seen a proliferation of AJAX-based web applications (AJAX being shorthand for asynchronous JavaScript and XML), as well as Rich Internet Applications (RIAs), based on so-called Web 2.0 technologies. These applications bring both luscious eye-candy and convenient functionality, e.g. social networking, to their users, making them quite compelling. At the same time, we are seeing an increase in attacks against these applications and their underlying technologies. The list of attacks is long and includes Cross-Site-Request Forgery (CSRF)-based attacks, content-sniffing, cross-site-scripting (XSS) attacks, attacks against browsers supporting anti-XSS policies, clickjacking attacks, malvertising attacks, as well as man-in-the-middle (MITM) attacks against "secure" (e.g. Transport Layer Security (TLS/SSL)-based) web sites along with distribution of the tools to carry out such attacks (e.g. sslstrip). Objectives and Scope With the arrival of new attacks the introduction of new web security indicators, security techniques, and policy communication mechanisms have sprinkled throughout the various layers of the Web and HTTP. The goal of this working group is to compose an overall "problem statement and requirements" document derived from surveying the issues outlined in the above section ([1] provides a starting point). The requirements guiding the work will be taken from the Web application and Web security communities. The scope of this document is HTTP applications security, but does not include HTTP authentication, nor internals of transport security which are addressed by other working groups (although it may make reference to transport security as an available security "primitive"). See the "Out of Scope" section, below. Additionally, the WG will standardize a small number of selected specifications that have proven to improve security of Internet Web applications. Initial work will be the following topics: - Same origin policy, as discussed in draft-abarth-origin (see also Appendices A and B, below) - HTTP Strict transport security, as discussed in draft-hodges-strict-transport-sec - Media type sniffing, as discussed in draft-abarth-mime-sniff This working group will work closely with IETF Apps Area WGs (such as HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working group(s) (e.g. HTML, WebApps). Out of Scope As noted in the objectives and scope (above), this working group's scope does not include working on HTTP Authentication nor underlying transport (secure or not) topics. So, for example, these items are out-of-scope for this WG: - Replacements for BASIC and DIGEST authentication - New transports (e.g. SCTP and the like) Deliverables 1. A document illustrating the security problems Web applications are facing and listing design requirements. This document shall be Informational. 2. A selected set of technical specifications documenting deployed HTTP-based Web security solutions. These documents shall be Standards Track. Goals and Milestones Oct 2010 Submit "HTTP Application Security Problem Statement and Requirements" as initial WG item. Oct 2010 Submit "Media Type Sniffing" as initial WG item. Oct 2010 Submit "Web Origin Concept" as initial WG item. Oct 2010 Submit "Strict Transport Security" as initial WG item. Feb 2011 Submit "HTTP Application Security Problem Statement and Requirements" to the IESG for consideration as an Informational RFC. Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Web Origin Concept" to the IESG for consideration as a Standards Track RFC. Mar 2011 Submit "Strict Transport Security" to the IESG for consideration as a Standards Track RFC. Apr 2011 Possible re-chartering References [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy Framework", W2SP position paper, 2010. http://w2spconf.com/2010/papers/p11.pdf Appendices A. Relationship between origin work in IETF WebSec and W3C HTML WG draft-abarth-origin defines the nuts-and-bolts of working with origins (computing them from URIs, comparing them to each other, etc). HTML5 defines HTML-specific usage of origins. For example, when making an HTTP request, HTML5 defines how to compute which origin among all the origins rendering HTML is the one responsible for making the request. draft-abarth-origin then takes that origin, serializes it to a string, and shoves it in a header. B. Origin work may yield two specifications There also seems to be demand for a document that describes the same-origin security model overall. However, it seems like that document ought to be more informative rather than normative. The working group may split draft-abarth-origin into separate informative and standards track specifications, the former describing same-origin security model, and the latter specifying the nuts-and-bolts of working with origins (computing them from URLs, comparing them to each other, etc). _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From new-work-bounces@ietf.org Tue Sep 28 10:30:07 2010 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7B843A6DFB; Tue, 28 Sep 2010 10:30:07 -0700 (PDT) X-Original-To: new-work@ietf.org Delivered-To: new-work@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 36A103A6D53; Tue, 28 Sep 2010 10:30:01 -0700 (PDT) From: IESG Secretary To: new-work@ietf.org Mime-Version: 1.0 Message-Id: <20100928173002.36A103A6D53@core3.amsl.com> Date: Tue, 28 Sep 2010 10:30:02 -0700 (PDT) X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.9 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, 28 Sep 2010 10:31:32 -0700 Subject: [secdir] [new-work] WG Review: Applications Area Working Group (APPSAWG) X-BeenThere: secdir@ietf.org Reply-To: iesg@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2010 17:30:08 -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, October 5, 2010. Applications Area Working Group (APPSAWG) ------------------------------------------ Current Status: Proposed Working Group Last updated: 2010-09-24 Chair(s): TBD Applications Area Directors: Alexey Melnikov Peter Saint-Andre Applications Area Advisor: Alexey Melnikov Mailing Lists: TBD Description of Working Group: The Applications Area Directors sometimes receives proposals for the development of specifications dealing with application-related topics that are not in scope for an existing working group and do not justify the formation of a new working group. The Applications Area Working Group (APPSAWG) can serve as a forum for such work in the IETF. The APPSAWG accepts work items in accordance with the consensus of the Working Group and the best judgment of the Applications Area Directors, who are responsible for updating the working group milestones as needed. The working group meets if there are active proposals that require intensive discussion. Work items that are appropriate for the APPSAWG mostly fall under the following topics: (A) Well-defined security issues that are relevant to multiple application technologies (e.g., draft-saintandre-tls-server-id-check). (B) Small-scale additions to the protocol stack for HTTP and other application technologies, mostly related to service discovery and meta-data (e.g., RFC 5785, draft-nottingham-http-link-header, and draft-hammer-hostmeta). (C) Selected other work items addressing topics that historically fall within the Applications Area, such as calendaring, date and time formats, HTTP, internationalization, language tags, MIME, URIs and XML. When considering whether to accept a proposed work item, the APPSAWG and the Applications Area Directors shall take into account the following factors, among others: (1) Whether the WG has consensus on the suitability, importance, and projected quality of the proposed work item. (2) Whether there is core team of WG participants with sufficient energy and expertise to advance the proposed work item according to the proposed schedule. (3) Whether there are enough WG participants who are willing to review the work produced by the document authors or editors. (4) Whether the Area Directors judge that wider input is needed before accepting the proposed work item (e.g., from the IESG, IAB, or another standards development organization). (5) There is no existing related Working Group that is willing to recharter to take on this work, and the document doesn't justify the formation of a new working group. In order to evaluate success of this WG, it is deliberately limited in its duration. The WG needs to close or be rechartered to remove this restriction before July 2011. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work