Russ,
Thanks again for your comments. A new version has been posted, with changes to
e.g. the abstract and the introduction. Can you check if you like these better,
and if any further changes come to mind? Thanks.
Jari
> On 14 Nov 2018, at 6.06, Russ Housley wrote:
>
> I agreed to review this document at IETF 103. Here are my comments.
>
> Document: draft-ietf-emu-rfc5448bis-03
> Reviewer: Russ Housley
> Review Date: 2018-11-13
>
> Summary: Almost Ready
>
>
> Major Concerns:
>
> The Abstract is essentially unchanged from RFC 5448. I think it would
> be better to provide the history of AKA and AKA' in a sentence or two
> and then tell the big changes that appear here. I found the part about
> SHA-1 especially concerning until I realized that was left over from the
> RFC 5448 Abstract text.
>
> I think the Introduction should be updated to provide a perspective for
> a new implementer. I suggest something like this:
> - 3GPP uses AKA' natively and as an EAP method.
> - EAP-AKA originally defined in [RFC4187]
> - EAP-AKA' defined in [RFC5448], and uses KDF in [TS-3GPP.33.402]
> - This update supports identifiers needed for 5G
>-- This version of the EAP-AKA' specification obsoletes RFC 5448
>-- List of the changes made by this update
> - Negotiation of the various versions
>
> Section 3.2 says:
>
> AT_KDF
>
> This is set to 24.
>
> And, then Section 3.3 says:
>
> AT_KDF set to 1
>
> The second one is shorthand for the KDF identifier carried in the
> attribute. I think that you should not use this shorthand. I
> stumbled on it when reading. I suggest:
>
> AT_KDF parameter has the value 1
>
> Section 5.3 says:
>
> Given the choice between these two types of identifiers, two areas
> need further specification in EAP-AKA' to ensure that different
> implementations understand each other and stay interoperable:
>
> This should be reworded. These do not need future specification.
> Those details are in the document. I think it would be better to say:
>
> Given the choice between these two types of identifiers, EAP-AKA'
> ensure interoperability by:
>
>
> Minor Concerns:
>
> Section 3: s/EAP-AKA' is a new EAP method/EAP-AKA' is an EAP method/
>
> Section 3 does not seem to be different from RFC 5448. Would it be
> better to list the changes from RFC 4187 (AKA to AKA') and then the
> changes from RFC 5448 (AKA' to this update)?
>
>
> Nits:
>
> The document uses "key generation" and "key derivation". If they are
> different, please add an explanation somewhere. If they are the same,
> please use one term throughout.
>
> The document uses "byte" and "octet". Please use one term throughout.
>
> ___
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
