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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
