Subject: [Emu] draft-ietf-emu-rfc5448bis-03

From: Russ Housley <[email-masked]>
Date: Wed, 14 Nov 2018 00:06:19 -0500

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.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Nov 2018 06:10:44 +0100

Thanks for your review, Russ.

I will look carefully into your comments. But for starters, you make a good point about the abstract/introduction. And obviously the language used to refer to the AT_KDF attribute number vs. value needs to be precise. 

Jari