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

["Owen Friel (ofriel)" <[e-mail]>]

> -----Original Message-----
> From: John Mattsson <[e-mail]>
> Sent: 19 September 2019 11:04
> To: Owen Friel (ofriel) <[e-mail]>; Jim Schaad
> <[e-mail]>; 'Alan DeKok' <[e-mail]>
> Cc: [e-mail]; 'EMU WG' <[e-mail]>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 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.

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 


> 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]" <draft-ietf-emu-eap-
> [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%2Fop
> enssl%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
> 
>