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

[John Mattsson <[e-mail]>]

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.

Jim wrote:
> 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)" <[e-mail]>
Date: Thursday, 19 September 2019 at 11:17
To: Jim Schaad <[e-mail]>, 'Alan DeKok' <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, 'EMU WG' <[e-mail]>
Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
Resent from: <[e-mail]>
Resent to: John Mattsson <[e-mail]>, <[e-mail]>
Resent date: Thursday, 19 September 2019 at 11:17

    
    
    > -----Original Message-----
    > From: Jim Schaad <[e-mail]>
    > Sent: 19 September 2019 07:28
    > To: 'Alan DeKok' <[e-mail]>; Owen Friel (ofriel)
    > <[e-mail]>
    > Cc: [e-mail]; 'EMU WG' <[e-mail]>
    > Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
    > 
    > 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.
    
    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.
    
    > 
    > 
    > 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 <[e-mail]> On Behalf Of Alan DeKok
    > Sent: Wednesday, September 18, 2019 2:59 PM
    > To: Owen Friel (ofriel) <[e-mail]>
    > Cc: [e-mail]; EMU WG <[e-mail]>
    > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
    > 
    > On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel) <[e-mail]> 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://protect2.fireeye.com/url?k=fa7cdbfa-a6f60f3b-fa7c9b61-863d9bcb726f-0570ce4a3462cb4b&q=1&u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fblob%2F558ea84743918f7a93bfbfc259f86a
    > d1fa4c
    > 8de9/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.
    > 
    > > 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:
    > > ...
    > > 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.
    > 
    > _______________________________________________
    > Emu mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/emu