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
