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:
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 PROTECTED]>
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
