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

[Alan DeKok <[e-mail]>]

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

  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.