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 <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
<emu@ietf.org>
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
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
