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

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Oct 2008 00:42:20 +0300

Hello all,

I am revising eap-aka-kdf based on everyone's comments. I took most of 
the comments from you Miguel into account. Further discussion inline:

> - 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"
>                    ^^^^^^^^^^^^

Fixed.

> - 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.

I decided to keep the SHOULD. Remember that while this does not affect 
interoperability between the endpoints, it is an action that the spec 
recommends to be performed. Furthermore, the action is something that is 
visible outside the implementation (e.g., a syslog entry is created in 
some server somewhere).

I think Russ has had to deal with situations like this in the past, 
perhaps you have some advice for us? Russ, if you want me to change 
this, I will.

> - 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.

Ok. The reference has changed to 24.302, and the field is "access 
network identity". I have added this to my draft, but at this point 
24.302 lacks detail about the exact procedure. I don't have the latest 
rev from last week's meeting, however. I was promised that it should be 
ready after that meeting.

> 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.

I have changed the text, but the point is that the material is in 
24.302. And with me pointing to the right field name the reference part 
at least is done right.

> - 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".

Changed.

> - 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" ?

Fixed.

> 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.

Split.

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

Done.

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

Ok.

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

Fixed.

> - 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.

I was wondering about that. Fixed.

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

Ok.

> - 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.

Fixed.

> - 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.

I changed the language to say "may set ... to either 0 or 1 ....".

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

Done.

Jari

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Mon, 13 Oct 2008 10:11:16 +0200

Jari:

Everything looks fine for me. But now I have an additional question:

The draft says: The AT_KDF_INPUT attribute carries the the Access 
Network Identity and points to 24.302. The draft says that this 
attribute contains an octet string. However, 24.302 says that the Access 
Network Identity is UTF-8 encoded.

I don't think there is a discrepancy between both statements, since 
UTF-8 at the end of the day is an octet stream. But I would like you to 
verify that there is no discrepancy with 24.302.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain

---

From: Jari Arkko <[email-masked]>
Date: Mon, 13 Oct 2008 13:18:06 +0300

Ah, good catch. I'll see what I can do.

(I am also reviewing 24.302 and other specifications to make sure they 
are in alignment.)

Jari

Miguel A. Garcia wrote:
> attribute contains an octet string. However, 24.302 says that the 
> Access Network Identity is UTF-8 encoded.
>
> UTF-8 at the end of the day is an octet stream. But I would like you 
> to verify that there is no discrepancy with 24.302.
>
> /Miguel
>

---

From: Russ Housley <[email-masked]>
Date: Mon, 13 Oct 2008 10:19:31 -0400

Jari & Miguel:

>>- 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.
>
>I decided to keep the SHOULD. Remember that while this does not 
>affect interoperability between the endpoints, it is an action that 
>the spec recommends to be performed. Furthermore, the action is 
>something that is visible outside the implementation (e.g., a syslog 
>entry is created in some server somewhere).
>

I have no real good advice, and the 'or' in the sentence makes it 
harder of offer something.  What would the user do with this 
information if it was displayed?  What would the network operator do 
with this information if it was logged?  Since the 'or' means that 
neither one is consistently going to get the information, the answer 
is more difficult.

It certainly does not impact interoperability, so I do not consider 
it a shwstopper.

Russ