Relation and interactions betweeen AT_KDF and AT_KDF_FS are not defined.

emu-wg / eap-aka-pfs

Perfect-Forward Secrecy for EAP-AKA' PFS

0 stars 2 forks source link

Relation and interactions betweeen AT_KDF and AT_KDF_FS are not defined. #25

Closed emanjon closed 1 year ago

emanjon commented 2 years ago

AT_KDF carries the legacy KDF value for those EAP peers that cannot or do not want to use this extension. Gives the impression that AT_KDF is ignored when AT_KDF_FS is used...

When the FS Key Derivation Function field in the AT_KDF_FS attribute
is set to 1 and the Key Derivation Function field in the AT_KDF
attribute is also set to 1, the Master Key (MK) is derived as follows
below.

Gives the impression that they are used together...

The Specification is clear on how to derive keys when AT_KDF in {1} and AT_KDF_FS in {1,2} but does not give any descriptions on how other combinations are supposed to work.

emanjon commented 2 years ago

I don't know how this is supposed to work but there are several options for how they are used together.

AT_KDF is completely ignored when AT_KDF_FS is used.
AT_KDF determines how to derive MK, K_aut, K_re AT_KDF_FS determines how to derive MK_ECDHE, K_re, MSK, EMSK
Like 2. but the PRF used in deriving MK_ECDHE is determined by AT_KDF.

emanjon commented 2 years ago

Reasons that this need to be specified is.

If someone specifies AT_KDF = 2. How would that work with EAP-AKA' FS
If someone wants to specify a PQC KEM for AT_KDF_FS. Exactly what should they specify.

jariarkko commented 1 year ago

Ok this seems like a fair issues. Thanks for spotting this.

jariarkko commented 1 year ago

I see two options. Either we are (a) trying to be clever and split what impacts what (MK, K_aut) vs. everything else or (b) we only specify a specific combination (KDF=1 + FS=1 or 2) and explicitly say that future specs need to specify how new KDF or FS algorithms can be combined with others.

Both have some drawbacks ... not sure we always want to have the same split in option a. And option b leaves out a lot of room for future extensions to forget to do this.

Maybe go for option b?

I will try to make a PR.

emanjon commented 1 year ago

I am fine with b.

The PR should make clear that this updates RFC 9048 with this new requirement.

jariarkko commented 1 year ago

A PR has been proposed: https://github.com/emu-wg/eap-aka-pfs/pull/36

jariarkko commented 1 year ago

Solved per the PR so that I can submit the draft (may not be able to work on Monday due to travel).