Michael, Many thanks for your comments. I agree the document could use some restructuring and clarification. It's a result of cumulative revisioning, and we haven't really thought about the structure since the beginning.
It's very hard to structure the document so that you can understand everything by reading it once. I think we need to have a good overview section. It's not a good idea to duplicate the same information in several places of the document, so it may be hard to avoid referencing sections that follow the current section. > A1) please include real packet dumps, including encrypted data > with keys, to help people. We're planning to do that in appendix A. > A2) There is no per-attribute description/reference. > -> AT_VERSION_LIST for instance has no reference. ... > A4) The definitions of the attributes seems to be partially defined > only in the scenarios of sections 9-15. I would rather the > attributes were defined seperately from the messages in which > they are used. Otherwise, it appears that one has to > code per-message > marshalling/etc. It is hard to tell if this is true or not. > Most of the attributes can be used in a certain message only, but there are attributes like AT_MAC that are general. Maybe we should have a separate section for the attribute definitions, like for example RFC2865. That would make the message definitions simpler. > A3) paragraph 1 of 5.2. This conversation seems totally out of > place, and very confusing. OK. > A5) It was not at all obvious that the AT_MAC is a keyed operation. > The last sentence of 8.1 says so, but I missed it at > least twice, > thinking, but, it must be keyed, I remembered reading about it. > > Maybe this is just the way that I read the document. Yes, it is a keyed operation, as described in section 8.1. > A5b) Annex A/B might be a little more detailed. > In particular, I think that you have chosen G to be SHA1, but > I'm not particularly certain. > Nor do I understahe what "m" is, or what the "optional > user input" > is in this context. Please see other postings on the EAP mailing list about the PRF. > A6) split normative and informative references. OK. > A7) section 3, overview, para 3. > It seemed that this was the only place that the value > of the Start > subtype was clearly stated. In addition, all protocol numbers are stated in section 18 (IANA considerations). > A8) section 5.1, page 9, > > > In this case, the permanent username MUST be of the > format "1imsi". > > It took me awhile to understand that the thing in quotes is a > pattern, not a string. Please remove "", or use another > notation. OK > A9) section 5.1, page 9, para 4. > This seems really nebulous. > Do you mean it's hard to understand if you don't know about re-authentication and IMSI privacy, which are discussed in later sections? > A10) section 5.2, first paragraph. > It seems that you are putting the most complicated "gotcha" > at the beginning. At this point, I don't even know what you are > talking about yet! The "gotcha" is rationale for the feature. Maybe the first paragraph can be removed altogether. > A11) time-sequence diagrams. They are simply not useful to > me. They just > seem to take lots of space. > They are useful when there are more than two parties. > A12) section 5.1, 5.2 and 5.3 should have *NO* mention of > re-authentication. Please describe the base protocol first, > (including state machines), and then give the version that > supports re-authentication. I agree it should be easy to understand the protocol in a general level by reading the first sections. But I'm not sure if we really need to first specify the base protocol only and cut corners in the specification of the Start messages for example. > A13) section 5.3, page 15, para 7. > " A received AT_PERMANENT_ID_REQ does not necessarily > originate from " > > The advice given seems very complicated and very dubious to me. > I believe that this must come out from the client state machine. The "advice" could be removed from the base description (and even omitted from state machine if we have such a thing), and we could discuss protection against active attacks on anonymity separately. > A14) section 6. > Caveat: I read this much less carefully. > page 22, para 4: > > " > Re-authentication identities are one-time identities. If > the client > does not receive a new re-authentication identity, it MUST use > either the permanent identity or a pseudonym identity on the next > authentication to initiate full authentication. > " > > Given that the identity is involved in the AT_MACs, are there > any cryptographic restrictions on the one-time identities? The identities are involved in key derivations in order to get implicit integrity protection by "binding" the derived keys to the identity string. I'm not sure if I properly understand your question, but I don't think there are any restrictions on the identities. > > A15) section 7. basic format. > What if length == 0. Malformed packet. > Then what? The current draft (section 15) specifies silent discard as the default operation in error cases, but we're going to change this in response to Glen's comments. If the client encounters a malformed packet, it sends an EAP-Response/SIM/Client-Error, to which the server replies with EAP Failure. If the server encounters a malformed packet, it issues EAP Failure. > A16) section 7. 0/127, 128-255 as "skippable". > I recommend that you adopt the terminology from IKEv2. > The high bit is the "critical" bit (or in this case, the > "non-critical" bit). OK, that's another way to describe the same thing. > A17) section 8.2. AT_CHECKCODE. ...will be removed from the next version of EAP SIM. > A19) What if it is known that the encapsulator provides integrity > protection and privacy? I.e. IKEv2? You'll still have to use AT_MAC, but you don't have to use IMSI privacy. If the encapsulator provides fast reconnect, you don't have to use EAP/SIM's re-authentication. > > A20) section 10. > I'd like to see real numbers in the entire packet. > Hex dumps. > The code/id/Length/etc. break out seems to take way more white > space that it provides value. I think the hex dumps belong to the test vector section. The packets are not fixed length so hex dumps would be problematic except as examples. If we re-arrange the attributes to separate sections, then the descriptions of the messages will be shorter, but I think it is still useful to clearly state at least the Subtype and Code for each message. > A21) re: AT_NEXT_PSEUDONYM, and I guess identities in general. > What about UTF-8? Internationalization? Should we specify that all identities contain UTF-8 encoded ISO 10646 characters and refer to RFC2279? > A22) section 18. > This seems to be the only place that there is a table of > values. I guess that is okay, but I found it hard to find. > I'd like to see a table with brief explanations of each > attribue back in section 10 or earlier. Do you think a section with a separate subsection for each attribute would be good enough? For each message, the section that specifies the message can list the attributes that may, must and must not be included. > A24) Annex B. I found it to be clear as MUD. I guess I don't > code very often to FIPS documents, are they all so obtuse? > C code for this PRF would be welcome, along with test vectors. > When I get mine working, I'll be happy to contribute them. This NIST specification really is very hard to follow. I think that we need to have pseudo-code too. I posted some test vectors on the list which we can include. Best regards, Henry - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
