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

From: Aura Tuomas <[email-masked]>
Date: Thu, 12 Sep 2019 13:53:02 +0000

I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it forbids PSK authentication. Why is that? While there is the EAP-PSK method, I would much rather use EAP-TLS with PSK because it provides identity protection and perfect forward secrecy, unlike EAP-PSK. 

In fact, I think EAP-TLS with PSK should become the standard authentication method for networks that rely on shared secrets, e.g. WPA-Personal. Unifying the Wi-Fi authentication around EAP would greatly simplify the Wi-Fi protocol stack. Not that I expect it to happen immediately, but we should not close sensible paths forward.

Tuomas

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Sep 2019 09:56:10 -0400

On Sep 12, 2019, at 9:53 AM, Aura Tuomas <[email-masked]> wrote:
> 
> I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it forbids PSK authentication. Why is that?

  See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we *cannot* use PSK for authentication in EAP-TLS.

> While there is the EAP-PSK method, I would much rather use EAP-TLS with PSK because it provides identity protection and perfect forward secrecy, unlike EAP-PSK. 

  Use EAP-PWD for that.

> In fact, I think EAP-TLS with PSK should become the standard authentication method for networks that rely on shared secrets, e.g. WPA-Personal. Unifying the Wi-Fi authentication around EAP would gr…

  The time to fix that was before TLS 1.3 was standardized.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Thu, 12 Sep 2019 14:55:12 +0000

See comments inline

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Thursday, 12 September 2019 at 15:56
To: Aura Tuomas <[email-masked]>
Cc: EMU WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]>
Resent to: John Mattsson <[email-masked]>, <[email-masked]>
Resent date: Thursday, 12 September 2019 at 15:56

>    Alan DeKok wrote:    
>    > I was looking at the EAP-TLS with TLS 1.3 draft and noticed that it forbids PSK >authentication. Why is that?
    
There was discussion regarding this on the list some years ago. The conclusion was to use the EAP-TLS Type-Code should be exclusively for certificate authentication. At that point, nobody expressed wish to use EAP-TLS with PSK authentication. If someone wants to use EAP-TLS with symmetric keys that should probably be a  new code point.

>      See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we *cannot* use PSK for >authentication in EAP-TLS.

I don't understand why this could not be done. My view is that allowing PSK authentication would be quite easy.

>    > While there is the EAP-PSK method, I would much rather use EAP-TLS with PSK because it >provides identity protection and perfect forward secrecy, unlike EAP-PSK. 
>    
>      Use EAP-PWD for that.

Standardizing EAP-TLS should only be done if it has some significant advantages over EAP-PWD, and there are people wanting to implement and use it. 3GPP is e.g. adding  identity protection and perfect forward secrecy to EAP-AKA instead.

>    
>    > In fact, I think EAP-TLS with PSK should become the standard authentication method for >networks that rely on shared secrets, e.g. WPA-Personal. Unifying the Wi-Fi authentication >around EAP would greatly simplify the Wi-Fi protocol stack. Not that I expect it to happen >immediately, but we should not close sensible paths forward.
>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 12 Sep 2019 11:27:51 -0400

> I don't understand why this could not be done. My view is that allowing PSK authentication would be quite easy.

  How would systems tell the difference between "raw" PSK and "resumption" PSK?

  When allowing resumption, the server has sent a PSK identity in a NewSessionTicket message.  The client caches this and re-uses this.  But the client signals that it is performing resumption via the act of using PSK.  There's nothing else.

  Which means that if PSK was allowed, the server can't look at the packets to distinguish resumption from "raw" PSK.  Instead, the server has to look at it's resumption cache which may be in a DB.

> Standardizing EAP-TLS should only be done if it has some significant advantages over EAP-PWD, and there are people wanting to implement and use it. 3GPP is e.g. adding  identity protection and perf…

  I would prefer to forbid PSK in EAP-TLS. 

  Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 18 Sep 2019 12:45:07 +0000

> From: Emu <[email-masked]> On Behalf Of Alan DeKok
> Sent: 12 September 2019 16:28
> To: John Mattsson <[email-masked]>
> Cc: [email-masked]; EMU WG <[email-masked]>
> >>     See Section 2.1.2.  TLS 1.3 uses PSK for resumption.  As a result, we
> *cannot* use PSK for >authentication in EAP-TLS.
> >
>   When allowing resumption, the server has sent a PSK identity in a
> NewSessionTicket message.  The client caches this and re-uses this.  But the
> client signals that it is performing resumption via the act of using PSK.  There's
> nothing else.
> 
>   Which means that if PSK was allowed, the server can't look at the packets to
> distinguish resumption from "raw" PSK.  Instead, the server has to look at it's
> resumption cache which may be in a DB.

The server can use the PskIdentity in the PreSharedKeyExtension to differentiate between an offline PSK used for authentication vs. a PSK established via NewSessionTicket.

There should be no problem here, and the statement

" Pre-Shared Key (PSK) authentication SHALL NOT be used except
   for resumption. "

should be updated to clarify.

> 
> >>> While there is the EAP-PSK method, I would much rather use EAP-TLS
> with PSK because it >provides identity protection and perfect forward
> secrecy, unlike EAP-PSK.
> >>
> >>     Use EAP-PWD for that.
> >
> > Standardizing EAP-TLS should only be done if it has some significant
> advantages over EAP-PWD, and there are people wanting to implement and
> use it. 3GPP is e.g. adding  identity protection and perfect forward secrecy to
> EAP-AKA instead.
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 Sep 2019 09:06:58 -0400

> The server can use the PskIdentity in the PreSharedKeyExtension to differentiate between an offline PSK used for authentication vs. a PSK established via NewSessionTicket.

  Please define "use".  As an implementor, I can't implement "my code USES a field".  I need to know what the code *does* with it.

  How does the code differentiate between PSK identities?  Are the identity formats different?  If so, how and why?

  What prevents a malicious attacker from "using" a format which matches an identity coming from NewSessionTicket?

  My understanding is that the code *cannot* make any decisions simply by looking at the PSK identity field.  Instead, it has to look at the resumption cache to see if a given PSK matches a cached one.  Or maybe the code looks in a DB to see if the given PSK is a real "end-user" PSK in the DB.

  Simply waving your hands and saying it "uses" a field is unhelpful.  Please give substantive feedback and/or advice about what the code *does*.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Wed, 18 Sep 2019 13:21:03 +0000

If I understand you correctly Alan, your implementation would have different databases (one resumption DB and one external PSK DB) and you do not want to do two database lookups. The format of the PSKidentities is free for the deployment to decide upon and the resumption PSKs can be completely be determined by the EAP-TLS implementation. Your implementation could for example put a message authentication code inside the PSK identity. The MAC would be calculated with a symmetric key the EAP server has randomly generated by itself. I think that would solve your problem.

I do not see how an attacker could do anything..... an attacker can definitely reuse any PSK identity, but would not have the corresponding PSK and the ClientHello would therefore not be accepted. The worst thing an attacker could do is to replay a ClientHello, then the handshake would fail then the EAP server verifies the Finished message.

I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that in any other application of EAP-TLS.

/John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Wednesday, 18 September 2019 at 15:07
To: "Owen Friel (ofriel)" <[email-masked]>
Cc: John Mattsson <[email-masked]>, "[email-masked]" <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

    

    
    
      Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 Sep 2019 09:21:24 -0400

Just re-reading the text on PSK, I noticed a few things.  The text in Section 2.1.2 talks about PSK, the session ticket, and a "key_share" extension.   The accompanying diagram doesn't include any of those.  I suggest updating the diagram to include them.

  As a related note, if the PSK *is* in the resumption cache, but the key is wrong, the cache entry should not be discarded.  Otherwise an attacker can disable caching for *all* users.  This issue could be clearer in this document.

  Perhaps it would be useful to add a short note in Section 5 about security of resumption.  It should reference RFC 8446 Section 8.1, and 8.2, which discuss this issue.  Also, Section 4.2.11 of that document has an "Implementor's note:" which is important.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 Sep 2019 09:39:33 -0400

> On Sep 18, 2019, at 9:21 AM, John Mattsson <[email-masked]> wrote:
> 
> If I understand you correctly Alan, your implementation would have different databases (one resumption DB and one external PSK DB) and you do not want to do two database lookups.

  It's more about what *can* be done.  RFC 8446 Section 8.1 and 8.2 talk about using multiple DBs, too.

> The format of the PSKidentities is free for the deployment to decide upon and the resumption PSKs can be completely be determined by the EAP-TLS implementation. Your implementation could for example put a message authentication code inside the PSK identity. The MAC would be calculated with a symmetric key the EAP server has randomly generated by itself. I think that would solve your problem.

  I suggest giving guidance to implementors.  Otherwise the issue is open to implementation-defined behaviour, which is problematic.

  If PSKs are used only for resumption, the the format doesn't matter.  If PSKs are used for both authentication *and* resumption, then I strongly recommend giving guidance.

  For example, RFC 8446 Section 4.1.2 says:

      struct {
          opaque identity<1..2^16-1>;
          uint32 obfuscated_ticket_age;
      } PskIdentity;

  i.e. the PSK identity is an opaque binary string.  How is the user supposed to enter a binary string into a "username" field in their GUI?  What are the recommended formats?

  If the ClientHello isn't encrypted, then the PSK is visible to anyone (I believe).  And the PSK *must not* be a user-manageable string such as the NAI.  On the other hand, if the PSK is sent after encryption begins, then the PSK *should* be a user-manageable string such as an NAI.

  I see it being useful for EAP-TLS to allow PSK authentication.  I just want to be sure I know what that means, and what the impacts are.

> I do not see how an attacker could do anything..... an attacker can definitely reuse any PSK identity, but would not have the corresponding PSK and the ClientHello would therefore not be accepted.…

  I agree.  My larger point was that in the absence of guidance, it's impossible to know what to do with a PSK identity.

> I don't see why this would be more of a problem in EAP-TLS with TLS 1.3 that in any other application of EAP-TLS.

  I agree.

  Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 18 Sep 2019 21:42:08 +0000

> Sent: 18 September 2019 14:40
> Cc: Owen Friel (ofriel) <[email-masked]>; draft-ietf-emu-eap-
> [email-masked]; EMU WG <[email-masked]>
> > If I understand you correctly Alan, your implementation would have
> different databases (one resumption DB and one external PSK DB) and you
> do not want to do two database lookups.
> 
> > The format of the PSKidentities is free for the deployment to decide upon
> and the resumption PSKs can be completely be determined by the EAP-TLS
> implementation. Your implementation could for example put a message
> authentication code inside the PSK identity. The MAC would be calculated
> with a symmetric key the EAP server has randomly generated by itself. I think
> that would solve your problem.
> 
>   I suggest giving guidance to implementors.  Otherwise the issue is open to
> implementation-defined behaviour, which is problematic.

Giving some implementation guidance seems appropriate here. Naively, one could envisage the implementation simply having a DB table for extern PSKs and a table that holds NewSessionTickets. An implementation could simply check the extern PSK table using the PskIdentity.identity, and if no match is found then check the NewSessionTickets table. The default OpenSSL NSK ticketId is 32 bytes long https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if there is a clash (poor randoms, etc.). An additional layer of protection is provided by the PskBinderEntry as this is a HMAC derived using the PSK as one input, so the server even if there happened to be an identity clash, the binders will not match.

Implementations should also note https://tools.ietf.org/html/rfc8446#appendix-E.6. 

> 
>   If PSKs are used only for resumption, the the format doesn't matter.  If PSKs
> are used for both authentication *and* resumption, then I strongly
> recommend giving guidance.
> 
>   i.e. the PSK identity is an opaque binary string.  How is the user supposed to
> enter a binary string into a "username" field in their GUI?  What are the
> recommended formats?
> 
>   If the ClientHello isn't encrypted, then the PSK is visible to anyone (I
> believe).  

Well, more precisely, the PSK identity is visible in the ClientHello, not the actual PSK of course.

And the PSK *must not* be a user-manageable string such as the
> NAI.  On the other hand, if the PSK is sent after encryption begins, then the
> PSK *should* be a user-manageable string such as an NAI.

https://tools.ietf.org/html/rfc8446#section-2.2 also states:

"   Note:  When using an out-of-band provisioned pre-shared secret, a
      critical consideration is using sufficient entropy during the key
      generation, as discussed in [RFC4086].  Deriving a shared secret
      from a password or other low-entropy sources is not secure.  A
      low-entropy secret, or password, is subject to dictionary attacks
      based on the PSK binder.  The specified PSK authentication is not
      a strong password-based authenticated key exchange even when used
      with Diffie-Hellman key establishment.  Specifically, it does not
      prevent an attacker that can observe the handshake from performing
      a brute-force attack on the password/pre-shared key. "

so TLS-PSK is not suitable for a user entered low entropy password. We need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)

> 
>   I see it being useful for EAP-TLS to allow PSK authentication.  I just want to
> be sure I know what that means, and what the impacts are.

There are some use cases Eliot and I are looking at related to IoT onboarding where a TLS-PSK authentication has definite value, and we really don't want to see this avenue closed off in EAP. Happy to provide any suggestions on Implementation Notes to your draft.

> 
> > I do not see how an attacker could do anything..... an attacker can
> definitely reuse any PSK identity, but would not have the corresponding PSK
> and the ClientHello would therefore not be accepted. The worst thing an
> attacker could do is to replay a ClientHello, then the handshake would fail
> then the EAP server verifies the Finished message.

And note https://tools.ietf.org/html/rfc8446#appendix-E.6 where there is guidance on how to protect from an attacker determining a valid PSK identity.
> > I don't see why this would be more of a problem in EAP-TLS with TLS 1.3
> that in any other application of EAP-TLS.
> 
>   I agree.
> 
>   Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Wed, 18 Sep 2019 21:43:30 +0000

And one other draft of interest: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00

> From: Emu <[email-masked]> On Behalf Of Owen Friel (ofriel)
> Sent: 18 September 2019 22:42
> To: Alan DeKok <[email-masked]>; John Mattsson
> <[email-masked]>
> > different databases (one resumption DB and one external PSK DB) and
> > you do not want to do two database lookups.
> >
> > authentication code inside the PSK identity. The MAC would be
> > calculated with a symmetric key the EAP server has randomly generated
> > by itself. I think that would solve your problem.
> >
> >   I suggest giving guidance to implementors.  Otherwise the issue is
> > open to implementation-defined behaviour, which is problematic.
> 
> Giving some implementation guidance seems appropriate here. Naively, one
> could envisage the implementation simply having a DB table for extern PSKs
> and a table that holds NewSessionTickets. An implementation could simply
> check the extern PSK table using the PskIdentity.identity, and if no match is
> found then check the NewSessionTickets table. The default OpenSSL NSK
> ticketId is 32 bytes long
> https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86a
> d1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously
> wrong if there is a clash (poor randoms, etc.). An additional layer of
> protection is provided by the PskBinderEntry as this is a HMAC derived using
> the PSK as one input, so the server even if there happened to be an identity
> clash, the binders will not match.
> 
> Implementations should also note
> https://tools.ietf.org/html/rfc8446#appendix-E.6.
> 
> >
> >   If PSKs are used only for resumption, the the format doesn't matter.
> > If PSKs are used for both authentication *and* resumption, then I
> > strongly recommend giving guidance.
> >
> >   i.e. the PSK identity is an opaque binary string.  How is the user
> > supposed to enter a binary string into a "username" field in their
> > GUI?  What are the recommended formats?
> >
> >   If the ClientHello isn't encrypted, then the PSK is visible to
> > anyone (I believe).
> 
> > NAI.  On the other hand, if the PSK is sent after encryption begins,
> > then the PSK *should* be a user-manageable string such as an NAI.
> 
> so TLS-PSK is not suitable for a user entered low entropy password. We need
> a PAKE for that (c.f. the ongoing CFRG PAKE assessment)
> 
> 
> >
> >   I see it being useful for EAP-TLS to allow PSK authentication.  I
> > just want to be sure I know what that means, and what the impacts are.
> 
> There are some use cases Eliot and I are looking at related to IoT onboarding
> where a TLS-PSK authentication has definite value, and we really don't want
> to see this avenue closed off in EAP. Happy to provide any suggestions on
> Implementation Notes to your draft.
> 
> >
> > definitely reuse any PSK identity, but would not have the
> > corresponding PSK and the ClientHello would therefore not be accepted.
> > The worst thing an attacker could do is to replay a ClientHello, then
> > the handshake would fail then the EAP server verifies the Finished
> message.
> 
> And note https://tools.ietf.org/html/rfc8446#appendix-E.6 where there is
> guidance on how to protect from an attacker determining a valid PSK
> identity.
> >
> >   I agree.  My larger point was that in the absence of guidance, it's
> > impossible to know what to do with a PSK identity.
> >

---

From: Alan DeKok <[email-masked]>
Date: Wed, 18 Sep 2019 17:58:48 -0400

On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel) <[email-masked]> wrote:
> Giving some implementation guidance seems appropriate here. Naively, one could envisage the implementation simply having a DB table for extern PSKs and a table that holds NewSessionTickets. An implementation could simply check the extern PSK table using the PskIdentity.identity, and if no match is found then check the NewSessionTickets table.

  Which works, but should be called out in the draft.

  And what is to prevent the system from generating conflicting PSK identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3 resumption means that OpenSSLL will choose whatever PSK identity it deems fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if there is a clash (poor randoms, etc.). 

  i.e. "pick a long string and that should be good enough".

  If that really is the guidance, then this should also be called out in the draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?  If "end users" shouldn't be doing this, the draft also needs to call that out.

> Well, more precisely, the PSK identity is visible in the ClientHello, not the actual PSK of course.

  Sure.

> ...

  Sure.

> There are some use cases Eliot and I are looking at related to IoT onboarding where a TLS-PSK authentication has definite value, and we really don't want to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.  I'm not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be automatically provisioned with long binary data for both PSK identity and PSK itself".  Or even "PSK identities and/or passwords that are composed solely of printable ASCII characters are likely to be humanly entered, and thus insecure".

  Which means, of course, that people will ignore that and demand simple user names / passwords for EAP-TLS with PSK.  Because that's ever so much easier than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding it.

  Alan DeKok.

---

From: Jim Schaad <[email-masked]>
Date: Wed, 18 Sep 2019 23:27:47 -0700

I am going to come down on the side of no PSK should not be supported.
However my issues have nothing to do with how things are implemented and
more to do with the security properties of the EAP method.

When you use certificates, there is no leakage of who the client is as this
is encrypted by TLS.  When you use a restore session ticket, it is possible
to limit the number of times that the ticket can be used (for example once).
The PSK identity is public and unprotected so it can be used to track.  If
one is using PSK for the purpose of authentication then that value will
always be visible to intermediate parties for the purpose of tracking.
This can be slightly mitigated by using restore session tickets with PSK,
but you are going to send that PSK identifier over the wire many times.

This is just informational and can be ignored:

My current favorite way to deal with PSK/ticket identifiers is with
encryption:

32 bytes of index into table
32 bytes of date information
32 bytes of SIV (synthetic IV)

Encrypt the first two items using the SIV.  You can then have multiple keys
for decryption.  One for PSKs and a resolving one for session tickets.  If
the identifier does not decrypt then you reject.  Otherwise you look at the
date information and the index in the table for the secret information.  

It is even possible to play games with AAD to do things like scope the
tickets up front - if you put in the name/address of the NAS then you have a
prescreen on where the ticket can be used.

Jim

-----Original Message-----
From: Emu <[email-masked]> On Behalf Of Alan DeKok
Sent: Wednesday, September 18, 2019 2:59 PM
To: Owen Friel (ofriel) <[email-masked]>
Cc: [email-masked]; EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

could envisage the implementation simply having a DB table for extern PSKs
and a table that holds NewSessionTickets. An implementation could simply
check the extern PSK table using the PskIdentity.identity, and if no match
is found then check the NewSessionTickets table.

  And what is to prevent the system from generating conflicting PSK
identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3
resumption means that OpenSSLL will choose whatever PSK identity it deems
fit.

  As an implementor and/or admin, how do I choose *pre-provisioned* PSK
identities which won't conflict with the ones OpenSSL choose?

> The default OpenSSL NSK ticketId is 32 bytes long
https://github.com/openssl/openssl/blob/558ea84743918f7a93bfbfc259f86ad1fa4c
8de9/include/openssl/ssl3.h#L127 so something has gone seriously wrong if
there is a clash (poor randoms, etc.). 

  If that really is the guidance, then this should also be called out in the
draft.  PSK identities MUST be long (ideally 32 octets or more), and MUST be
generated from a CSPRNG.

  Which then leads to the question of what will the poor user enter in a UI?
If "end users" shouldn't be doing this, the draft also needs to call that
out.

  Sure.

> so TLS-PSK is not suitable for a user entered low entropy password. We 
> need a PAKE for that (c.f. the ongoing CFRG PAKE assessment)

  Sure.

> There are some use cases Eliot and I are looking at related to IoT
onboarding where a TLS-PSK authentication has definite value, and we really
don't want to see this avenue closed off in EAP.

  I don't know the exact use-case, but TBH I'd suggest EAP-PWD for that.
I'm not sure that EAP-TLS with PSK adds any value here.

  Allowing PSK means that the draft should likely say "end users MUST NOT be
using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems can be
automatically provisioned with long binary data for both PSK identity and
PSK itself".  Or even "PSK identities and/or passwords that are composed
solely of printable ASCII characters are likely to be humanly entered, and
thus insecure".

  Which means, of course, that people will ignore that and demand simple
user names / passwords for EAP-TLS with PSK.  Because that's ever so much
easier than using nasty certs.

  That isn't something we should encourage.  It may be worth just forbidding
it.

  Alan DeKok.

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 19 Sep 2019 09:17:44 +0000

> From: Jim Schaad <[email-masked]>
> Sent: 19 September 2019 07:28
> To: 'Alan DeKok' <[email-masked]>; Owen Friel (ofriel)
> <[email-masked]>
> Cc: [email-masked]; 'EMU WG' <[email-masked]>
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> However my issues have nothing to do with how things are implemented
> and more to do with the security properties of the EAP method.
> 
> When you use certificates, there is no leakage of who the client is as this is
> encrypted by TLS.  When you use a restore session ticket, it is possible to limit
> the number of times that the ticket can be used (for example once).
> The PSK identity is public and unprotected so it can be used to track.  If one is
> using PSK for the purpose of authentication then that value will always be
> visible to intermediate parties for the purpose of tracking.
> This can be slightly mitigated by using restore session tickets with PSK, but
> you are going to send that PSK identifier over the wire many times.

The IoT use case is to use the PSK one time for authentication during bootstrapping, then get credentialed, and thereafter use a certificate for subsequent EAP authentications. The bootstrap PSK enables proof of possession i.e. the thing will only bootstrap against a network that knows its PSK.

> Encrypt the first two items using the SIV.  You can then have multiple keys for
> decryption.  One for PSKs and a resolving one for session tickets.  If the
> identifier does not decrypt then you reject.  Otherwise you look at the date
> information and the index in the table for the secret information.
> 
> It is even possible to play games with AAD to do things like scope the tickets
> up front - if you put in the name/address of the NAS then you have a
> found then check the NewSessionTickets table.
> 
> identities?  i.e. I don't control OpenSSL.  From what I see, TLS 1.3 resumption
> means that OpenSSLL will choose whatever PSK identity it deems fit.
> 
> d1fa4c
>   If that really is the guidance, then this should also be called out in the draft.
> PSK identities MUST be long (ideally 32 octets or more), and MUST be
> generated from a CSPRNG.
> 
> If "end users" shouldn't be doing this, the draft also needs to call that out.
> 
> > Well, more precisely, the PSK identity is visible in the ClientHello,
> > not
> the actual PSK of course.
> 
>   Sure.
> 
>   Allowing PSK means that the draft should likely say "end users MUST NOT
> be using TLS-PSK".  Or maybe "TLS-PSK MUST be used only where systems
> can be automatically provisioned with long binary data for both PSK identity
> and PSK itself".  Or even "PSK identities and/or passwords that are composed

---

From: John Mattsson <[email-masked]>
Date: Thu, 19 Sep 2019 10:04:17 +0000

I am starting to come down on the side the EAP-TLS PSK should be specified.

- I think EAP-PSK should be phased out like all other methods not giving PFS.
- The security of the Dragonfly handshake used in EAP-PWD (and WPA3) seems quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked into the details.

- An EAP password method for the future should likely use the PAKE that CFRG will soon standardize.
- EAP methods should in the future support some PQC key exchange.

TLS will very likely get support for both the CFRG PAKE and PQC key exchange algorithms. I am not sure the EAP group want to spend time updating either EAP-PSK or ESP-PWD. Unless there are other benefits with EAP-PSK or EAP-PWD, I think standardizing EAP-TLS PSK makes a lot of sense.

I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless IETF thinks PSK and passwords should not be used (which does certainly not seem to be the case as TLS 1.3 is including PSK and CFRG is standardizing password based AKE) I think that EMU should make some PSK and password based method Standards Track. At the moment EAP-TLS 1.3 looks like the best choice.

> and more to do with the security properties of the EAP method.

If that is seen as a problem, standardizing a separate Type-Code for EAP-TLS with PSK authentication would solve the problem.

/John

-----Original Message-----
From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thursday, 19 September 2019 at 11:17
To: Jim Schaad <[email-masked]>, 'Alan DeKok' <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, 'EMU WG' <[email-masked]>
Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]>
Resent to: John Mattsson <[email-masked]>, <[email-masked]>
Resent date: Thursday, 19 September 2019 at 11:17

    
    
    > https://protect2.fireeye.com/url?k=fa7cdbfa-a6f60f3b-fa7c9b61-863d9bcb726f-0570ce4a3462cb4b&q=1&u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fblob%2F558ea84743918f7a93bfbfc259f86a
    > d1fa4c

---

From: "Owen Friel (ofriel)" <[email-masked]>
Date: Thu, 19 Sep 2019 11:20:07 +0000

> From: John Mattsson <[email-masked]>
> Sent: 19 September 2019 11:04
> To: Owen Friel (ofriel) <[email-masked]>; Jim Schaad
> <[email-masked]>; 'Alan DeKok' <[email-masked]>
> - The security of the Dragonfly handshake used in EAP-PWD (and WPA3)
> seems quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked
> into the details.
> 
> TLS will very likely get support for both the CFRG PAKE and PQC key
> exchange algorithms. I am not sure the EAP group want to spend time
> updating either EAP-PSK or ESP-PWD. Unless there are other benefits with
> EAP-PSK or EAP-PWD, I think standardizing EAP-TLS PSK makes a lot of sense.

Right, we have already started a couple of drafts along these lines, but are in a holding pattern now until CFRG are done:

https://tools.ietf.org/html/draft-barnes-tls-pake-04
https://tools.ietf.org/html/draft-sullivan-tls-opaque-00

> 
> I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless
> IETF thinks PSK and passwords should not be used (which does certainly not
> seem to be the case as TLS 1.3 is including PSK and CFRG is standardizing
> password based AKE) I think that EMU should make some PSK and password
> based method Standards Track. At the moment EAP-TLS 1.3 looks like the
> best choice.
> 

Additionally, we have had early discussions about updating TEAP RFC7170 to explicitly handle TLS 1.3, these updates could possibly be incorporated into https://tools.ietf.org/html/draft-lear-eap-teap-brski-04 , which is more and more looking like a general TEAP extensions / update draft, not a BRSKI specific draft.

And FYI, some movement has been made on TEAP with experimental support added to wpa_supplicant https://w1.fi/cgit/hostap/plain/wpa_supplicant/ChangeLog 

> If that is seen as a problem, standardizing a separate Type-Code for EAP-TLS
> with PSK authentication would solve the problem.
> 
> /John
> 
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent
> from: <[email-masked]> Resent to: John Mattsson
> <[email-masked]>, <[email-masked]> Resent date:
> Thursday, 19 September 2019 at 11:17
> 
> 
> 
> is
> one is
> but
>     The IoT use case is to use the PSK one time for authentication during
> bootstrapping, then get credentialed, and thereafter use a certificate for
> subsequent EAP authentications. The bootstrap PSK enables proof of
> possession i.e. the thing will only bootstrap against a network that knows its
> PSK.
> 
>     >
>     >
> tickets
>     > > Giving some implementation guidance seems appropriate here.
> Naively,
>     > > one
> is
> resumption
>     > https://protect2.fireeye.com/url?k=fa7cdbfa-a6f60f3b-fa7c9b61-
> 863d9bcb726f-
> 0570ce4a3462cb4b&q=1&u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fop
> enssl%2Fblob%2F558ea84743918f7a93bfbfc259f86a
>     > d1fa4c
> draft.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 19 Sep 2019 09:36:28 -0400

> - I think EAP-PSK should be phased out like all other methods not giving PFS.

  EAP-TLS using PSK has worse security properties than EAP-PSK, I think.

> - The security of the Dragonfly handshake used in EAP-PWD (and WPA3) seems quite shaky ( https://eprint.iacr.org/2019/383 ), but I have not looked into the details.

  Yes.  There are updates coming.

  EAP-PWD is widely deployed and is widely used.  Given it's simplicity, I recommend using it where simple name / password authentication is required.

> TLS will very likely get support for both the CFRG PAKE and PQC key exchange algorithms. I am not sure the EAP group want to spend time updating either EAP-PSK or ESP-PWD. Unless there are other be…

  It's not clear to me how EAP-TLS PSK is *better* than EAP-PWD.

> I also note that, EAP-PSK is experimental and EAP-PWD is informal. Unless IETF thinks PSK and passwords should not be used (which does certainly not seem to be the case as TLS 1.3 is including PSK…

  PEAP is informational.  EAP-TTLS is informational.  Yet both are widely used.  The document status is largely a byproduct of the IETF process.  I think we should take into account what people *do* with EAP methods.

  In this case, people have voted with their feet.  EAP-PWD, PEAP, and EAP-TTLS are widely deployed.  They all support some form of name / password authentication.  PEAP and EAP-TTLS also include support for anonymous outer identities, which is impossible with EAP-TLS PSK.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 19 Sep 2019 09:39:20 -0400

> more to do with the security properties of the EAP method.

  I'm leaning that way myself.  I'm not opposed in principle, but it looks like other options have better properties.

> but you are going to send that PSK identifier over the wire many times.

  i.e. the only secure way to use PSK is one-time authentication, as per Owen's IoT use-case.

  If we do allow it, there's just no question that people will abuse it.  That for me is a strong reason to forbid it.

  Alan DeKok.

---

From: John Mattsson <[email-masked]>
Date: Fri, 20 Sep 2019 10:41:53 +0000

Hi Alan,

I added references to RFC 8446 Section 8.1, and 8.2, and 4.2.11. Agree that they are good to point out.

I am not sure about the other suggestions, I am hesitant to discuss anything detailed about TLS 1.3 that does not have a specific connection to EAP-TLS or are useful for users of EAP-TLS. My feeling is that adding some extension, but not other would be even more confusing. The diagrams are there to show the message flows, which have a strong connection to the EAP state machine. For other details I think implementors have to read RFC 8466.

/John

-----Original Message-----
From: Alan DeKok <[email-masked]>
Date: Wednesday, 18 September 2019 at 15:21
To: "[email-masked]" <[email-masked]>, EMU WG <[email-masked]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[email-masked]>
Resent to: John Mattsson <[email-masked]>, <[email-masked]>
Resent date: Wednesday, 18 September 2019 at 15:21

    
    
      Alan DeKok.