Hi, > Actually even if the client is authenticated as part of the TLS tunnel > establishment, NEA data can still be passed inside TEAP tunnel. It is > designed to carry additional data in Phase 2. > > The Current TEAP draft supports both of these modes, as in Section 3.2:
Thanks for the explanation. Well, if it supports both then that opens space for misunderstandings. When configuring protected client auth, one implementation might on the wire choose to do protected client-side auth within the TLS handshake, but another might expect an inner EAP-TLS instead. I fail to see why supporting *both* modes of operation is required. From my (non-implementer's) point of view, I see two code paths to achieve the same goal here. In terms of implementation complexity, it would appear to me that using inner EAP-TLS makes the client cert exchange "yet another inner EAP method" (ideally able to share code with other inner EAP method's session establishment), while a TLS-handshake operation creates a "special case" to be handled differently. Greetings, Stefan Winter > > "TEAP implementations MUST support client authentication during tunnel > establishment using the TLS ciphersuites specified in Section 3.2 > <http://tools.ietf.org/html/draft-ietf-emu-eap-tunnel-method-03#section-3.2 >> . > The EAP peer does not need to authenticate as part of the TLS > exchange, but can alternatively be authenticated through additional > exchanges carried out in Phase 2. > > The TEAP tunnel protects peer identity information exchanged during > phase 2 from disclosure outside the tunnel. Implementations that > wish to provide identity privacy for the peer identity must carefully > consider what information is disclosed outside the tunnel prior to > phase 2. TEAP implementations SHOULD support the immediate > renegotiation of a TLS session to initiate a new handshake message > exchange under the protection of the current cipher suite. This > allows support for protection of the peer's identity when using TLS > client authentication." > > > It properly doesn't describes the TLS exchanges as detailed as in EAP-TLS > RFC, but something we could improve if desired. > > > On 10/9/12 10:23 AM, "Stefan Winter" <stefan.win...@restena.lu> wrote: > >> Hi, >> >>> 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? >> >> We have a couple of EAP-TLS realms which are also interested in NEA. I >> usually tell them that NEA data can't be put into the EAP channel with >> EAP-TLS, and that that is bad luck for them :-) >> >> If TEAP uses tunneled EAP-TLS as opposed to renegotiating, the inner EAP >> would/might allow for carrying extra attributes besides the cert >> exchange - thus enabling NEA-like exchanges. >> >> If my thinking isn't borked, that would mean I'd rather support inner >> EAP-TLS to enable these usages. >> >> Greetings, >> >> Stefan >> >>> >>> >>> >>> 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 >>> >> >> >> -- >> 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 >> > -- 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
