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