> -----Original Message-----
> From: John Mattsson <john.matts...@ericsson.com>
> Sent: 19 September 2019 11:04
> To: Owen Friel (ofriel) <ofr...@cisco.com>; Jim Schaad
> <i...@augustcellars.com>; 'Alan DeKok' <al...@deployingradius.com>
> Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' <emu@ietf.org>
> 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)" <ofr...@cisco.com>
> Date: Thursday, 19 September 2019 at 11:17
> To: Jim Schaad <i...@augustcellars.com>, 'Alan DeKok'
> <al...@deployingradius.com>
> Cc: "draft-ietf-emu-eap-tl...@ietf.org" <draft-ietf-emu-eap-
> tl...@ietf.org>, 'EMU WG' <emu@ietf.org>
> Subject: RE: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13 Resent
> from: <alias-boun...@ietf.org> Resent to: John Mattsson
> <john.matts...@ericsson.com>, <mo...@piuha.net> Resent date:
> Thursday, 19 September 2019 at 11:17
>
>
>
> > -----Original Message-----
> > From: Jim Schaad <i...@augustcellars.com>
> > Sent: 19 September 2019 07:28
> > To: 'Alan DeKok' <al...@deployingradius.com>; Owen Friel (ofriel)
> > <ofr...@cisco.com>
> > Cc: draft-ietf-emu-eap-tl...@ietf.org; 'EMU WG' <emu@ietf.org>
> > 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 <emu-boun...@ietf.org> On Behalf Of Alan DeKok
> > Sent: Wednesday, September 18, 2019 2:59 PM
> > To: Owen Friel (ofriel) <ofr...@cisco.com>
> > Cc: draft-ietf-emu-eap-tl...@ietf.org; EMU WG <emu@ietf.org>
> > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> > On Sep 18, 2019, at 5:42 PM, Owen Friel (ofriel) <ofr...@cisco.com>
> 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
> > Emu@ietf.org
> > https://www.ietf.org/mailman/listinfo/emu
>
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
