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
