Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

From: Alan DeKok <[email-masked]>
Date: Fri, 1 Nov 2019 07:08:03 -0400

On Nov 1, 2019, at 6:15 AM, John Mattsson <[email-masked]> wrote:
> I strongly support working group adoption of draft-dekok-emu-tls-eap-types. Can we make sure to get this document going, I agree that this is a very needed draft. I think it should include updates for everything people wants to use. I do not think draft-ietf-emu-eap-tls13 strictly have to wait for draft-dekok-emu-tls-eap-types, but draft-dekok-emu-tls-eap-types should be published shortly after.

  I will do an update to my document shortly.

  I also added an issue with the EAP-TLS document on GitHub.  The suggestion is to add text which explains how (and why) the EAP Identity is chosen during resumption:

---
The EAP Identity used in resumption SHOULD be the same EAP Identity as was used during the original authentication. This requirement allows EAP packets to be routable through an AAA infrastructure to the same destination as the original authentication.

The alternative is to derive the EAP Identity from the identity used inside of TLS. This derivation is common practice when using certificates, and works because the "common name" field in the certificate is typically compatible with EAP, and it contains a routable identifier such as an email address. This practice cannot be used for resumption, as the PSK identity may be a binary blob, and it might not contain a routable realm as suggested by RFC 7542.

In some cases, the PSK identity is derived by the underlying TLS implementation, and cannot be controlled by the EAP authenticator. These limitations make the PSK identity unsuitable for use as the EAP Identity.
---

  Alan DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 1 Nov 2019 12:53:59 +0100

Thanks, Alan.  Please see below.

> On 1 Nov 2019, at 12:08, Alan DeKok <[email-masked]> wrote:
> 

Just a question: why SHOULD and not MUST?

> In some cases, the PSK identity is derived by the underlying TLS implementation, and cannot be controlled by the EAP authenticator. These limitations make the PSK identity unsuitable for use as the…

Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for federated realms (we may both have this wrong).  My presumption here is that an anonymous NAI is always used, but that the realm is what people would key off of, and this would always be present.  But that presumption doesn’t hold true with the current TEAP update that we’re working on and that may be problematic.  In any case, this means that that at least the externalized identity can be used to route, and that normal TLS semantics can be used for authenticating.  It does require that tickets be managed on both ends.

My presumption is further that federation doesn’t really occur beyond the TLS endpoint, of it it does that is entirely an internal matter for the server.  We have a working example of callouts based on the identity of a client for purposes of authorization, but for authentication, I would think that would be largely a bad idea, due to secret sharing issues (when I say “federation” I mean that there should be no trust TLS secret sharing).

Is my understanding correct?

Eliot

---

From: Alan DeKok <[email-masked]>
Date: Fri, 1 Nov 2019 08:05:53 -0400

> Just a question: why SHOULD and not MUST?

  I'm happy to have it a MUST.

  I'm prepared for some people to say it can be different, i.e a different AAA server can be used for resumed sessions.  But I don't see that as important.

> Ok, so this sort of impacts the other drafts as well (NOOB and TEAP) for federated realms (we may both have this wrong).  My presumption here is that an anonymous NAI is always used, but that the realm is what people would key off of, and this would always be present.

  As the EAP Identity, yes.

>  But that presumption doesn’t hold true with the current TEAP update that we’re working on and that may be problematic.  In any case, this means that that at least the externalized identity can be used to route, and that normal TLS semantics can be used for authenticating.  It does require that tickets be managed on both ends.

  If the authentications are performed within a constrained system, it's fine to skip using NAIs.  I would suggest that for device bootstrapping you want to ensure that the authentications *aren't* routed outside of the current network.  So they *shouldn't* use a realm.

  That's why my suggested text said "resumption uses same identity as the original authentication" .... whatever that is.  That initial identity doesn't need to be an NAI.

  However, the identities still need to be acceptable to EAP / AAA systems.  Which means that any binary identity should likely be converted to a "printable" form, via something like base64.

> My presumption is further that federation doesn’t really occur beyond the TLS endpoint, of it it does that is entirely an internal matter for the server.

  Yes.

  Federation works because nothing examines the contents of EAP.  Instead, the packets are routed solely based on the NAI.

>  We have a working example of callouts based on the identity of a client for purposes of authorization, but for authentication, I would think that would be largely a bad idea, due to secret sharing issues (when I say “federation” I mean that there should be no trust TLS secret sharing).
> 

  Yes.

  There may be federations which share a common CA cert.  But each authentication system is unique, and does not share its secrets / identity with any other system.

  Aln DeKok.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 1 Nov 2019 14:14:33 +0100

Hi!

> On 1 Nov 2019, at 13:05, Alan DeKok <[email-masked]> wrote:
> 

Ok.  Got it.  I think we have to be quite careful about use of the realm, then, and mechanism selection must be done exclusively with EAP-Request/Type.  I think it’s okay for federations to bootstrap; although we needn’t define that here.

I’ll be updating our draft accordingly.

Eliot

---

From: Joseph Salowey <[email-masked]>
Date: Sun, 3 Nov 2019 10:31:09 -0800

On Fri, Nov 1, 2019 at 4:08 AM Alan DeKok <[email-masked]> wrote:

> > I strongly support working group adoption of
> draft-dekok-emu-tls-eap-types. Can we make sure to get this document going,
> I agree that this is a very needed draft. I think it should include updates
> for everything people wants to use. I do not think draft-ietf-emu-eap-tls13
> strictly have to wait for draft-dekok-emu-tls-eap-types, but
> draft-dekok-emu-tls-eap-types should be published shortly after.
>
>   I also added an issue with the EAP-TLS document on GitHub.  The
> suggestion is to add text which explains how (and why) the EAP Identity is
> chosen during resumption:
>
> ---
> The EAP Identity used in resumption SHOULD be the same EAP Identity as was
> used during the original authentication. This requirement allows EAP
> packets to be routable through an AAA infrastructure to the same
> destination as the original authentication.

The alternative is to derive the EAP Identity from the identity used inside
> of TLS. This derivation is common practice when using certificates, and
> works because the "common name" field in the certificate is typically
> compatible with EAP, and it contains a routable identifier such as an email
> address. This practice cannot be used for resumption, as the PSK identity
> may be a binary blob, and it might not contain a routable realm as
> suggested by RFC 7542.
>
>
[Joe] Do implementations use the whole common name or just the domain
portion.  Using the whole common name is not advisable with TLS 1.3.

> In some cases, the PSK identity is derived by the underlying TLS
> implementation, and cannot be controlled by the EAP authenticator. These
> limitations make the PSK identity unsuitable for use as the EAP Identity.
>

[Joe]  Is EAP Identity Synonymous with the NAI?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 4 Nov 2019 10:49:59 -0500

After checking the draft again, Section 2.1.4 does have comments about anonymizing the NAI.  But those comments are limited to NAIs derived from certificates.

  I think that the text needs to be expanded to make the recommendations more genetic, and clearer.  I hope that my previous message clarified some of the issues here.

  I would like to see some discussion of these topics in the draft.  I don't think it's clear enough that the EAP Identity should always be "@realm", and there is no discussion on EAP Identity and resumption.

  I would suggest a new section called "Identities".  This section could go after 2.1.1, and incorporate some existing text from the Privacy section.  Suggested text follows.

Identities

EAP-TLS peer and server implementations supporting TLS 1.3 or higher
MUST support anonymous NAIs (Network Access Identifiers) (Section 2.4
in [RFC7542]) and a client supporting TLS 1.3 MUST NOT send its
username in cleartext in the Identity Response.  It is RECOMMENDED to
use anonymous NAIs, but other solutions where the username is
encrypted MAY be used.

This recommendation applies to all uses of EAP-TLS, no matter the underlying TLS authentication mechanism.  This recommendation also applies when resumption is used.

The anonymous NAI can often be derived automatically.  When certificates are used, the certificate common name is often in the form of an email address.  The anonymous NAI can be derived from that address by using only the "@realm" portion.  This derivation has privacy implications, as discussed in the Privacy section, below.

In some cases, the anonymous NAI cannot be derived from the underlying TLS authentication mechanism.  For example, when PSKs are used, the PSK identity may be an opaque binary string.  Binary data is not compatible with the EAP Response / Identity field, as Section 5.1 of 3748 requires that the Identity field be composed solely of UTF-8 encoded ISO 10646 characters.  Instead, the Identity may be statically pre-provisioned.  Or for resumption, the Identity used for resumption SHOULD be the same as the Identity used for the original authentication.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 7 Nov 2019 17:30:16 +0000

> -----Original Message-----
> From: Emu <[email-masked]> On Behalf Of Joseph Salowey
> Sent: 31 October 2019 04:45
> To: Alan DeKok <[email-masked]>
> Cc: [email-masked]; John Mattsson
> <john.mattsson=[email-masked]>; Michael Richardson
> <[email-masked]>; EMU WG <[email-masked]>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> On Wed, Oct 30, 2019 at 4:12 AM Alan DeKok
> <mailto:[email-masked]> wrote:
> On Oct 30, 2019, at 5:02 AM, Eliot Lear <mailto:[email-masked]> wrote:
> > A fair argument, if it can be made, and I am not convinced it has been fully
> expressed, is the idea that there is no context by which one can separate fast
> restart and initial authentication.  This is Alan’s concern.  I’m not saying it’s
> without merit, but what I cannot yet see is whether it is an implementation or a
> protocol matter.
> 
>   I believe it's a protocol matter.  In TLS 1.3, PSK handshakes are the same as
> resumption handshakes.
> 
>   It's not clear to me how this issue was addressed when using TLS 1.3 with
> HTTPS.  But I do believe it's an issue there, too.
> 
> [Joe] Can you elaborate on what the issue is?  I think most TLS deployments
> operate in either a certificate based mode or a PSK mode, but not both at the
> same time.

[ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I don't think TLS with extern PSK is really intended for Web/Browser HTTPS connections. Its more for devices/things which are preprovisioned with the extern PSK.

In TLS1.3, by design the protocol does not differentiate between resumption and external PSKs, and says nothing about PSK ID format, as commented here https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 , https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc 

And its application specific how the two are differentiated, the spec says nothing about it: https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o

I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. Surely it should be an EAP server implementation decision on whether to support that feature or not, but we should not preclude a specific EAP server implementation from supporting extern PSK by disallowing it in the spec. If a particular EAP server does not want to support extern PSK - that’s fine.

> 
>   As an additional note, I believe it's also important that draft-dekok-emu-tls-
> eap-types be published at the same time as the EAP-TLS document.  The only
> unknown there is FAST and TEAP.  I'm happy to remove them from the
> document.
> 
>   But at this point it's not even a WG document.  There's not even consensus that
> the document necessary, which surprises me rather a lot.  Because password-
> based EAP methods are *much* more wide-spread than EAP-TLS.
> 
>   If the IETF publishes EAP-TLS without simultaneously rev'ing TTLS and PEAP, it
> will not only look bad, it will *be* bad.  And the industry press will (rightfully)
> lambast the standards process.
> 
> [Joe] We need people to contribute to the document.  If we are going to publish
> a document through the working group it needs to at least to include TEAP.   I
> know there are folks on this list who are implementing.  They need to step up
> and help with this document and the TEAP errata.
> 
>   Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 7 Nov 2019 12:48:14 -0500

> [ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously. draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I don't think TLS with extern PSK is really int…

  Then the EAP-TLS document should disallow it, too.  If TLS 1.3 doesn't support it, I don't see how something built on top of TLS 1.3 can support it.

> In TLS1.3, by design the protocol does not differentiate between resumption and external PSKs, and says nothing about PSK ID format, as commented here https://mailarchive.ietf.org/arch/msg/tls/Q5K8…

  Which is fine.  I'm happy to have PSKs be anything.  The caveat is that we then MUST forbid the PSKs from being copied to the EAP Identity field.  So the EAP-TLS document has to make a recommendation.

> I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3. Surely it should be an EAP server implementation decision on whether to support that feature or not, but we should not p…

  Then we need to give guidance on what implementors and administrators should do.  Even if it means adding text saying "you can do certs OR PSK, but NOT BOTH".

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 8 Nov 2019 07:43:25 -0500

On Nov 7, 2019, at 11:08 PM, Joseph Salowey <[email-masked]> wrote:
> [Joe] How about 
> "If an implementation supports an external PSK it MUST provide a way to configure the realm so it can create an Anonymous NAI to send in the EAP-Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the PSK-ID into the EAP-Identity response. "

  That's good.

> If someone thinks there is a need to allow the PSK-ID to be copied then the phrase could be extended with " unless there is prior knowledge that this will have an acceptable impact to privacy and the use case supports Identity responses that are not in the form of an NAI.  

  ... and the PSK identity is compatible with the requirements of the EAP Identity field, i.e. UTF-8.

> [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as mutually exclusive for a particular handshake.   I do not think it restricts a particular server from supporting both external PSK and certificate authentication for separate connections.  

  OK.  I'm back to "how do you tell?"

  If the document suggests that plain PSK is OK, it would be very useful to describe the impact of that.  What does an implementation do?  How should administrators tell PSK identities apart?  If the EAP authenticator can't control the derivation of PSK identities for resumption, is it even possible to have manually provisioned PSKs?

  Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 11 Nov 2019 17:28:21 +0000

> From: Alan DeKok <[email-masked]>
> Sent: 07 November 2019 17:48
> To: Owen Friel (ofriel) <[email-masked]>
> Cc: Joseph Salowey <[email-masked]>; [email-masked];
> John Mattsson <john.mattsson=[email-masked]>; Michael
> Richardson <[email-masked]>; EMU WG <[email-masked]>
> > [ofriel] TLS1.3 explicitly does not allow both PSK and certs simultaneously.
> draft-ietf-tls-tls13-cert-with-extern-psk does, but that’s Experimental. I don't
> think TLS with extern PSK is really intended for Web/Browser HTTPS
> connections. Its more for devices/things which are preprovisioned with the
> extern PSK.
> 
>   Then the EAP-TLS document should disallow it, too.  If TLS 1.3 doesn't support
> it, I don't see how something built on top of TLS 1.3 can support it.

[ofriel]  TLS1.3 does not allow both PSK and cert based auth simultaneously on the same TLS session. It does allows support of both PSK and cert based auth on the same server, just on different TLS sessions. What draft-ietf-tls-tls13-cert-with-extern-psk does is allow both PSK and cert based auth simultaneously on the same TLS session. I can see how my statement was confusing, apologies.

> 
> > In TLS1.3, by design the protocol does not differentiate between resumption
> and external PSKs, and says nothing about PSK ID format, as commented here
> https://mailarchive.ietf.org/arch/msg/tls/Q5K8HSPPgLRojQwXbV4ZTIxBIH0 ,
> https://mailarchive.ietf.org/arch/msg/tls/X_z8pc3oS2Au7KajjMhlWhP1UPc
> 
>   Which is fine.  I'm happy to have PSKs be anything.  The caveat is that we then
> MUST forbid the PSKs from being copied to the EAP Identity field.  So the EAP-
> TLS document has to make a recommendation.
> 
> > And its application specific how the two are differentiated, the spec says
> nothing about it:
> https://mailarchive.ietf.org/arch/msg/tls/btLnZERYv8GJJ2PFUksjNsDyv8o
> >
> > I still don't get why EAP-TLS1.3 should place restrictions on use of TLS1.3.
> Surely it should be an EAP server implementation decision on whether to support
> that feature or not, but we should not preclude a specific EAP server
> implementation from supporting extern PSK by disallowing it in the spec. If a
> particular EAP server does not want to support extern PSK - that’s fine.
> 
>   Then we need to give guidance on what implementors and administrators
> should do.  Even if it means adding text saying "you can do certs OR PSK, but
> NOT BOTH".
[ofriel] You can do certs or PSK on the same TLS server, just not on the same TLS session. Unless draft-ietf-tls-tls13-cert-with-extern-psk became a thing.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Mon, 11 Nov 2019 17:52:28 +0000

> From: Emu <[email-masked]> On Behalf Of Alan DeKok
> Sent: 08 November 2019 12:43
> To: Joseph Salowey <[email-masked]>
> Cc: EMU WG <[email-masked]>
> > "If an implementation supports an external PSK it MUST provide a way to
> configure the realm so it can create an Anonymous NAI to send in the EAP-
> Identity response.  An EAP-TLS 1.3  implementation MUST NOT copy the PSK-ID
> into the EAP-Identity response. "
> 
>   That's good.

[ofriel]  Is the primary reason they MUST NOT be copied because of encoding differences? UTF-8 vs. TLS raw bytes?

On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypted in cleartext in the ClientHello, what information leakage are we preventing by not sending that same data in cleartext in the Identity Response?

Note that TLS1.3 PSK IDs are different to TLS1.3 client certs: PSK IDs are sent in cleartext in the ClientHello, client certs are sent encrypted inside the client's second flight. PSK IDs are not protected, client certs are (assuming of course that the client can validate the server identity when the server sends its first flight to the client).

> 
> > If someone thinks there is a need to allow the PSK-ID to be copied then the
> phrase could be extended with " unless there is prior knowledge that this will
> have an acceptable impact to privacy and the use case supports Identity
> responses that are not in the form of an NAI.
> 
> > [Joe] The TLS 1.3 base spec teats certificate auth and external PSK auth as
> mutually exclusive for a particular handshake.   I do not think it restricts a
> particular server from supporting both external PSK and certificate
> authentication for separate connections.

[ofriel] Right.

>   OK.  I'm back to "how do you tell?"

[ofriel]  You can of course trivially tell the difference between an extern PSK and a cert based auth - the ClientHellos are different.

This is a different question to the difference between an extern PSK and a resumption PSK. That is implementation specific and not defined in TLS1.3

> 
>   If the document suggests that plain PSK is OK, it would be very useful to
> describe the impact of that.  What does an implementation do?  How should
> administrators tell PSK identities apart?  If the EAP authenticator can't control
> the derivation of PSK identities for resumption, is it even possible to have
> manually provisioned PSKs?

[ofriel] I agree some implementation advice would be good here. Should this be in EAP, or should we push for a TLS1.3 errata? It's the same advice that a standard TLS1.3 server implementor needs. OpenSSL for example defines its own resumption format, and provides a callback hook to check for extern PSKs, and it looks like OpenSSL lets the application check for an extern PSK match first before checking its internal resumption cache: https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093. But of course that is TLS stack specific. We would need to document guidance olong the lines of checking for TLS stack behaviour.

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

---

From: Alan DeKok <[email-masked]>
Date: Mon, 11 Nov 2019 14:41:37 -0500

> [ofriel]  Is the primary reason they MUST NOT be copied because of encoding differences? UTF-8 vs. TLS raw bytes?

  Yes.  EAP Identities are UTF-8 encoded strings.  Non-compliant identities will likely result in the packet being dropped.

> On the privacy aspect, as the TLS PSK ID is sent unprotected and unencrypted in cleartext in the ClientHello, what information leakage are we preventing by not sending that same data in cleartext i…

  Not much.  Except that if we send the data in the Identity, it MUST be encoded in some format which is acceptable to EAP, RADIUS, etc.

  Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets in length.  While EAP can carry large identities, RADIUS cannot.  So we're left with a practical limitation of ~250 octets for the identity field.

  At that point, it's best to recommend that the EAP Identity carry only an anonymous NAI.  That avoids the issue of PSK length and encoding entirely.  Further, it means that all uses of EAP-TLS have the same recommendation: the Identity is an anonymous NAI.

> This is a different question to the difference between an extern PSK and a resumption PSK. That is implementation specific and not defined in TLS1.3

  i.e. "good luck".  :(

  It's difficult for implementors to do the right thing in such a situation.

> [ofriel] I agree some implementation advice would be good here. Should this be in EAP, or should we push for a TLS1.3 errata? It's the same advice that a standard TLS1.3 server implementor needs. O…

  I think it's best to give guidance in this document.

  Alan DeKok.

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 11 Nov 2019 14:38:23 -0800

On Mon, Nov 11, 2019 at 11:41 AM Alan DeKok <[email-masked]>
wrote:

> > [ofriel]  Is the primary reason they MUST NOT be copied because of
> encoding differences? UTF-8 vs. TLS raw bytes?
>
>   Yes.  EAP Identities are UTF-8 encoded strings.  Non-compliant
> identities will likely result in the packet being dropped.
>
> > On the privacy aspect, as the TLS PSK ID is sent unprotected and
> unencrypted in cleartext in the ClientHello, what information leakage are
> we preventing by not sending that same data in cleartext in the Identity
> Response?
>
>   Not much.  Except that if we send the data in the Identity, it MUST be
> encoded in some format which is acceptable to EAP, RADIUS, etc.
>
>   Further, RFC 8446 says that PSK Identities can be be up to 2^16-1 octets
> in length.  While EAP can carry large identities, RADIUS cannot.  So we're
> left with a practical limitation of ~250 octets for the identity field.
>
>   At that point, it's best to recommend that the EAP Identity carry only
> an anonymous NAI.  That avoids the issue of PSK length and encoding
> entirely.  Further, it means that all uses of EAP-TLS have the same
> recommendation: the Identity is an anonymous NAI.
>
>
[Joe] I agree that its best to only include the anonymous NAI.  Including
more information may cause a problem if the PSK works changes in the future
or if you are copying the original NAI into subsequent transactions.

> > This is a different question to the difference between an extern PSK and
> a resumption PSK. That is implementation specific and not defined in TLS1.3
>
>   i.e. "good luck".  :(
>
> > [ofriel] I agree some implementation advice would be good here. Should
> this be in EAP, or should we push for a TLS1.3 errata? It's the same advice
> that a standard TLS1.3 server implementor needs. OpenSSL for example
> defines its own resumption format, and provides a callback hook to check
> for extern PSKs, and it looks like OpenSSL lets the application check for
> an extern PSK match first before checking its internal resumption cache:
> https://github.com/openssl/openssl/blob/master/ssl/statem/extensions_srvr.c#L1093.
> But of course that is TLS stack specific. We would need to document
> guidance olong the lines of checking for TLS stack behaviour.
>
[Joe] If its needed then I also think we should include it in the EAP-TLS
document.  It wouldn't be bad to file an errata on TLS 1.3, but I think
this is more of a corner case for them.