From emu-bounces@ietf.org Fri Dec 01 15:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqErB-0004wx-7n; Fri, 01 Dec 2006 15:19:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqErA-0004ws-0k for emu@ietf.org; Fri, 01 Dec 2006 15:19:36 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqEr8-0007EB-JH for emu@ietf.org; Fri, 01 Dec 2006 15:19:36 -0500 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id VAA56192 ; Fri, 1 Dec 2006 21:16:38 +0100 Received: from 86.66.211.110 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Fri, 1 Dec 2006 21:20:45 +0100 (CET) Message-ID: <61591.86.66.211.110.1165004445.squirrel@www.isima.fr> In-Reply-To: References: Date: Fri, 1 Dec 2006 21:20:45 +0100 (CET) Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 From: badra@isima.fr To: "Joseph Salowey \(jsalowey\)" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: bernard_aboba@hotmail.com, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Dear Joe, Bernard and all, Section 2.7 describes a way to securely send the client certificate. It assumes that the client permits renegotiation after the first server authentication. However, this requires more cryptographic computations since both entities will encrypt the second TLS session packets and it augments significantly the number of rounds trips over the wireless link, which is not always widely available. Moreover, this sensitivity increases a DoS attack's effectiveness against the authentication server, especially in the case where the client is not configured to renegotiate a second TLS session. It is IMHO useful to negotiate identity protection asap. Hajjeh and I recently submitted a document to add identity protection to TLS. This solution does not suffer from interoperability issues related to TLS Extensions, TLS 1.0 and TLS 1.1 implementations. I would like that EAP-TLS reconsider this document for identity protection implementations. The document is available for your review and comments at http://www.ietf.org/internet-drafts/draft-hajjeh-tls-identity-protection-00.txt Best regards, Badra > This is a working group last call for draft-simon-emu-rfc2716bis-05. > > Please send you comments to the emu list by December 29, 2006. > > The document can be accessed here: > http://www.ietf.org/internet-drafts/draft-simon-emu-rfc2716bis-05.txt. > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Dec 01 16:03:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFXO-0000rm-Po; Fri, 01 Dec 2006 16:03:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqFXO-0000ns-3X for emu@ietf.org; Fri, 01 Dec 2006 16:03:14 -0500 Received: from bay0-omc3-s41.bay0.hotmail.com ([65.54.246.241]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqFXM-00087R-PT for emu@ietf.org; Fri, 01 Dec 2006 16:03:14 -0500 Received: from hotmail.com ([207.46.8.114]) by bay0-omc3-s41.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Dec 2006 13:03:12 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 1 Dec 2006 13:03:12 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Fri, 01 Dec 2006 21:03:07 GMT X-Originating-IP: [131.107.0.73] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <61591.86.66.211.110.1165004445.squirrel@www.isima.fr> From: "Bernard Aboba" To: badra@isima.fr, jsalowey@cisco.com Bcc: Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 Date: Fri, 01 Dec 2006 13:03:07 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Dec 2006 21:03:12.0194 (UTC) FILETIME=[1C8CC220:01C7158C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org >However, this requires more cryptographic computations >since both entities will encrypt the second TLS session packets and it >augments significantly the number of rounds trips over the wireless link, >which is not always widely available. As you point out, the approach described in the document is not optimal; rather the goal was to provide functionality that could be most easily implemented, and would be "good enough". The computational load of encrypting additional packets is fairly small compared with the initial TLS negotiation, which may involve public key computations, so I don't think this is much of a burden. I believe that the proposed approach adds 1.5 round trips to an initial conversation (session resumption is not affected). As noted in the draft, ciphersuite negotiation could eliminate this. On the other hand, the total number of round-trips in EAP-TLS is largely determined by the certificate chain size, which is the same whether privacy is supported or not. So adding 1.5 round-trips for an initial exchange will typically not represent much of a performance penalty in intranet scenarios. >Hajjeh and I recently submitted a document to add identity protection to >TLS. This solution does not suffer from interoperability issues related to >TLS Extensions, TLS 1.0 and TLS 1.1 implementations. I would like that >EAP-TLS reconsider this document for identity protection implementations. If and when identity protection ciphersuites are added to TLS, EAP-TLS implementations can support it. I agree that it would be somewhat more efficient in terms of round-trips. However, I don't think we want to require that EAP-TLS implementations wishing to implement privacy support identity protection ciphersuites. For example, the set of Identity protection ciphersuites described in the document are limited, so that an EAP-TLS implementation might not be able to negotiate the ciphersuites that it would prefer along with identity privacy. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Fri Dec 01 17:43:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqH5x-0007XM-Aq; Fri, 01 Dec 2006 17:43:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GqH5v-0007X9-Hh for emu@ietf.org; Fri, 01 Dec 2006 17:42:59 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GqH5n-0005Jh-DP for emu@ietf.org; Fri, 01 Dec 2006 17:42:59 -0500 Received: from www.isima.fr (www.isima.fr [193.55.95.79]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with SMTP id XAA43376 ; Fri, 1 Dec 2006 23:41:13 +0100 Received: from 86.66.211.110 (SquirrelMail authenticated user badra) by www.isima.fr with HTTP; Fri, 1 Dec 2006 23:45:19 +0100 (CET) Message-ID: <62040.86.66.211.110.1165013119.squirrel@www.isima.fr> In-Reply-To: References: <61591.86.66.211.110.1165004445.squirrel@www.isima.fr> Date: Fri, 1 Dec 2006 23:45:19 +0100 (CET) Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 From: badra@isima.fr To: "Bernard Aboba" User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Hi Bernard, >So > adding 1.5 round-trips for an initial exchange will typically not > represent > much of a performance penalty in intranet scenarios. Does the server send no empty certificate_request in each TLS session? If then it will cost at least 2 more round-trips. Whatever, my concern is about charging the server, especially when forged clients try to connect. The authentication server will not be able to detect such an action early. >the set of Identity protection ciphersuites described in the > document are limited, so that an EAP-TLS implementation might not be able > to > negotiate the ciphersuites that it would prefer along with identity > privacy. Recently, there was a discussion on the TLS mailing list* regarding static DH implementation, showed that the static DH ciphersuites rarely seems to be supported, especially with (http://www1.ietf.org/mail-archive/web/tls/current/msg00856.html) - The Certicom SSL-C. - cryptlib (definitely doesn't do static DH). - PureTLS (hasn't tested static DH). - OpenSSL I don't know if TLS implementations of Microsoft support static DH ciphersuites. Identity protection ciphersuites supports all ciphersuites except those based on static DH (static DH may be added, but not a full identity protection will be therefore provided). Best regards, Badra _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Dec 11 10:08:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtmlh-0003Z8-Ev; Mon, 11 Dec 2006 10:08:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gtmlg-0003Z2-3J for emu@ietf.org; Mon, 11 Dec 2006 10:08:36 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gtmlb-0002i5-IQ for emu@ietf.org; Mon, 11 Dec 2006 10:08:36 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBBF7pvZ025125 for ; Mon, 11 Dec 2006 17:08:10 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 17:08:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 11 Dec 2006 17:08:22 +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: Mon, 11 Dec 2006 17:08:28 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WGLC comments for draft-simon-emu-rfc2716bis Thread-Index: AccdNjaVUVsf8Sb1T3aZH2ooZZr1Bw== From: To: X-OriginalArrivalTime: 11 Dec 2006 15:08:22.0085 (UTC) FILETIME=[32C96F50:01C71D36] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [Emu] WGLC comments for draft-simon-emu-rfc2716bis X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Roughly in order of importance: 1) Section 2.7: "An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead it MUST bring up the TLS session and then send a server_hello followed by a certificate_request." Not quite correct... The TLS server sends hello_request, then the handshake proceeds as normally (client sends client_hello, server sends server_hello, certificate, server_key_exchange, certificate_request, and server_hello_done, and so on). Example 2 in Appendix B also needs to be fixed. 2) Section 2.1 is very long and quite difficult to read. I have two suggestions for clarifying it a bit: First, split the text to four subsections: first covering the basic case, the second session resumption, the third privacy support (current section 2.7), and the fourth the error cases. Second, copy or move some/all of the message sequence diagrams from Appendix B to here. 3) The document would be much shorter if it omitted text that applies to all EAP methods. This text might have been necessary when RFC 2716 was published, but not is largely covered by RFC 3748. For example, Sections 2.2, the non-EAP-TLS specific parts of Section 3, Section 4.4, and Section 4.5 seem largely redundant to me... 4) Section 2.4, "SHOULD NOT use the identity presented in the Identity Response for access control or accounting purposes": is using unauthenticated information for access control or accounting purposes really something where we think "there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful"? (quoting from RFC2119) 5) Section 2.4, "SHOULD also examine the Server-id in order to determine whether the EAP server can be trusted": if this is really an appropriate SHOULD, it definitely needs more discussion. If you don't check the name (the most important piece of information!) in the certificate, why bother checking the certificate at all, or details such as revocation?=20 6) Section 2.4: "For example, an EAP peer connecting to the "EXAMPLE" SSID may wish to check whether the Server-Id matches the regular expression "*.example.com", in addition to checking whether the server certificate chains to the example.com CA." I find this suggestion quite dubious. So if I break into www.example.com and steal its private key, I should be able to masquerade as EAP server for EXAMPLE SSID? Even though this text is only an example, it's one with serious security considerations... 7) Section 4.2 "Where the subject field is not empty, the Peer-Id and Server-Id are obtained from the Common Name (CN) field of the DN" It's not guaranteed a DN always include the CN field, or that it includes only one CN field, or that the CN alone (without the rest of the DN) is a meaningful identifier. So probably the Peer-Id/Server-ID should be the whole DN...? 8) Section 4.2: "A valid EAP-TLS client certificate SHOULD contain an extendedKeyUsage value indicating support for Client Authentication (1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD contain an extendedKeyUsage value indicating support for Server Authentication (1.3.6.1.5.5.7.3.1)." According to RFC 3280, 1.3.6.1.5.5.7.3.2" means "TLS WWW client authentication". Although EAP-TLS does use TLS, we're not doing WWW client authentication here, so is the recommendation to include this EKU a good one? Is it consistent with what existing implementations do? Would it be better to recommend the EKUs from RFC 4334? 9) The document specifies a mandatory-to-implement cipher suite, but not a mandatory-to-implement TLS version (it just says "The version offered by the client [or server] MUST correspond to TLS v1.0 or later"). I guess most implementations today use TLS 1.0...? 10) The document doesn't have an IANA considerations section. It probably should ask IANA to update reference to EAP type 13 to this document, and say that there are no other IANA actions. 11) Section 3.3: the Start bit is never set in EAP Responses, right? 12) Section 4.1: The table about key sizes is not actually identical to the one in RFC 3766 (the numbers for DSA are slightly different). 13) Page 25 (Acknowledgments): "Thanks to Terence Spies, Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space." I didn't know Glen has moved to Microsoft? :-) 14) Typos:=20 - Section 5.1 "Lefkowetz" -> "Levkowetz". - Section 4.2 "altSubjectName" -> "subjectAltName" 15) From idnits: - Line 194 has weird spacing: '...ssionId will ...' - Line 197 has weird spacing: '...ered by the c...' - Unused Reference: 'FIPS' is defined on line 1023, but not referenced - Unused Reference: 'RFC1321' is defined on line 1064, but not referenced - Unused Reference: 'RFC1570' is defined on line 1067, but not referenced - Unused Reference: 'RFC1661' is defined on line 1070, but not referenced - Unused Reference: 'RFC1962' is defined on line 1073, but not referenced - Unused Reference: 'RFC1968' is defined on line 1076, but not referenced - Unused Reference: 'RFC1990' is defined on line 1079, but not referenced Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Dec 12 01:38:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu1HW-0004oy-F2; Tue, 12 Dec 2006 01:38:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu1HV-0004or-Ae for emu@ietf.org; Tue, 12 Dec 2006 01:38:25 -0500 Received: from bay0-omc1-s13.bay0.hotmail.com ([65.54.246.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu1HT-00020Y-KO for emu@ietf.org; Tue, 12 Dec 2006 01:38:25 -0500 Received: from hotmail.com ([207.46.8.110]) by bay0-omc1-s13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 11 Dec 2006 22:38:22 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Dec 2006 22:38:22 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 12 Dec 2006 06:38:21 GMT X-Originating-IP: [24.16.67.215] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Mon, 11 Dec 2006 22:38:21 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Dec 2006 06:38:22.0961 (UTC) FILETIME=[1EB36610:01C71DB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 Cc: aboba@internaut.com X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thank you for your detailed and thoughtful review comments. >Roughly in order of importance: > >1) Section 2.7: "An EAP-TLS server supporting privacy MUST NOT treat a >certificate list containing no entries as a terminal condition; >instead it MUST bring up the TLS session and then send a server_hello >followed by a certificate_request." > >Not quite correct... The TLS server sends hello_request, then the >handshake proceeds as normally (client sends client_hello, server >sends server_hello, certificate, server_key_exchange, >certificate_request, and server_hello_done, and so on). Example 2 in >Appendix B also needs to be fixed. Right. >2) Section 2.1 is very long and quite difficult to read. I have two >suggestions for clarifying it a bit: First, split the text to four >subsections: first covering the basic case, the second session >resumption, the third privacy support (current section 2.7), and the >fourth the error cases. Second, copy or move some/all of the message >sequence diagrams from Appendix B to here. The suggestion to split section 2.1 is a good one. >3) The document would be much shorter if it omitted text that applies >to all EAP methods. This text might have been necessary when RFC 2716 >was published, but not is largely covered by RFC 3748. For example, >Sections 2.2, the non-EAP-TLS specific parts of Section 3, Section >4.4, and Section 4.5 seem largely redundant to me... I agree that Sections 2.2, 4.4 and 4.5 could probably be deleted, since much of this material is now in RFC 3748. Section 3.1 could also probably be deleted, since it is just reprising the EAP packet format. >4) Section 2.4, "SHOULD NOT use the identity presented in the Identity >Response for access control or accounting purposes": is using >unauthenticated information for access control or accounting purposes >really something where we think "there may exist valid reasons in >particular circumstances when the particular behavior is acceptable or >even useful"? (quoting from RFC2119) Some EAP-TLS implementations do match the identity in the Response with the identity included in the certificate, though this is not a good idea. The SHOULD was left here so as to be compatible with RFC 3748 Section 5.1: It is RECOMMENDED that the Identity Response be used primarily for routing purposes and selecting which EAP method to use. EAP Methods SHOULD include a method-specific mechanism for obtaining the identity, so that they do not have to rely on the Identity Response. >5) Section 2.4, "SHOULD also examine the Server-id in order to >determine whether the EAP server can be trusted": if this is really an >appropriate SHOULD, it definitely needs more discussion. If you don't >check the name (the most important piece of information!) in the >certificate, why bother checking the certificate at all, or details >such as revocation? Some implementations may not have expectations relating to the server name and may just verify the server certificate chain. Verifying the certificate chain and checking revocation provide benefits independent of checking the server name against a pre-configured template. >6) Section 2.4: "For example, an EAP peer connecting to the "EXAMPLE" >SSID may wish to check whether the Server-Id matches the regular >expression "*.example.com", in addition to checking whether the server >certificate chains to the example.com CA." > >I find this suggestion quite dubious. So if I break into >www.example.com and steal its private key, I should be able to >masquerade as EAP server for EXAMPLE SSID? Even though this text is >only an example, it's one with serious security considerations... If you compromised the private key corresponding to the server certificate, then you could put up a rogue AP utilizing the EXAMPLE SSID, and could convince the EAP-TLS peer that your rogue AP was genuine. I believe that such an attack would work on quite a few EAP/802.11 implementations, assuming that your rogue AP advertised the same security properties as the original EXAMPLE SSID. >7) Section 4.2 "Where the subject field is not empty, the Peer-Id and >Server-Id are obtained from the Common Name (CN) field of the DN" > >It's not guaranteed a DN always include the CN field, or that it >includes only one CN field, or that the CN alone (without the rest of >the DN) is a meaningful identifier. So probably the Peer-Id/Server-ID >should be the whole DN...? Will have to think about this. >8) Section 4.2: "A valid EAP-TLS client certificate SHOULD contain an >extendedKeyUsage value indicating support for Client Authentication >(1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD >contain an extendedKeyUsage value indicating support for Server >Authentication (1.3.6.1.5.5.7.3.1)." > >According to RFC 3280, 1.3.6.1.5.5.7.3.2" means "TLS WWW client >authentication". Although EAP-TLS does use TLS, we're not doing WWW >client authentication here, so is the recommendation to include this >EKU a good one? Is it consistent with what existing implementations >do? Would it be better to recommend the EKUs from RFC 4334? Existing implementations do require these EKUs. The EKUs from RFC 4334 have never been implemented. I think that one of the ideas behind RFC 4334 was to provide additional information for certificate selection, but that would require modifications to the TLS code base which seems unlikely. So it might make sense to omit mention of RFC 4334, or even recommend against using those EKUs, since existing EAP-TLS servers will probably ignore them. >9) The document specifies a mandatory-to-implement cipher suite, but >not a mandatory-to-implement TLS version (it just says "The version >offered by the client [or server] MUST correspond to TLS v1.0 or >later"). I guess most implementations today use TLS 1.0...? Yes, Most existing implementations do use TLS 1.0. >10) The document doesn't have an IANA considerations section. It >probably should ask IANA to update reference to EAP type 13 to this >document, and say that there are no other IANA actions. OK. >11) Section 3.3: the Start bit is never set in EAP Responses, right? It isn't set in EAP Responses, correct. >12) Section 4.1: The table about key sizes is not actually identical to >the one in RFC 3766 (the numbers for DSA are slightly different). Thanks. Will fix. >13) Page 25 (Acknowledgments): "Thanks to Terence Spies, Glen Zorn and >Narendra Gidwani of Microsoft for useful discussions of this problem >space." I didn't know Glen has moved to Microsoft? :-) At the time RFC 2716 was published he did work for Microsoft, but that was quite a while ago. Time to update the acknowledgements section ;) >14) Typos: >- Section 5.1 "Lefkowetz" -> "Levkowetz". >- Section 4.2 "altSubjectName" -> "subjectAltName" Will fix. >15) From idnits: >- Line 194 has weird spacing: '...ssionId will ...' >- Line 197 has weird spacing: '...ered by the c...' >- Unused Reference: 'FIPS' is defined on line 1023, but not referenced >- Unused Reference: 'RFC1321' is defined on line 1064, but not >referenced >- Unused Reference: 'RFC1570' is defined on line 1067, but not >referenced >- Unused Reference: 'RFC1661' is defined on line 1070, but not >referenced >- Unused Reference: 'RFC1962' is defined on line 1073, but not >referenced >- Unused Reference: 'RFC1968' is defined on line 1076, but not >referenced >- Unused Reference: 'RFC1990' is defined on line 1079, but not >referenced Will fix. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Dec 12 05:51:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu5Ej-00006O-Rr; Tue, 12 Dec 2006 05:51:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gu5Ei-00005r-ML for emu@ietf.org; Tue, 12 Dec 2006 05:51:48 -0500 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gu5Eh-0000NS-7X for emu@ietf.org; Tue, 12 Dec 2006 05:51:48 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBCAlsX2014330; Tue, 12 Dec 2006 12:48:06 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:48:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Dec 2006 12:48:02 +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 Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Tue, 12 Dec 2006 12:48:02 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Thread-Index: AccduCFjejbfPhOFRNyJnpCoGoWfWAAH6CPg From: To: , X-OriginalArrivalTime: 12 Dec 2006 10:48:02.0233 (UTC) FILETIME=[FF0AEA90:01C71DDA] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: aboba@internaut.com X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Bernard Aboba wrote: > >4) Section 2.4, "SHOULD NOT use the identity presented in the > >Identity Response for access control or accounting purposes": is > >using unauthenticated information for access control or accounting > >purposes really something where we think "there may exist valid > >reasons in particular circumstances when the particular behavior is > >acceptable or even useful"? (quoting from RFC2119) >=20 > Some EAP-TLS implementations do match the identity in the Response > with the identity included in the certificate, though this is not a > good idea. The SHOULD was left here so as to be compatible with RFC > 3748 Section 5.1: >=20 > It is RECOMMENDED that the Identity Response be used=20 > primarily for routing purposes and selecting which EAP method=20 > to use. EAP Methods SHOULD include a method-specific mechanism=20 > for obtaining the identity, so that they do not have to rely on=20 > the Identity Response. It's not a big problem if some implementations require that the Identity Response matches the certificate, but it *is *a big problem if they don't match, and unauthenticated information from Identity Response is used for access control purposes. But I don't think this is what RFC3748's SHOULD is about... How about rephrasing the text to something like this? Since the identity presented in the Identity Response need not be related to the identity presented in the peer certificate, EAP-TLS implementations SHOULD NOT require that they be identical. However, if they are not identical, the identity presented in the Identity Response is unauthenticated information, and SHOULD NOT be used for access control or accounting purposes. > >5) Section 2.4, "SHOULD also examine the Server-id in order to > >determine whether the EAP server can be trusted": if this is really > >an appropriate SHOULD, it definitely needs more discussion. If you > >don't check the name (the most important piece of information!) in > >the certificate, why bother checking the certificate at all, or > >details such as revocation? >=20 > Some implementations may not have expectations relating to the > server name and may just verify the server certificate chain. > Verifying the certificate chain and checking revocation provide > benefits independent of checking the server name against a > pre-configured template. I'm aware that some implementations do this, but the document should explain the security implications better. If you compare the name in the certificate with the expected server name, an attacker fool you if he breaks into that server and steals its private key. If you don't check the name, the attacker can steal a private key corresponding to any certificate issued by your trusted CA (which in case of large CA could be millions of potential points of failure). Best regards, Pasi _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Dec 12 13:55:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCmj-0000dQ-2A; Tue, 12 Dec 2006 13:55:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuCmh-0000al-Hg for emu@ietf.org; Tue, 12 Dec 2006 13:55:23 -0500 Received: from bay0-omc2-s3.bay0.hotmail.com ([65.54.246.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuCmb-0004Eb-Cm for emu@ietf.org; Tue, 12 Dec 2006 13:55:23 -0500 Received: from hotmail.com ([207.46.8.120]) by bay0-omc2-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 12 Dec 2006 10:55:16 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Dec 2006 10:55:16 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 12 Dec 2006 18:55:12 GMT X-Originating-IP: [24.16.67.215] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Tue, 12 Dec 2006 10:55:12 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Dec 2006 18:55:16.0466 (UTC) FILETIME=[1000DD20:01C71E1F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: aboba@internaut.com X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Here are some of the changes to deal with the privacy comment. Let me know if this resolves the issue. In Section 2.6: An EAP-TLS server supporting privacy MUST NOT treat a certificate list containing no entries as a terminal condition; instead it MUST bring up the TLS session and then send a hello_request. The handshake then proceeds normally; the client sends a client_hello and the server replies with a server_hello, certificate, server_key_exchange, certificate_request, server_hello_done, etc. For an example, see Appendix B. The example: 2. In the case where the peer and server support privacy and mutual authentication, the conversation will appear as follows: Authenticating Peer Authenticator ------------------- ------------- <- EAP-Request/ Identity EAP-Response/ Identity (AnonymousNAI) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS Start) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, TLS certificate, [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate (no cert), TLS client_key_exchange, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, hello_request) EAP-Response/ EAP-Type=EAP-TLS (TLS client_hello)-> <- EAP-Request/ EAP-Type=EAP-TLS (TLS server_hello, [TLS certificate,] [TLS server_key_exchange,] TLS certificate_request, TLS server_hello_done) EAP-Response/ EAP-Type=EAP-TLS (TLS certificate, TLS client_key_exchange, TLS certificate_verify, TLS change_cipher_spec, TLS finished) -> <- EAP-Request/ EAP-Type=EAP-TLS (TLS change_cipher_spec, TLS finished) EAP-Response/ EAP-Type=EAP-TLS -> <- EAP-Success A version of the document with most of the changes made is available here: http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Tue Dec 12 18:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHSs-0003Av-OS; Tue, 12 Dec 2006 18:55:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuHSs-0003Aa-4o for emu@ietf.org; Tue, 12 Dec 2006 18:55:14 -0500 Received: from bay0-omc2-s12.bay0.hotmail.com ([65.54.246.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GuHSS-00076H-HI for emu@ietf.org; Tue, 12 Dec 2006 18:55:14 -0500 Received: from hotmail.com ([207.46.8.111]) by bay0-omc2-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 12 Dec 2006 15:54:47 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 12 Dec 2006 15:54:47 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Tue, 12 Dec 2006 23:54:44 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Tue, 12 Dec 2006 15:54:44 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 12 Dec 2006 23:54:47.0248 (UTC) FILETIME=[E76C9500:01C71E48] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org I think I have now incorporated most of these comments into a strawman -06 document: http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt Let me know if I've missed something. >From: >To: >Subject: [Emu] WGLC comments for draft-simon-emu-rfc2716bis >Date: Mon, 11 Dec 2006 17:08:28 +0200 > > >Roughly in order of importance: > >1) Section 2.7: "An EAP-TLS server supporting privacy MUST NOT treat a >certificate list containing no entries as a terminal condition; >instead it MUST bring up the TLS session and then send a server_hello >followed by a certificate_request." > >Not quite correct... The TLS server sends hello_request, then the >handshake proceeds as normally (client sends client_hello, server >sends server_hello, certificate, server_key_exchange, >certificate_request, and server_hello_done, and so on). Example 2 in >Appendix B also needs to be fixed. > > >2) Section 2.1 is very long and quite difficult to read. I have two >suggestions for clarifying it a bit: First, split the text to four >subsections: first covering the basic case, the second session >resumption, the third privacy support (current section 2.7), and the >fourth the error cases. Second, copy or move some/all of the message >sequence diagrams from Appendix B to here. > > >3) The document would be much shorter if it omitted text that applies >to all EAP methods. This text might have been necessary when RFC 2716 >was published, but not is largely covered by RFC 3748. For example, >Sections 2.2, the non-EAP-TLS specific parts of Section 3, Section >4.4, and Section 4.5 seem largely redundant to me... > > >4) Section 2.4, "SHOULD NOT use the identity presented in the Identity >Response for access control or accounting purposes": is using >unauthenticated information for access control or accounting purposes >really something where we think "there may exist valid reasons in >particular circumstances when the particular behavior is acceptable or >even useful"? (quoting from RFC2119) > > >5) Section 2.4, "SHOULD also examine the Server-id in order to >determine whether the EAP server can be trusted": if this is really an >appropriate SHOULD, it definitely needs more discussion. If you don't >check the name (the most important piece of information!) in the >certificate, why bother checking the certificate at all, or details >such as revocation? > > >6) Section 2.4: "For example, an EAP peer connecting to the "EXAMPLE" >SSID may wish to check whether the Server-Id matches the regular >expression "*.example.com", in addition to checking whether the server >certificate chains to the example.com CA." > >I find this suggestion quite dubious. So if I break into >www.example.com and steal its private key, I should be able to >masquerade as EAP server for EXAMPLE SSID? Even though this text is >only an example, it's one with serious security considerations... > > >7) Section 4.2 "Where the subject field is not empty, the Peer-Id and >Server-Id are obtained from the Common Name (CN) field of the DN" > >It's not guaranteed a DN always include the CN field, or that it >includes only one CN field, or that the CN alone (without the rest of >the DN) is a meaningful identifier. So probably the Peer-Id/Server-ID >should be the whole DN...? > > >8) Section 4.2: "A valid EAP-TLS client certificate SHOULD contain an >extendedKeyUsage value indicating support for Client Authentication >(1.3.6.1.5.5.7.3.2). A valid EAP-TLS server certificate SHOULD >contain an extendedKeyUsage value indicating support for Server >Authentication (1.3.6.1.5.5.7.3.1)." > >According to RFC 3280, 1.3.6.1.5.5.7.3.2" means "TLS WWW client >authentication". Although EAP-TLS does use TLS, we're not doing WWW >client authentication here, so is the recommendation to include this >EKU a good one? Is it consistent with what existing implementations >do? Would it be better to recommend the EKUs from RFC 4334? > > >9) The document specifies a mandatory-to-implement cipher suite, but >not a mandatory-to-implement TLS version (it just says "The version >offered by the client [or server] MUST correspond to TLS v1.0 or >later"). I guess most implementations today use TLS 1.0...? > >10) The document doesn't have an IANA considerations section. It >probably should ask IANA to update reference to EAP type 13 to this >document, and say that there are no other IANA actions. > >11) Section 3.3: the Start bit is never set in EAP Responses, right? > >12) Section 4.1: The table about key sizes is not actually identical to >the one in RFC 3766 (the numbers for DSA are slightly different). > >13) Page 25 (Acknowledgments): "Thanks to Terence Spies, Glen Zorn and >Narendra Gidwani of Microsoft for useful discussions of this problem >space." I didn't know Glen has moved to Microsoft? :-) > >14) Typos: >- Section 5.1 "Lefkowetz" -> "Levkowetz". >- Section 4.2 "altSubjectName" -> "subjectAltName" > >15) From idnits: >- Line 194 has weird spacing: '...ssionId will ...' >- Line 197 has weird spacing: '...ered by the c...' >- Unused Reference: 'FIPS' is defined on line 1023, but not referenced >- Unused Reference: 'RFC1321' is defined on line 1064, but not >referenced >- Unused Reference: 'RFC1570' is defined on line 1067, but not >referenced >- Unused Reference: 'RFC1661' is defined on line 1070, but not >referenced >- Unused Reference: 'RFC1962' is defined on line 1073, but not >referenced >- Unused Reference: 'RFC1968' is defined on line 1076, but not >referenced >- Unused Reference: 'RFC1990' is defined on line 1079, but not >referenced > > >Best regards, >Pasi > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Dec 13 02:53:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuOvE-0007cl-4T; Wed, 13 Dec 2006 02:53:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuOvC-0007cW-KJ for emu@ietf.org; Wed, 13 Dec 2006 02:52:58 -0500 Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuOv8-0001UU-4A for emu@ietf.org; Wed, 13 Dec 2006 02:52:58 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBD7pZhM031934; Wed, 13 Dec 2006 09:52:14 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 09:52:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 13 Dec 2006 09:52:11 +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 Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Wed, 13 Dec 2006 09:52:13 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Thread-Index: AcceSOsT/R0oATMDRBKVsKPpa2rXTQAQnDdg From: To: , X-OriginalArrivalTime: 13 Dec 2006 07:52:11.0909 (UTC) FILETIME=[98F8FB50:01C71E8B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thanks for handling my comments so quickly! (If every author had this fast turnaround times, IETF would get documents to RFCs in a fraction of current time... :-) About 1: the figure in 2.6 is not quite right yet. There should be=20 a finished message after the first change_cipher_spec sent by the server, and the certificate/server_key_exchange messages after the=20 second server_hello are not optional. About 2: I'd further suggest rephrasing the last two paragraphs of 2.1.1 along these lines (basic case first, session resumption second): =20 If the peer supports EAP-TLS and is configured to use it, it MUST respond to the EAP-Request with an EAP-Response packet of EAP- Type=3DEAP-TLS. If the preceding server_hello message sent by the EAP server in the preceeding EAP-Request packet did not indicate the resumption of a previous session, the data field of this packet MUST encapsulate one or more TLS records containing a TLS client_key_exchange, change_cipher_spec and finished messages. If the EAP server sent a certificate_request message in the preceding EAP-Request packet, then unless the peer is configured for privacy (see Section 2.6) the peer MUST send, in addition, certificate and certificate_verify messages. The former contains a certificate for the peer's signature public key, while the latter contains the peer's signed authentication response to the EAP server. After receiving this packet, the EAP server will verify the peer's certificate and digital signature, if requested. If the preceding server_hello message sent by the EAP server in the preceding EAP-Request packet indicated the resumption of a previous session, then the peer MUST send only the change_cipher_spec and finished handshake messages. The finished message contains the peer's authentication response to the EAP server. (And maybe Section 2.6 could be moved to 2.1.4?) About 7: This one is not there yet. About 9: The document still doesn't specify mandatory-to-implement TLS version (which is required in addition to mandatory-to-implement cipher suite to get interoperability). About 11: The S bit was removed from the bit diagram, but the text "The S bit (EAP-TLS start) is set in an EAP-TLS Start message" is still there. Best regards, Pasi=20 > -----Original Message----- > From: ext Bernard Aboba [mailto:bernard_aboba@hotmail.com]=20 > Sent: 13 December, 2006 01:55 > To: Eronen Pasi (Nokia-NRC/Helsinki); emu@ietf.org > Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis >=20 > I think I have now incorporated most of these comments into a=20 > strawman -06 document: > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt >=20 > Let me know if I've missed something. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Wed Dec 13 08:24:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuU5Y-0005TN-2t; Wed, 13 Dec 2006 08:24:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuU5X-0005TD-6T for emu@ietf.org; Wed, 13 Dec 2006 08:23:59 -0500 Received: from bay0-omc2-s4.bay0.hotmail.com ([65.54.246.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuU5U-0001cr-LD for emu@ietf.org; Wed, 13 Dec 2006 08:23:59 -0500 Received: from hotmail.com ([207.46.8.104]) by bay0-omc2-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 13 Dec 2006 05:23:56 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 13 Dec 2006 05:23:56 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Wed, 13 Dec 2006 13:23:51 GMT X-Originating-IP: [24.16.67.215] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: From: "Bernard Aboba" To: Pasi.Eronen@nokia.com, emu@ietf.org Bcc: Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis Date: Wed, 13 Dec 2006 05:23:51 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 13 Dec 2006 13:23:56.0014 (UTC) FILETIME=[F0BE60E0:01C71EB9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thanks for reviewing the changes. To fix the remaining issues, I've done another revision: http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt This includes: 1. Corrections to the example (hopefully correct this time). Also moved 2.6 to 2.1.4. 2. Rephrasing of the paragraphs as you suggested. 9. Added a statement on mandatory-to-implement TLS v1.0 to Section 2.4. 11. Removed mention of the 'S' bit from Section 3.2. 7. Changed Section 5.2 to the following: "5.2. Certificate Usage The EAP-TLS peer name (Peer-Id) represents the Network Access Identifier (NAI) [RFC4282] to be used for access control and accounting purposes. The Server-Id represents the identity of the EAP server. In EAP-TLS, the Peer-Id and Server-Id are determined from the subject or subjectAltName fields in the peer and server certificates. As noted in [RFC3280] Section 4.1.2.6: The subject field identifies the entity associated with the public key stored in the subject public key field. The subject name MAY be carried in the subject field and/or the subjectAltName extension... If subject naming information is present only in the subjectAltName extension (e.g., a key bound only to an email address or URI), then the subject name MUST be an empty sequence and the subjectAltName extension MUST be critical. Where it is non-empty, the subject field MUST contain an X.500 distinguished name (DN). Where the subjectAltName field is present, the Peer-Id or Server-Id is set to the contents of the subjectAltName. If subject naming information is present only in the subject field, then the Peer-Id or Server-Id is set to the Distinguished Name (DN). A valid EAP-TLS client certificate SHOULD contain an Extended Key Usage field indicating support for Client Authentication (1.3.6.1.5.5.7.3.2) or the special keyPurposeID anyExtendedKeyUsage. A valid EAP-TLS server certificate SHOULD contain an Extended Key Usage field indicating support for Server Authentication (1.3.6.1.5.5.7.3.1) or the special keyPurposeID anyExtendedKeyUsage. Certificate extensions for use with EAP-TLS are discussed in "Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol (PPP) and Wireless Local Area Networks (WLAN)" [RFC4334]. These extensions enable certificate usage to be restricted to use with lower layers such as PPP or IEEE 802.11. An EAP-TLS implementation MAY make these and other certificate fields available to the lower layer. The peer MUST verify the validity of the EAP server certificate, and SHOULD also examine the Server-id in order to determine whether the EAP server can be trusted. Even though a server certificate chains to a trust anchor, this does not necessarily imply that it is valid for connection to a particular network. Comparing the Server-Id in the certificate to the expected server name limits the damage that will result from an attacker compromising a server private key. If the peer does not check the Server-Id, then the peer would accept a compromised server certificate chaining to any of the configured trust anchors. The peer MAY also test whether the EAP server certificate is signed by a CA controlling the destination network and whether the Server-Id matches the format expected for that network. For example, an EAP peer connecting to the "EXAMPLE" SSID may check whether the Server-Id matches the regular expression "*.example.com", in addition to checking whether the server certificate chains to the example.com CA." ------------------------------------------------------------------------------------------------------- >From: >To: , >Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis >Date: Wed, 13 Dec 2006 09:52:13 +0200 > >Thanks for handling my comments so quickly! (If every author had this >fast turnaround times, IETF would get documents to RFCs in a fraction >of current time... :-) > >About 1: the figure in 2.6 is not quite right yet. There should be >a finished message after the first change_cipher_spec sent by the >server, and the certificate/server_key_exchange messages after the >second server_hello are not optional. > >About 2: I'd further suggest rephrasing the last two paragraphs of >2.1.1 along these lines (basic case first, session resumption second): > > If the peer supports EAP-TLS and is configured to use it, it MUST > respond to the EAP-Request with an EAP-Response packet of EAP- > Type=EAP-TLS. If the preceding server_hello message sent by the > EAP server in the preceeding EAP-Request packet did not indicate > the resumption of a previous session, the data field of this packet > MUST encapsulate one or more TLS records containing a TLS > client_key_exchange, change_cipher_spec and finished messages. If > the EAP server sent a certificate_request message in the preceding > EAP-Request packet, then unless the peer is configured for privacy > (see Section 2.6) the peer MUST send, in addition, certificate and > certificate_verify messages. The former contains a certificate for > the peer's signature public key, while the latter contains the > peer's signed authentication response to the EAP server. After > receiving this packet, the EAP server will verify the peer's > certificate and digital signature, if requested. > > If the preceding server_hello message sent by the EAP server in the > preceding EAP-Request packet indicated the resumption of a previous > session, then the peer MUST send only the change_cipher_spec and > finished handshake messages. The finished message contains the > peer's authentication response to the EAP server. > >(And maybe Section 2.6 could be moved to 2.1.4?) > >About 7: This one is not there yet. > >About 9: The document still doesn't specify mandatory-to-implement TLS >version (which is required in addition to mandatory-to-implement >cipher suite to get interoperability). > >About 11: The S bit was removed from the bit diagram, but the text >"The S bit (EAP-TLS start) is set in an EAP-TLS Start message" is >still there. > >Best regards, >Pasi > > > -----Original Message----- > > From: ext Bernard Aboba [mailto:bernard_aboba@hotmail.com] > > Sent: 13 December, 2006 01:55 > > To: Eronen Pasi (Nokia-NRC/Helsinki); emu@ietf.org > > Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis > > > > I think I have now incorporated most of these comments into a > > strawman -06 document: > > http://www.drizzle.com/~aboba/EMU/draft-simon-emu-rfc2716bis-06.txt > > > > Let me know if I've missed something. > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Thu Dec 14 22:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv47P-0006FM-KI; Thu, 14 Dec 2006 22:52:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gv47O-0006FA-4I for emu@ietf.org; Thu, 14 Dec 2006 22:52:18 -0500 Received: from mail2.genealogia.fi ([194.100.116.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gv47M-00008D-RD for emu@ietf.org; Thu, 14 Dec 2006 22:52:18 -0500 Received: from dsl017-049-110.sfo4.dsl.speakeasy.net ([69.17.49.110] helo=jm) by mail2.genealogia.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.50) id 1Gv47G-0000x6-Cm for emu@ietf.org; Fri, 15 Dec 2006 05:52:11 +0200 Received: by jm (sSMTP sendmail emulation); Thu, 14 Dec 2006 19:52:06 -0800 Date: Thu, 14 Dec 2006 19:52:06 -0800 From: Jouni Malinen To: emu@ietf.org Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 Message-ID: <20061215035206.GC6173@jm.kir.nu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) X-Spam-Score: -2.6 (--) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org On Thu, Nov 30, 2006 at 10:28:51AM -0800, Joseph Salowey (jsalowey) wrote: > This is a working group last call for draft-simon-emu-rfc2716bis-05. 2.3. Key Hierarchy Session-Id = 0x0C || client.random || server.random Isn't Session-Id usually the concatenation of the EAP type and some session specific information? Is that 0x0C just a typo? EAP-TLS uses EAP type 13 (0x0D) and I would have expected to see 0x0D || ... here. -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Dec 18 11:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwLFQ-0001Wa-5F; Mon, 18 Dec 2006 11:21:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GuAgY-0001zO-SS for emu@ietf.org; Tue, 12 Dec 2006 11:40:54 -0500 Received: from outbound.mailhop.org ([63.208.196.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GuAgX-0001a6-MH for emu@ietf.org; Tue, 12 Dec 2006 11:40:54 -0500 Received: from c-24-16-67-215.hsd1.wa.comcast.net ([24.16.67.215] helo=internaut.com) by outbound.mailhop.org with esmtpa (Exim 4.63) (envelope-from ) id 1GuAgX-0004pq-30; Tue, 12 Dec 2006 11:40:53 -0500 Received: by internaut.com (Postfix, from userid 1000) id 75EF73B641; Tue, 12 Dec 2006 08:40:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by internaut.com (Postfix) with ESMTP id 6C2583A75C; Tue, 12 Dec 2006 08:40:56 -0800 (PST) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.16.67.215 X-Report-Abuse-To: abuse@dyndns.com (see http://www.mailhop.org/outbound/abuse.html for abuse reporting information) X-MHO-User: aboba Date: Tue, 12 Dec 2006 08:40:56 -0800 (PST) From: Bernard Aboba To: Pasi.Eronen@nokia.com Subject: RE: [Emu] WGLC comments for draft-simon-emu-rfc2716bis In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 18 Dec 2006 11:21:49 -0500 Cc: bernard_aboba@hotmail.com, emu@ietf.org X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org > How about rephrasing the text to something like this? > > Since the identity presented in the Identity Response need not be > related to the identity presented in the peer certificate, EAP-TLS > implementations SHOULD NOT require that they be identical. > However, if they are not identical, the identity presented in the > Identity Response is unauthenticated information, and SHOULD NOT be > used for access control or accounting purposes. Looks good. > I'm aware that some implementations do this, but the document should > explain the security implications better. If you compare the name in > the certificate with the expected server name, an attacker fool you if > he breaks into that server and steals its private key. If you don't > check the name, the attacker can steal a private key corresponding to > any certificate issued by your trusted CA (which in case of large CA > could be millions of potential points of failure). OK. _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu From emu-bounces@ietf.org Mon Dec 18 18:54:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSIy-0007kQ-Nj; Mon, 18 Dec 2006 18:54:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GwSIx-0007kL-Df for emu@ietf.org; Mon, 18 Dec 2006 18:53:59 -0500 Received: from bay0-omc3-s3.bay0.hotmail.com ([65.54.246.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GwSIw-00005Q-3X for emu@ietf.org; Mon, 18 Dec 2006 18:53:59 -0500 Received: from hotmail.com ([207.46.8.106]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Mon, 18 Dec 2006 15:53:57 -0800 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 18 Dec 2006 15:53:57 -0800 Message-ID: Received: from 207.46.8.123 by by117fd.bay117.hotmail.msn.com with HTTP; Mon, 18 Dec 2006 23:53:56 GMT X-Originating-IP: [131.107.0.71] X-Originating-Email: [bernard_aboba@hotmail.com] X-Sender: bernard_aboba@hotmail.com In-Reply-To: <20061215035206.GC6173@jm.kir.nu> From: "Bernard Aboba" To: jkmaline@cc.hut.fi, emu@ietf.org Bcc: Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 Date: Mon, 18 Dec 2006 15:53:56 -0800 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 18 Dec 2006 23:53:57.0328 (UTC) FILETIME=[C825E500:01C722FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: emu@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "EAP Methods Update \(EMU\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emu-bounces@ietf.org Thanks for catching this. Yes, it is a typo. >From: Jouni Malinen >To: emu@ietf.org >Subject: Re: [Emu] WG Last Call: draft-simon-emu-rfc2716bis-05 >Date: Thu, 14 Dec 2006 19:52:06 -0800 > >On Thu, Nov 30, 2006 at 10:28:51AM -0800, Joseph Salowey (jsalowey) wrote: > > This is a working group last call for draft-simon-emu-rfc2716bis-05. > >2.3. Key Hierarchy > > Session-Id = 0x0C || client.random || server.random > > >Isn't Session-Id usually the concatenation of the EAP type and some >session specific information? Is that 0x0C just a typo? EAP-TLS uses EAP >type 13 (0x0D) and I would have expected to see 0x0D || ... here. > >-- >Jouni Malinen PGP id EFC895FA > >_______________________________________________ >Emu mailing list >Emu@ietf.org >https://www1.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu