Document: draft-arkko-eap-aka-kdf-05.txt Reviewer: Miguel Garcia 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.