AD Review draft-ietf-emu-aka-pfs-10
Thanks for the clear document and the extensive Security Considerations.
But also, thanks for seeing a real world problem (compromised long term
secrets) and thinking about how to reduce the impact of these observed
attacks. This is great work!
My only substantive comment is about K_encr and K_auth not being
protected by the ECDHE addition. If I understand it correctly, this is
done to ensure backwards compatibility with equipment that does not yet
support these. And that these values are only used for the EAP-AKA'
channel itself, and all other key derivations used for like packet
encryption is done via the MSK and EMSK values, which do have ECDHE
protection. Perhaps it is worth making that a little more clear.
Another consideration which might have been made, but cannot be read from
the document is that there is no "pinning" when seeing ECDHE once, to
then always insist on requiring it in the future. I assume this might not
work with equipment or connection changes happen in the infrastructure.
Nits:
The first use of RECOMMENDED comes before the RFC2119 information on
what it means.
It might be useful to explain EAP-AKA vs EAP-AKA' - wasn't entirely clear to
me this was not a typo at first.
have gained much scrutiny
I think you receive scrutiny, not gain it?
They are a high-value target
s/They/These
panacea
find a phrasing less obscure to describe this ?
Expand first use of UICC ?
the 3GPP specifications
Turn into a real reference?
For X25519/Curve25519
Elsewhere, this is referred to as X25519, and Curve25519 is only used
as a name, not the DHE function, which is only referred to as X25519?
Maybe just call it X25519 here?
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
