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.


-----Original Message-----
From: Alan DeKok <al...@deployingradius.com>
Date: Wednesday, 18 September 2019 at 15:07
To: "Owen Friel (ofriel)" <ofr...@cisco.com>
Cc: John Mattsson <john.matts...@ericsson.com>, 
"draft-ietf-emu-eap-tl...@ietf.org" <draft-ietf-emu-eap-tl...@ietf.org>, EMU WG 
Subject: Re: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

    On Sep 18, 2019, at 8:45 AM, Owen Friel (ofriel) <ofr...@cisco.com> 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.

Emu mailing list

Reply via email to