Subject: [Emu] I-D Action: draft-ietf-emu-rfc5448bis-00.txt

From: [email-masked]
Date: Mon, 25 Jun 2018 08:18:40 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the EAP Method Update WG of the IETF.

        Title           : Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')
        Authors         : Jari Arkko
                          Vesa Lehtovirta
                          Vesa Torvinen
                          Pasi Eronen
	Filename        : draft-ietf-emu-rfc5448bis-00.txt
	Pages           : 33
	Date            : 2018-06-24

Abstract:
   This specification defines a new EAP method, EAP-AKA', a small
   revision of the EAP-AKA method.  The change is a new key derivation
   function that binds the keys derived within the method to the name of
   the access network.  The new key derivation mechanism has been
   defined in the 3rd Generation Partnership Project (3GPP).  This
   specification allows its use in EAP in an interoperable manner.  In
   addition, EAP-AKA' employs SHA-256 instead of SHA-1.

   This specification also updates RFC 4187 EAP-AKA to prevent bidding
   down attacks from EAP-AKA'.

   This version of the EAP-AKA' specification updates a reference to
   constructing one field in the protocol, so that EAP-AKA' becomes
   compatible with 5G deployments as well.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-rfc5448bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-emu-rfc5448bis-00
https://datatracker.ietf.org/doc/html/draft-ietf-emu-rfc5448bis-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: John Mattsson <[email-masked]>
Date: Tue, 26 Jun 2018 19:32:48 +0000

Hi,

This looks very good, I looked through the document quickly and have some mostly editorial comments.

- I think the document still need to have the first-page header "Updates: 4187". My understanding of Obsoletes is that it replaces the older document and that the new document can be used alone without reference to the older document.

- Section 1 "is an update to RFC 5448."
I think the word update is a bit confusing as the documents obsoletes RFC 5448.

- "2008 version" and "5G version", I think it is better to talk about Releases here, i.e. Release 8 and 15. Also "that reference"?. Suggestion:

"RFC 5448 referred to the Release 8 version of [TS-3GPP.24.302] and this update	 refers to the the first 5G version, Release 15."

- "reaching their final Release 15 status"
What is meant with final here? 3GPP are stable at some point, but the specifications in a release are never final....

- Section 2 should follow RFC 8174 and say:

     "The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
      appear in all capitals, as shown here."

- RFC 5226 has been obsoleted by RFC 8126
      
- [FIPS.180-2.2002] has been superseeded by FIPS 180-4

- As 23.501, 24.302, and 33.501 points to the Release 15 version, I think all the other 3GPP specifications 33.102, 33.402, etc. should refer to Rel-15 as well. The technical specifications in a Release are meant to be used together. 

- "[FIPS.180-1.1995]", this reference is not needed, SHA-1 is also defined (without changes) in FIPS 180-2, 180-3, and 180-4

- The third column in the table in Section 8.3 is not aligned.

Cheers,
John