Hi Bernard, I'm not sure I understand some of the text below:
<snip> > 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. > [Joe] If the server key is compromised then it seems checking the server-ID will not help discover this or limit damage. > 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: <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]>, <[email protected]> > >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:[EMAIL PROTECTED] > > > Sent: 13 December, 2006 01:55 > > > To: Eronen Pasi (Nokia-NRC/Helsinki); [email protected] > > > 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 > >[email protected] > >https://www1.ietf.org/mailman/listinfo/emu > > > > _______________________________________________ > Emu mailing list > [email protected] > https://www1.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
