I think it is worthwhile to support an mode of operation that supports peer privacy. I've seen this implemented in tunnel methods in two different ways. One with renegotiation as described below and the other as an inner EAP-TLS exchange after an anonymous outer exchange. I don't really have a strong opinion as to which is better at this point. It seems that using an inner EAP-TLS may be more flexible and would offer the same security properties and might be a simpler model.
Any opinions on the list? On Oct 7, 2012, at 8:43 PM, Jim Schaad wrote: > Stefan, > > Thanks for the input. > > For the authors, > > Does this need to be documented as a mode of operation for TEAP or are we > going to say that this is not a supported mode? > > Jim > > >> -----Original Message----- >> From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of >> Stefan Winter >> Sent: Wednesday, October 03, 2012 11:10 PM >> To: emu@ietf.org >> Subject: Re: [Emu] Client Auth with TLS >> >> Hi, >> >>> 3. The client provides the certificate in a protected manner - I had >>> a problem at this point because I don't know enough TLS to properly go >>> through this scenario, and I could not really read documents while >>> driving. If the encrypted certificate extension was used, then there >>> is no issue as the protected certificate would be passed in the >>> initial handshake. However if the client starts the negotiation and >>> then restarts it after it is encrypted, I don't know if this occurs > before or >> after the finish message. >>> If it starts after the finish method then there is an issue with >>> having the server close an anonymous session if the client is then >>> going to provide the certificate encrypted. Help on how this works > would >> be appreciated. >> >> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected client >> credential exchange (for client privacy protection reasons). I didn't ever > see it >> used (anyone?), but it's clearly a foreseen mode of operation. The text >> describing this is in section 2.1.4: >> >> "... In order to avoid disclosing the peer username, an EAP-TLS peer >> configured for privacy MUST negotiate a TLS ciphersuite supporting >> confidentiality and MUST provide a client certificate list containing >> no entries in response to the initial certificate_request from the >> EAP-TLS server. >> >> 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 peer sends a client_hello and >> the server replies with a server_hello, certificate, >> server_key_exchange, certificate_request, server_hello_done, etc. >> >> For the calculation of exported keying material (see Section 2.3), >> the master_secret derived within the second handshake is used. >> >> An EAP-TLS peer supporting privacy MUST provide a certificate list >> containing at least one entry in response to the subsequent >> certificate_request sent by the server. If the EAP-TLS server >> supporting privacy does not receive a client certificate in response >> to the subsequent certificate_request, then it MUST abort the >> session. >> " >> >> There is a sequence diagram shortly afterwards which shows clearly that > the >> "first" negotiation ends with a 'finished' and then immediately a new >> 'hello_request' - all in one EAP message. >> >> Greetings, >> >> Stefan >> >>> >>> Jim >>> >>> >>> _______________________________________________ >>> Emu mailing list >>> Emu@ietf.org >>> https://www.ietf.org/mailman/listinfo/emu >>> >> >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de >> la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
