search

emu-wg / eap-aka-pfs

Perfect-Forward Secrecy for EAP-AKA' PFS
0 stars 2 forks source link

Comments by Meiling Cheng #43

Closed emanjon closed 1 year ago

emanjon commented 1 year ago

https://mailarchive.ietf.org/arch/msg/emu/yDv2xIEKxZ1TfzW7lptOzKkx_F0/

Hi, I have reviewed the draft, it seems that asymmetric negotiation is used to achieve PFS, But I didn't understand how it was realized. MK = PRF'(IK'|CK',"EAP-AKA'"|Identity) MK_ECDHE = PRF'(IK'|CK'|SHARED_SECRET,"EAP-AKA' FS"|Identity) K_encr = MK[0..127] K_aut = MK[128..383] K_re = MK_ECDHE[0..255] MSK = MK_ECDHE[256..767] EMSK = MK_ECDHE[768..1279]

  1. ECDHE's private key is not reflected in the K_encr,
    MSK used SHARED_SECRET(I understand it is the private key in a pair of keys), Ensure PFS by mixing private key? The names of SHARED SECRET and long-term shared secrets on the SIM card should be distinguished. 2.TLS1.3 support secp256r1, secp384r1, secp521r1，x25519， x448, why the draft only x25519?

Best, Meiling

knorrman commented 1 year ago

Hi!

Thanks for reviewing the draft.

On your first question: Can you elaborate on what you mean by that the private key is not reflected in K_encr?

The SHARED_SECRET is the g^xy from the ephemeral Diffie-Hellman exchange. This is maybe not entirely clear from the text, I agree. And yes, mixing in g^xy is what enables PFS for the MSK (and the other keys), compared to a straight EAP-AKA' exchange.

I have a pull request on patches to more clearly distinguish the name of the DH shared secret from the long-term key in the smart card.

BR Karl

emanjon commented 1 year ago

The comment above is also captured in Paul's AD review.

Meiling Cheng also commented that the text on future addition of PQC algorithms should be modified. We should not assume that not additional changes are needed. That is FFS

emanjon commented 1 year ago

I made a commit stating that introducing KEMs might be more complex that the current draft indicated.

Closing this as the remaining change to explain why the ECDHE secret is not used for all key derivation is captured by #47