Subject: [Emu] Client Auth with TLS

From: "Jim Schaad" <[email-masked]>
Date: Wed, 3 Oct 2012 13:11:59 -0700

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

---

From: Stefan Winter <[email-masked]>
Date: Thu, 04 Oct 2012 08:09:48 +0200

Hi,

> 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
> [email-masked]
> 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

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 7 Oct 2012 20:43:57 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stefan Winter
> Sent: Wednesday, October 03, 2012 11:10 PM
> To: [email-masked]
> 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.
> 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:
> 
the
> "first" negotiation ends with a 'finished' and then immediately a new
> 'hello_request' - all in one EAP message.
> 
> Greetings,
> 
> Stefan
> 
> >
> > Jim
> >
> >
> 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

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 9 Oct 2012 04:22:33 +0000

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?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 09 Oct 2012 09:13:47 -0400

> Any opinions on the list?  

  The inner EAP-TLS has proven to work before.  It seems fine.

  Alan DeKok.

---

From: Stefan Winter <[email-masked]>
Date: Tue, 09 Oct 2012 16:23:29 +0200

Hi,

> 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

Tel: +352 424409 1
Fax: +352 422473

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Tue, 9 Oct 2012 15:14:39 +0000

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" <[email-masked]> 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.
>> 
>>>>ever

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 9 Oct 2012 09:35:06 -0700

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Monday, October 08, 2012 9:23 PM
> To: Jim Schaad
> Cc: Stefan Winter; <[email-masked]>
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.
> 

Are you suggesting an inner EAP-TLS or an inner TEAP?

Jim

> > 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
> >
> >
> >>> 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
> >> used (anyone?), but it's clearly a foreseen mode of operation. The
> >> text describing this is in section 2.1.4:
> >>
> >> 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
> >
> >

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 9 Oct 2012 16:43:35 +0000

> Are you suggesting an inner EAP-TLS or an inner TEAP?

[Joe]  EAP-TLS as an inner method.

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 10 Oct 2012 12:48:02 -0700

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

> Sent: Tuesday, October 09, 2012 9:44 AM
> To: Jim Schaad
> >> EAP-TLS may be more flexible and would offer the same security
> >> properties and might be a simpler model.
> >>
> >>> 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
> >>>
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> Behalf
> >> Of
> >>>> Stefan Winter
> >>>>> 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
> >>>> FWIW, RFC5216 (EAP-TLS) already has provisions for a protected
> >>>> client credential exchange (for client privacy protection reasons).
> >>>> I didn't ever
> >>> see it
> >>>> confidentiality and MUST provide a client certificate list
> >>>> containing  no entries in response to the initial
> >>>> certificate_request from the  EAP-TLS server.
> >>>>
> >>>> list containing no entries as a terminal condition; instead, it
> >>>> MUST  bring up the TLS session and then send a hello_request.  The
> >>>> supporting privacy does not receive a client certificate in
> >>>> response  to the subsequent certificate_request, then it MUST abort
> >>>> the  session.
> >>>> "
> >>>>
> >>>> "first" negotiation ends with a 'finished' and then immediately a
> >>>> 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
> >>>
> >>>

---

From: Stefan Winter <[email-masked]>
Date: Thu, 11 Oct 2012 11:20:59 +0200

Hi,

> 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

>>>> we
>>>>> containing
>>>>> et de

Tel: +352 424409 1
Fax: +352 422473