Subject: [Gen-art] Gen-ART review of IETF LC draft-arkko-eap-aka-kdf-05.txt

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 23 Sep 2008 16:59:05 +0200

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-arkko-eap-aka-kdf-05.txt
Reviewer: Miguel Garcia <[email-masked]>
Review Date: 2008-09-23
IETF LC End Date: 2008-10-13

Summary: The document is almost ready, but there are a couple of minor 
issues that should be addressed before publication.

Comments:

- Figure 1, the first box in the server. I think there is a missing 
indication to an attribute name. The text reads "AND and AUTN are sent 
as AT_RAND and AT_AUTN attributes, whereas the network name is 
transported in the attribute". I think it should read: "AND and AUTN are 
sent as AT_RAND and AT_AUTN attributes, whereas the network name is 
      transported in the AT_KDF_INPUT attribute"
                    ^^^^^^^^^^^^

- Section 3.1, the first paragraph on page 7. The text reads: "If the 
policy indicates that it can continue, the peer SHOULD log a warning 
message or display it to the user." Honestly, it is hard to find a 
justification of the SHOULD strength here, when the action does not 
affect protocol interoperability and it takes in the same node. My point 
is that the normative text of the standard should focus on protocol 
interoperability, not on the details of the implementation. I would 
accept a non-capitalized verb though.

- Section 3.1, second paragraph. The text reads: "The Network Name field 
contains an octet string.  This string MUST be constructed as specified 
in [3GPP.23.003].  This is done in a manner that is specific to a 
particular access technology". I have a problem because I don't know 
which field 23.003 I have to use from the multiple collection of fields 
specified there. I am assuming you are referring to the "Home network 
domain name", is this correct? I think you need to be much more precise 
and specify exactly which field of 23.003 the implementor have to use 
and place in the Network Name.

Then, it is not totally clear what "is done in a manner that is specific 
to the particular access technology". I guess it is not referring to the 
"octet string". Well, I am familiar with 23.003 and still I have my 
doubts of what this text is all about. I guess you should try to clarify 
what you want to say and perhaps point to a given section in 23.003 or 
provide some examples.

- Section 3.2, page 8. I find a bit confusing this text: "The first of 
these attributes represents the desired function and the other ones are 
acceptable alternatives, the most desired alternative being the second 
attribute". Is the distinction between "desired function" and 
"acceptable alternatives" needed at this stage? If not, the text could 
just read: "These attributes represent the desired functions ordered by 
preference, the most preferred function being the first attribute".

- Section 6 (IANA Considerations) was unclear to me, because the 
registry names where IANA has to operate are not named. For example, the 
first paragraph, is this the "Method Types registry in the Extensible 
Authentication Protocol (EAP) Registry" ?

Second and following paragraphs: I think this one is easier, I guess 
this is the "Subtypes registry of the EAP-AKA and EAP-SIM Parameters 
registry". But I was confused, because the draft talks about "message 
Subtypes", but I didn't find "message" in the IANA registry.

Please consider splitting this section into two subsections, each one 
devoted to a different registry. You will make IANA's life easier.

Nits:

- Expand terms a first occurrence. This includes: NAI, 3GPP, AMF, LTE, eHRPD

- Section 1, 4th paragraph, add a reference to SHA-256.

- Section 1, 6 paragraph does not mention Appendix B.

- Section 2. The text is a trimmed down and customized version of the 
boilerplate included in RFC 2119. As a consequence, idnits complains. I 
recommend to replace it by the standard boilerplate.

- Section 3, page 4, last bullet point, add references to SHA-256 and a 
new informative reference to SHA-1.

- Section 3.2, las paragraph on page 8. There is something that does not 
match in the sentence. Perhaps there is a missing "the":
    When the peer receives the new EAP-Request/AKA'-Challenge message, it
    MUST check that the requested change, and only the requested change
                    ^^^^
    occurred in the list of AT_KDF attributes.

- Section 3.3, page 9, the text reads:
       In particular, implementations MAY set
       the so called AMF separation bit to either 0 or 1 in the AKA
       algorithm.

Well, a "MAY" indicates an option of doing something (or not doing it). 
But if a bit can only take the values 0 or 1, as stated, I don't 
understand what are the remaining options for this bit. Perhaps it can 
take the value 0,5 ;-) ? Perhaps the text should just simply say: "... 
MAY set the AMF separation bit to 1 in the AKA algorithm". Then the 
"MAY" makes sense, because I have an option of setting it to 0.

- Add a reference to SHA-1 in Section 3.4.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain
_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Jari Arkko <[email-masked]>
Date: Tue, 23 Sep 2008 18:32:51 +0300

Thanks for your review. Based on a quick look at the comments I agree 
with all of them and they will be addressed in the next revision.

On the use of SHOULD for the log/warn issue -- this isn't an interop 
issue, its a security issue. That was the justification for the use of 
SHOULD. I do not feel strongly about it, however.

Jari

Miguel A. Garcia wrote:
> transported in the attribute". I think it should read: "AND and AUTN 
> are sent as AT_RAND and AT_AUTN attributes, whereas the network name 
> is      transported in the AT_KDF_INPUT attribute"
>                    ^^^^^^^^^^^^
>
> affect protocol interoperability and it takes in the same node. My 
> point is that the normative text of the standard should focus on 
> protocol interoperability, not on the details of the implementation. I 
> would accept a non-capitalized verb though.
>
> - Section 3.1, second paragraph. The text reads: "The Network Name 
> field contains an octet string.  This string MUST be constructed as 
> specified in [3GPP.23.003].  This is done in a manner that is specific 
> to a particular access technology". I have a problem because I don't 
> know which field 23.003 I have to use from the multiple collection of 
> fields specified there. I am assuming you are referring to the "Home 
> network domain name", is this correct? I think you need to be much 
> more precise and specify exactly which field of 23.003 the implementor 
> have to use and place in the Network Name.
>
> Then, it is not totally clear what "is done in a manner that is 
> specific to the particular access technology". I guess it is not 
> referring to the "octet string". Well, I am familiar with 23.003 and 
> still I have my doubts of what this text is all about. I guess you 
> should try to clarify what you want to say and perhaps point to a 
> given section in 23.003 or provide some examples.
>
> these attributes represents the desired function and the other ones 
> are acceptable alternatives, the most desired alternative being the 
> second attribute". Is the distinction between "desired function" and 
> just read: "These attributes represent the desired functions ordered 
> by preference, the most preferred function being the first attribute".
>
> registry names where IANA has to operate are not named. For example, 
> the first paragraph, is this the "Method Types registry in the 
> Extensible Authentication Protocol (EAP) Registry" ?
>
> boilerplate included in RFC 2119. As a consequence, idnits complains. 
> I recommend to replace it by the standard boilerplate.
>
> - Section 3, page 4, last bullet point, add references to SHA-256 and 
> a new informative reference to SHA-1.
>
> - Section 3.2, las paragraph on page 8. There is something that does 
> not match in the sentence. Perhaps there is a missing "the":
> Well, a "MAY" indicates an option of doing something (or not doing 
> it). But if a bit can only take the values 0 or 1, as stated, I don't

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 24 Sep 2008 08:18:35 +0200

Hi Jari:

On the use of SHOULD for a non-protocol action... I am not going to make 
  big think about it, but my interpretation of RFC 2119 makes me feel 
better if we restrict the use of capitalize words for protocol actions. 
I don't think the capital SHOULD brings more security than a lowercase 
should. Anyway, this is up to you.

/Miguel