Re: [Emu] Client Auth with TLS
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" 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 >>>>>>
Re: [Emu] Client Auth with TLS
I think this approach may be better than trying to do the re-negotiations inside of the TEAP and probably merits about 2 sentences in the document. Jim > -Original Message- > From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] > Sent: Tuesday, October 09, 2012 9:44 AM > To: Jim Schaad > Cc: Stefan Winter; > Subject: Re: [Emu] Client Auth with TLS > > > 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; > >> 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 wi
Re: [Emu] Client Auth with TLS
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; >> 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
Re: [Emu] Client Auth with TLS
> -Original Message- > From: Joseph Salowey (jsalowey) [mailto:jsalo...@cisco.com] > Sent: Monday, October 08, 2012 9:23 PM > To: Jim Schaad > Cc: Stefan Winter; > 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? 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
Re: [Emu] Client Auth with TLS
Stefan: 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: "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" 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 >>
Re: [Emu] Client Auth with TLS
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 >&
Re: [Emu] Client Auth with TLS
Joseph Salowey (jsalowey) wrote: > 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? The inner EAP-TLS has proven to work before. It seems fine. Alan DeKok. ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
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? 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
Re: [Emu] Client Auth with TLS
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
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 signature.asc Description: OpenPGP digital signature ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
[Emu] Client Auth with TLS
This issue is one that I was dealing with while driving grapes back from the vineyard yesterday. I don't know that it needs to have any changes in the draft. I am putting this out to see if there is any controversy on the decisions that I would make about this issue. The client is going to use client authorization with the TLS tunnel. I make the assumption that the client does successfully authenticate the server's certificate and we are not in a total anonymous situation. At this point I believe the following possible scenarios exist: 1. The client provides no certificate - This would be accepted depending on the server policy about requiring a client certificate to be presented. 2. The client provides a certificate in the clear - This could be either a user or machine certificate, the server would check the identity against Its database (with the proviso that the certificate could be the entry in the database) and either accepts or rejects the TLS connection based on the identity presented. This would be done via a TLS alert. Note, I did have an argument with myself about the possibility that the server would accept the certificate and treat it as if it was an anonymous client. 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. Jim ___ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
