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
