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

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

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

> -----Original Message-----
> From: Emu <[e-mail]> On Behalf Of Owen Friel (ofriel)
> Sent: 18 September 2019 22:42
> To: Alan DeKok <[e-mail]>; John Mattsson
> <[e-mail]>
> Cc: [e-mail]; EMU WG <[e-mail]>
> Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> 
> 
> 
> > -----Original Message-----
> > From: Alan DeKok <[e-mail]>
> > Sent: 18 September 2019 14:40
> > To: John Mattsson <[e-mail]>
> > Cc: Owen Friel (ofriel) <[e-mail]>; draft-ietf-emu-eap-
> > [e-mail]; EMU WG <[e-mail]>
> > Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
> >
> >
> >
> > > On Sep 18, 2019, at 9:21 AM, John Mattsson
> > <[e-mail]> 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.
> 
> 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.
> >
> >   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).
> 
> 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 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.
> 
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu