And one other draft of interest: https://tools.ietf.org/html/draft-ietf-tls-external-psk-importer-00
> -----Original Message----- > From: Emu <emu-boun...@ietf.org> On Behalf Of Owen Friel (ofriel) > Sent: 18 September 2019 22:42 > To: Alan DeKok <al...@deployingradius.com>; John Mattsson > <john.matts...@ericsson.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 > > > > > -----Original Message----- > > From: Alan DeKok <al...@deployingradius.com> > > Sent: 18 September 2019 14:40 > > To: John Mattsson <john.matts...@ericsson.com> > > Cc: Owen Friel (ofriel) <ofr...@cisco.com>; 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 9:21 AM, John Mattsson > > <john.matts...@ericsson.com> 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 > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
