Subject: [Emu] Key Derivation for EAP-TLS 1.3

From: Joseph Salowey <[email-masked]>
Date: Sun, 7 Feb 2021 18:27:17 -0800

I'd like to get feedback from the working group on the EAP-TLS 1.3 key
derivation.  Does this improve the security of the system?  Are there any
implementation barriers?

The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3.
A few reviews have pointed out that the exporter master secret for TLS
exporters includes server identity information, but does not include
information about the peer/client identity.

Both Martin and Ben proposed adding the peer identity into the context
parameter for the TLS exporter key derivation. This binds the peer identity
into the key derivation for EAP-TLS keys that are used in lower layer
protocols.   This explicit binding strengthens the resulting authentication
implied by the key and should make formal analysis of the system easier.

For example, if the EAP-TLS server is requesting a certificate from the
peer then the key derivation would look something like:

Key =  TLS-Exporter(label, peerID/peer certificate, 64)

Where the label is the label defined for the key and the peer ID is
identity information for the peer.  Since the peer ID in EAP-TLS has some
potential ordering issues, it may be better to use the end entity
certificate of the peer as the peerID.

In the case where the peer is not asked for a certificate then the
derivation would not include the peerID. The TLS resumption key derivation
is derived using both the peer and server identity from the original
exchange so adding the peerID into the EAP-TLS key derivation in the
resumption is not necessary.

Cheers,

Joe

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 08 Feb 2021 14:46:33 +1100

On Mon, Feb 8, 2021, at 13:27, Joseph Salowey wrote:
> parameter for the TLS exporter key derivation. 

So I wasn't suggesting the client certificate, as that is covered by the client key confirmation and (I think) the results we have from the exported authenticator work indicates that this isn't necessary for the security of the protocol; validating the Finished is what provides the assurances there.

What I was concerned about was the information that is exchanged in EAP *before* the TLS handshake begins that might affect the choice of certificate to offer.  As this is not authenticated at all, there are trivial attacks if a client uses that information to guide its choice of certificate.  For that problem, including the certificate as context in the key exporter doesn't help, but including any information that might appear outside could, if you get all of it.

---

From: John Mattsson <[email-masked]>
Date: Mon, 8 Feb 2021 07:12:01 +0000

Hi,

Martin Thompson wrote:

>What I was concerned about was the information that is exchanged in EAP *before* the TLS handshake
>begins that might affect the choice of certificate to offer.  As this is not authenticated at all,
>there are trivial attacks if a client uses that information to guide its choice of certificate.  For
>that problem, including the certificate as context in the key exporter doesn't help, but including
>any information that might appear outside could, if you get all of it.

That seems more interesting to discuss. I think the only only interesting information exchanged before the TLS handshake is the identity in the identity response. It will typically be an anonymous NAI 

@realm

but it may be an encrypted username

xCZINCPTK5+7y81CrSYbPg+RKPE3OTrYLn4AQc4AC2U=@realm

and formally it does not even need to be a NAI. EAP-TLS 1.3 mandates a "privacy-friendly" identity. An encrypted username may not protect against spoofing.

I don't think RFC 5216 states anything about how the client choses it's certificate. In some
implementation I have seen the user picks a certificate. The realm does of course very much determine the server certificate as the response would be send to different servers.

On one hand, the realm could be considered routing information just like the IP address. Changing the sever IP address in any use of TLS might change the server certificate.

On the other hand the guidance in RFC 5216 on how to verify the server identity is very vague.

   Once a TLS session is established, EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS.  The
   authorization process makes use of the contents of the certificates
   as well as other contextual information.  While authorization
   requirements will vary from deployment to deployment, it is
   RECOMMENDED that implementations be able to authorize based on the
   EAP-TLS Peer-Id and Server-Id determined as described in Section 5.2.

There are no hard rules like the one in RFC 2818 about comparing hostname with subjectAltName.

Not sure that putting the identity response in the exporter context improves anything. Might be more useful with guidance/requirements on how to chose certificates and which identities to allow.

Cheers,
John

-----Original Message-----
From: Emu <[email-masked]> on behalf of Martin Thomson <[email-masked]>
Date: Monday, 8 February 2021 at 04:47
To: Joseph Salowey <[email-masked]>, EMU WG <[email-masked]>, 'Benjamin Kaduk' <[email-masked]>
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Mon, 8 Feb 2021 07:32:11 -0500

On Feb 7, 2021, at 10:46 PM, Martin Thomson <[email-masked]> wrote:
> What I was concerned about was the information that is exchanged in EAP *before* the TLS handshake begins that might affect the choice of certificate to offer.  As this is not authenticated at all, there are trivial attacks if a client uses that information to guide its choice of certificate.

  There isn't anything sent in EAP-TLS from the server to the client, which lets the client choose a certificate.  The clients choice of certificate is driven by layers *outside* of EAP-TLS.

  e.g. a client certificate may be tied to a WiFi SSID.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 8 Feb 2021 07:42:09 -0500

On Feb 7, 2021, at 9:27 PM, Joseph Salowey <[email-masked]> wrote:
> 
> I'd like to get feedback from the working group on the EAP-TLS 1.3 key derivation.  Does this improve the security of the system?  Are there any implementation barriers?
> 
> The key derivation for TLS 1.3 uses the key exporters defined for TLS 1.3.  A few reviews have pointed out that the exporter master secret for TLS exporters includes server identity information, but does not include information about the peer/client identity.  
> 
> Both Martin and Ben proposed adding the peer identity into the context parameter for the TLS exporter key derivation. This binds the peer identity into the key derivation for EAP-TLS keys that are used in lower layer protocols.   This explicit binding strengthens the resulting authentication implied by the key and should make formal analysis of the system easier.  
> 
> For example, if the EAP-TLS server is requesting a certificate from the peer then the key derivation would look something like:
> 

  What format is used for then peer certificate?

  The EAP-TLS application doesn't necessarily have access to the "on the wire" format of the certificate.  It may only have access to a decoded / high-layer representation of the certificate.  For that reason, I would prefer to avoid using the certificate in any key derivation.

  The peer ID may be more, if we just a field in a certificate (e.g. subjetAltName).  It is simple, and can be exported as an opaque blob.

> Where the label is the label defined for the key and the peer ID is identity information for the peer.  Since the peer ID in EAP-TLS has some potential ordering issues, it may be better to use the end entity certificate of the peer as the peerID.  
> 
> In the case where the peer is not asked for a certificate then the derivation would not include the peerID.  The TLS resumption key derivation is derived using both the peer and server identity from the original exchange so adding the peerID into the EAP-TLS key derivation in the resumption is not necessary.  

  I would prefer to define a consistent key derivation.  The more if / then / else cases are defined, the more opportunity for error.

  TBH, just leaving it as draft-13 or -14 is fine.  The main important change for me is to mandate the use of TLS alert as a secure altReject indicator, and a delayed close_notify / commitment message (after the client cert) was a secured altAccept indicator.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Thu, 18 Feb 2021 09:03:42 +0000

Hi,

I don't think any additional information in the key derivation is needed.

I do think that the requirements for server identity verification in RFC 5216 is a bit vague. 

HTTPS (RFC 2818) for example has much more stricter requirement regarding this:

  "If the hostname is available, the client MUST check it against the
  server's identity as presented in the server's Certificate message,
  in order to prevent man-in-the-middle attacks."

I started an issue regarding this.

https://github.com/emu-wg/draft-ietf-emu-eap-tls13/issues/47

My suggestion would be to add something like the following to EAP-TLS 1.3:

  "The EAP-TLS peer MUST check that the identity in the EAP-TLS server's
  Certificate is appropriate and authorized for the link. If a NAI was
  used in the identity response, the EAP-TLS peer MUST check the realm
  in the identity response against the identity in the EAP-TLS server's
  certificate."

I am sure most EAP implementations are secure, but I have recently seen prototype usage (not EAP) of TLS where the identity in the certificate was never checked, resulting in nothing more than group authentication where any cert signed by any of the trust anchors was accepted. I think implementors need guidance on that verifying the identity is essential for getting authentication. Otherwise implementors might easily miss this, thinking that TLS and certificate chain validation alone gives authentication.

Cheers,
John

-----Original Message-----
From: Emu <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Date: Monday, 8 February 2021 at 13:42
To: Joseph Salowey <[email-masked]>
Cc: EMU WG <[email-masked]>, Martin Thomson <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 18 Feb 2021 10:38:45 -0500

>  in order to prevent man-in-the-middle attacks."

  The issue is that HTTPS has (generally) a hostname available: "go to www.example.org".

  Hmm.. does the presented cert contain "www.example.org" ?  That's easy to check.  There's a field for that.

  We don't have this with EAP.  EAP may contain an identity, "@example.com", and the server will present a certificate with DNS name "radius.example.com".

  Is this OK?  We're not sure.  It is widely used, but the field which says "my DNS name is radius.example.com" does not necessarily help with comparisons to an NAI of "@example.com".

>  in the identity response against the identity in the EAP-TLS server's

  The issue is "how".  :(  There have been prior discussions about this in EMU.  See "EAP/EMU recommendations for client cert validation logic" in early 2020.  That was a _long_ discussion.

  The conclusion largely was that there's no real way to do this safely with existing certificate fields.

> I am sure most EAP implementations are secure, but I have recently seen prototype usage (not EAP) of TLS where the identity in the certificate was never checked, resulting in nothing more than group authentication where any cert signed by any of the trust anchors was accepted.

  Implementations largely fixed that years ago via a few methods:

* on initial connection to SSID, prompting the user to see if the certificate is OK (historical, and less permitted these days)

* pre-provisioning SSID / CA certificate / user credentials to each machine

* certificate pinning so that the EAP server certificate is cached and associated with an SSID / user credentials.  i.e. not just the CA cert.  This caching prevents bad actors from getting their own certificate from the same CA, and setting up their own "mirror" malicious SSID.

  The result is that this works for most situations, and is reasonably secure.

> I think implementors need guidance on that verifying the identity is essential for getting authentication. Otherwise implementors might easily miss this, thinking that TLS and certificate chain validation alone gives authentication.

  Unfortunately there doesn't seem to be a clear way to do this.  Even if we added a new certificate field, many public CAs will only sign certs which contain a very limited subset of OIDs.  So you can't just add an OID and get it used.

  The current implementations seem to be OK, inter-operable, and secure.  But it would be good to document this behavior, and explain why it's necessary.  I'll see if I can suggest some text.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 18 Feb 2021 16:39:33 -0500

>  The result is that this works for most situations, and is reasonably secure.

  Some suggested text, perhaps for Section 5.3, Certificate Validation:

  There are some proposed additions to the certificate validation text in Section 5.3 of RFC 5216:

  Experience shows that configuring EAP peers can be difficult and error-prone, especially when that configuration is performed manually by end users.  In order to avoid errors and insecure configurations, EAP-TLS peers SHOULD be provisioned via an automated process.  This process should configure all settings necessary to perform EAP-TLS in a secure manner, in its expected use-case(s).  These settings can include not only the certificate chain from certificate authority to client certificate, but also the expected EAP server certificate.  These settings can also include information about the protocol layers above or below EAP (MAC addresses, IP addresses, port numbers, WiFi SSID, etc.).

  Where these settings cannot be provisioned in an automated manner, the EAP peer SHOULD cache them after first use.  The peer SHOULD then present the EAP-TLS credentials only when all of the cached settings match the network being accessed.  Where these settings do not match, the EAP peer MAY refuse to proceed with authentication.  Where the EAP peer does proceed, it SHOULD inform the end user (where possible) as to the nature of the changes, and give the user the option of proceeding or refusing the authentication.

  The above recommendations have been in wide-spread use in EAP-TLS peer implementations for many years.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Fri, 19 Feb 2021 07:12:33 +0000

Thanks Alan,

But these are more implementation guidance/history then security requirements.

"should configure all settings necessary to perform EAP-TLS in a secure manner" is extremely soft. If we put that in the document it has to be MUST.

RFC 5216 has the normative text:
   "Once a TLS session is established, EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS."

Can we update that to:
   "Once a TLS session is established, EAP-TLS peer and server
   implementations MUST validate that the identities represented in the
   certificate are appropriate and authorized for use with EAP-TLS on the specific link."

RFC 3748 use the term link, but I think path or network might also be ok.

Unless we can say that, it is very hard to justify the security claim of mutual authentication. Then we would likely have to explain that EAP-TLS only gives some very weak form of authentication.

Might also be that the text in quoted text in RFC 5216 is not how things are implemented. An alternative approach would be to check that the certificates are issues by a CA that is exclusively used for EAP-TLS in a specific network and ignore the identities.

/John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Thursday, 18 February 2021 at 22:39
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>, Martin Thomson <[email-masked]>, Benjamin Kaduk <[email-masked]>
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 19 Feb 2021 06:30:53 -0500

> But these are more implementation guidance/history then security requirements.

  Do these issues affect security?  If the answer is "no", then they can be ignored.  If the answer is "yes", then they should be put in.

  You've approached this specification as a theoretical exercise in protocol design.  I've tried to explain that protocols are implemented in the real world, by real people.  As such, it is important for the document to give implementation guidance.  Further, it's very useful for implementors to understand *why* things are done a particular way.  Explaining the reasons for a particular choice helps implementors understand the higher level picture, which makes implementation easier.

  There are any number of RFCs which take this approach.  Experience shows that specifications which do *not* have implementation guidance. too often result in insecure implementations.

  There have been a number issues brought up by people who have *coded* these protocols, and *used* them in the real world.   You're opposing the requests to update the document with guidance that the implementors say they need.  The reasons you give are largely from inexperience: "I don't understand why this matters".

  Well, it does.  If you don't understand why, then please step aside, and let the work be done by others.   If you won't step aside, then please stop resisting guidance from people who have experience in this area.

  To be perfectly frank: if this specification does not meet the needs of implementors, then they will ignore it, and go do whatever they want.  This particular specification will be ignored.  And once implementors are ready, they will bring a specification to the IETF which says "ignore the previous spec, this is what we actually did".

> Might also be that the text in quoted text in RFC 5216 is not how things are implemented.

  There is code publicly available.  I suggest looking at it.

> An alternative approach would be to check that the certificates are issues by a CA that is exclusively used for EAP-TLS in a specific network and ignore the identities.

  This topic has been discussed before in EMU, including explanations of what people have been doing for a decade in production networks

  Implementors have a long established a set of practices which are NOT written down in any standard.  These practices help to both secure the network, and make these systems easier to deploy.

  i.e.: Instead of fighting with standards bodies, implementors have gone and done their own thing, because the specifications are lacking.  Worse, the processes used by standards bodies are lacking.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Fri, 19 Feb 2021 15:49:27 +0000

Dear Alan,

It would very nice if you stopped putting words in my mouth and stopped accusing me personally for IETF procedures, which I feel you do.

Alan DeKok <[email-masked]> wrote:
>> But these are more implementation guidance/history then security >requirements.
>
>  Do these issues affect security?  If the answer is "no", then they can >be ignored.  If the answer is "yes", then they should be put in.

[John] I have not stated that I don't think your text should be put in the document. I do. And your suggested text certainly affect security. I simply meant that this was not the kind of requirements I personally was discussing and expecting. In fact, your text make me questioning if implementations are even following the RFC 5216 MUST or if we need to update some text.

[John] If EMU cannot agree on a a few high level sentences summarizing MUST requirements for secure server authentication, I have a hard time believing that current or future implementations are/will be secure.

[John] My role as one of the authors is not to decide what goes into the document or to produce all the text. After adoption, my role is to add text that there is WG consensus on. Sometimes that includes trying to come up with text based on the consensus.

>  You've approached this specification as a theoretical exercise in >protocol design.  I've tried to explain that protocols are implemented in >the real world, by real people.  As such, it is important for the document >to give implementation guidance.  Further, it's very useful for >implementors to understand *why* things are done a particular way.  >Explaining the reasons for a particular choice helps implementors >understand the higher level picture, which makes implementation easier.

[John] Except the first sentence, I agree with you. If you suggest guidance text and that text has WG consensus, me and Mohit will add it to the document (Given that the shepard and AD are ok with it). Most of your suggested resumption guidance text is e.g. in the document. Some of the *why* text you have requested has been about TLS 1.3, I think you need to ask people that took part in these specific discussions in the TLS WG for this. Futhermore, there was people recently suggesting that all TLS guidance was to be removed. Then it is hard to arguee that there is IETF consensus to add more.

[John] Note also that at this late state of the document process it is harder to harder to justify new technical changes that are not related ot the IESG review. 

>  There are any number of RFCs which take this approach.  Experience shows >that specifications which do *not* have implementation guidance. too often >result in insecure implementations.

[John] I know. There are also WGs that spearate the protocol specification and implementation guidance in different RFCs. I think we should have more of that, expecially for protocols where there is experiance on how implement.

>  There have been a number issues brought up by people who have *coded* >these protocols, and *used* them in the real world.   You're opposing the >requests to update the document with guidance that the implementors say >they need.  The reasons you give are largely from inexperience: "I don't >understand why this matters".
>
>  Well, it does.  If you don't understand why, then please step aside, and >let the work be done by others.   If you won't step aside, then please >stop resisting guidance from people who have experience in this area.
>
>  To be perfectly frank: if this specification does not meet the needs of >implementors, then they will ignore it, and go do whatever they want.  >This particular specification will be ignored.  And once implementors are >ready, they will bring a specification to the IETF which says "ignore the >previous spec, this is what we actually did".
>
>Implementors have a long established a set of practices which are NOT >written down in any standard.  These practices help to both secure the >network, and make these systems easier to deploy.

[John] I don’t know what you think I have opposed. So far I can recall two significant chucks of established practice text that you have suggested. Text regarding resumption, which is now in the document, and recent practice text regarding authentication that I have NOT resisted. 

[John] Note that guidance text is not always easy for the WG to reach consensus about. Your resumption guidance text for example got quite a lot of comments both before and after it was put in the document.

>i.e.: Instead of fighting with standards bodies, implementors have gone >and done their own thing, because the specifications are lacking.  Worse, >the processes used by standards bodies are lacking.

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Friday, 19 February 2021 at 12:31
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 19 Feb 2021 11:19:51 -0500

> It would very nice if you stopped putting words in my mouth and stopped accusing me personally for IETF procedures, which I feel you do.

  You aren't responsible for IETF procedures.  But IETF procedures involve people discussing topics.  This discussion is with the goal of reaching consensus.  You are responsible for pushing back against suggestions.  Which is fine if the reasons help move the document forward.

  I'm not suggesting things because I'm being troublesome.  I'm suggesting things because they're *useful*.  I'm explaining *why* they're useful.  But there's push-back because... you don't see why the suggestions are useful?

  That's concerning.

> [John] I have not stated that I don't think your text should be put in the document. I do. And your suggested text certainly affect security. I simply meant that this was not the kind of requiremen…

  No one suggested that implementations don't follow RFC 5216.  And as I said, the code is publicly available.  This isn't the first time I've addressed protocol issues by pointing people at code.

  The point I was making is that implementations do MORE than what RFC 5216 suggests.  I think it is entirely reasonable to update the document to explain this.

  If the implementations find it useful to do something, then there must be reasons for it.  We should either explain WHY it's necessary to do these things, OR explain why these implementations are wrong.

> [John] My role as one of the authors is not to decide what goes into the document or to produce all the text. After adoption, my role is to add text that there is WG consensus on. Sometimes that in…

  Like pushing back on suggestions which I believe are important, for reasons *other* than "that is technically wrong".

> [John] Except the first sentence, I agree with you.

  You have pushed back against feedback from implementors.  You've pushed back against giving guidance to implementors.  Which makes the document largely an academic exercise.

> If you suggest guidance text and that text has WG consensus, me and Mohit will add it to the document (Given that the shepard and AD are ok with it). Most of your suggested resumption guidance text is e.g. in the document. Some of the *why* text you have requested has been about TLS 1.3, I think you need to ask people that took part in these specific discussions in the TLS WG for this. Futhermore, there was people recently suggesting that all TLS guidance was to be removed. Then it is hard to arguee that there is IETF consensus to add more.

  EAP is an application which uses TLS.  As such, it is entirely relevant to add text explaining how to use TLS (e.g. the number of session tickets, and what to do with them).  This text would help guide implementors as to what to do.

  The only push-back on that text was you.  So it's a little disingenuous to claim "there's no IETF consensus".

> [John] Note also that at this late state of the document process it is harder to harder to justify new technical changes that are not related ot the IESG review. 

  This is *entirely* the wrong approach to take.  The purpose of the IETF process is not to ram documents through come hell or high water.  If a late review discovers major issues with the document, then the document can be fixed.  This has happened before, and is part of the IETF process.

   I'll also note your earlier comment, which raised another major red flag: Basically the comment was that if we weren't sure what to say, we should just publish the document and figure it out later. 

   This comes across STRONGLY that process is more important than content.

  I disagree completely.  People will implement and deploy a specification.  They don't care what process was used.  They only see the end result.  As such, it is critical to get the content correct.

> [John] I know. There are also WGs that spearate the protocol specification and implementation guidance in different RFCs. I think we should have more of that, expecially for protocols where there i…

  So... should we, or shouldn't we update this document with implementation guidance?

> [John] I don’t know what you think I have opposed. So far I can recall two significant chucks of established practice text that you have suggested. Text regarding resumption, which is now in the do…

  I had comments on session tickets.  You opposed that, because "RFC 8446 doesn't provide guidance" on this issue.

  The TLS RFCs have historically been silent on choosing encryption methods, digests, etc.  Yet there are any number of RFCs which describe an application using TLS, and which give guidance as to which encryption methods are mandatory to support.  I can think of 3 just for RADIUS.

> [John] Note that guidance text is not always easy for the WG to reach consensus about. Your resumption guidance text for example got quite a lot of comments both before and after it was put in the…

  Do you think that's news to me?

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 22 Feb 2021 08:40:35 -0500

I'd like to apologize to John for mis-stating what he said.  That attempt at paraphrasing his comments was wrong.

  I will summarize any technical issues I have in a separate thread.

  Alan DeKok

---

From: John Mattsson <[email-masked]>
Date: Tue, 23 Feb 2021 14:10:11 +0000

Appology accepted.

John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Monday, 22 February 2021 at 14:41
To: John Mattsson <[email-masked]>
Cc: EMU WG <[email-masked]>
Subject: Re: [Emu] Key Derivation for EAP-TLS 1.3

  Alan DeKok