Jouni,
It looks like draft-arkko-eap-aka-kdf-09.txt updates the RFC 4187
definition of AT_CHECKCODE by changing the length of Checkcode field to
be "0 or 32 bytes". This does not look correct since EAP-AKA continues
to use 20-byte Checkcode value and the same definition of the attribute
is shared by both EAP-AKA and EAP-AKA' (assuming I understood the draft
correctly). The updated version should include 20 bytes as a valid
length of the Checkcode field (i.e., something like "0, 20, or 32
bytes"). In addition, the following paragraph ("Second, the checkcode is
a hash value ..") should be modified to apply only for EAP-AKA' and only
when using AT_KDF Key Derivation Function value 1.
Thanks for your review.
I have thought about this issue today and came to the following
conclusion. The issue is about being clear where the new formats and
rules apply. They only apply to EAP-AKA', not EAP-AKA or EAP-SIM. It
would be possible to change the attribute type numbers and names as
well, but personally I find that unnecessary. So here's what I'd suggest:
In Section 3.4.2, change
OLD:
The AT_MAC attribute is changed as follows.
NEW:
When used within EAP-AKA', the AT_MAC attribute is changed as follows.
In Section 3.4.3, change
OLD:
The AT_CHECKCODE attribute is changed as follows.
NEW:
When used within EAP-AKA', the AT_CHECKCODE attribute is changed as
follows.
(We may get an OK from the 3GPP to approve this spec this week. However,
I have this change and another one (picture reformatting to fit it in
one page. The latter is hard to do in an RFC Editor note, so I guess
I'll submit a new version of the draft next week in any case.)
Jari
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
