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

[John Mattsson <[e-mail]>]

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

/John

-----Original Message-----
From: Alan DeKok <[e-mail]>
Date: Wednesday, 18 September 2019 at 15:07
To: "Owen Friel (ofriel)" <[e-mail]>
Cc: John Mattsson <[e-mail]>, "[e-mail]" <[e-mail]>, EMU WG <[e-mail]>
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

    On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel) <[e-mail]> wrote:
    > 
    >> 
    >>  Which means that if PSK was allowed, the server can't look at the packets to
    >> distinguish resumption from "raw" PSK.  Instead, the server has to look at it's
    >> resumption cache which may be in a DB.
    > 
    > The server can use the PskIdentity in the PreSharedKeyExtension to differentiate between an offline PSK used for authentication vs. a PSK established via NewSessionTicket.
    
      Please define "use".  As an implementor, I can't implement "my code USES a field".  I need to know what the code *does* with it.
    
      How does the code differentiate between PSK identities?  Are the identity formats different?  If so, how and why?
    
      What prevents a malicious attacker from "using" a format which matches an identity coming from NewSessionTicket?
    
      My understanding is that the code *cannot* make any decisions simply by looking at the PSK identity field.  Instead, it has to look at the resumption cache to see if a given PSK matches a cached one.  Or maybe the code looks in a DB to see if the given PSK is a real "end-user" PSK in the DB.
    
      Simply waving your hands and saying it "uses" a field is unhelpful.  Please give substantive feedback and/or advice about what the code *does*.
    
      Alan DeKok.