I think this approach may be better than trying to do the re-negotiations inside of the TEAP and probably merits about 2 sentences in the document.
Jim > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] > Sent: Tuesday, October 09, 2012 9:44 AM > To: Jim Schaad > Cc: Stefan Winter; <emu@ietf.org> > Subject: Re: [Emu] Client Auth with TLS > > > On Oct 9, 2012, at 9:35 AM, Jim Schaad wrote: > > > > > > >> -----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? > > > > [Joe] EAP-TLS as an inner method. > > > 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
