Draft: draft-ietf-emu-aka-pfs-latest

Commentary: I 'm flying later today and unsure about how much I can do on Monday . I will need to deploy this change and submit the draft . 
 ATKDF carries the legacy KDF value for those EAP peers that can not or do not want to use this extension . Gives the impression that ATKDF is ignored when ATKDFFS is used ... Gives the impression that they are used together ... The Specification is clear on how to derive keys when ATKDF in { 1 } and ATKDF_FS in { 1,2 } but does not give any descriptions on how other combinations are supposed to work . 
 I do n't know how this is supposed to work but there are several options for how they are used together . is completely ignored when ATKDFFS is used . determines how to derive MK ,  ,   determines how to derive MKECDHE ,  , MSK , EMSK but the PRF used in deriving MKECDHE is determined by ATKDF . 
  that this need to be specified is . If someone specifies ATKDF = 2 . How would that work with EAP - AKA ' FS If someone wants to specify a PQC KEM for ATKDF_FS . Exactly what should they specify . 
 Ok this seems like a fair issues . Thanks for spotting this . 
 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 . 
 I am fine with b. The PR should make clear that this updates RFC 9048 with this new requirement . 
 Ok 
 A PR has been proposed : 
 Solved per the PR so that I can submit the draft ( may not be able to work on Monday due to travel ) .
The AT_KDF_FS indicates the used or desired forward secrecy key
generation function, if the Forward Secrecy extension is taken into
use.  It will also at the same time indicate the used or desired
ECDHE group.  A new attribute is needed to carry this information, as
AT_KDF carries the legacy KDF value which is still used together with
the forward secrecy KDF value.  The legacy KDF value is also used by
those EAP peers that cannot or do not want to use this extension.
The AT_KDF_FS indicates the used or desired forward secrecy key
generation function, if the Forward Secrecy extension is taken into
use.  It will also at the same time indicate the used or desired
ECDHE group.  A new attribute is needed to carry this information, as
AT_KDF carries the basic KDF value which is still used together with
the forward secrecy KDF value.  The basic KDF value is also used by
those EAP peers that cannot or do not want to use this extension.
This specification only specifies the behaviour relating to the
following combinations of basic KDF values and forward secrecy KDF
values: The basic KDF value in AT_KDF is 1, as specified in RFC5448
and RFC9048, and the forward secrecy KDF values in AT_KDF_FS are 1 or
2, as specified below and in kdf2.
Any future specifications that add either new basic KDF or new
forward secrecy KDF values need to specify how they are treated and
what combinations are allowed.  This requirement is an update to how
RFC5448 and RFC9048 may be extended in the future.