> -----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/558ea84743918f7a93bfbfc259f86ad1fa4c8de9/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
