> 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.
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). 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.
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.
> 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.
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
