> -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] > Sent: Monday, October 08, 2012 9:23 PM > To: Jim Schaad > Cc: Stefan Winter; <emu@ietf.org> > Subject: Re: [Emu] Client Auth with TLS > > 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?
Are you suggesting an inner EAP-TLS or an inner TEAP? Jim > > > > 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
