Draft: draft-clancy-eap-pax-08 Reviewer: Elwyn Davies [elwynd@googlemail.com] Review Date: Monday 8/7/2006 7:31 PM CST IETF LC Date: 8/8/2006 Summary: This document needs another editing pass. There appear to be significant technical issues. I also found the overview (primarily s2) very difficult to follow. The overview has not been written from the point of view of an uninformed reader and the ordering of topics is sometimes not the best that could be achieved. Issues: ===== s1; The protocol offers 'support for provisioning'. Provisioning what? Keys? Presumably the Authenticated Data Exchange is what is being talked about here. It would be good to connect the idea of provisioning and the ADE right at the beginning, and then explain what it is anticiapated using this for. s1.1: Remove the second sentence ("These words are often capitalized.") and ensure that all requirements words are capitalized as appropriate. You can't have some of them that imply requirments capitalized and others not. s1.2: Good idea to capitalize the words in the definitions that indicate the abbreviations in all cases (some are already done). CID =? Expand NAI. g - public Diffie-Hellman generator, typically 2.... 2 what??? 2 wombats, 2 bits, type 2. Please explain. Since PK is used in AK it would be sensible to define PK first. s1.2: RFC4282 doesn't impose any explicit restrictions on the length of an NAI (we assume the limited words used mean tat the CID has the fomr of an NAI). If I read the payload formats later correctly there is an implicit restriction on the length of an NAI because the length is encoded in two octets (just HOW it is encoded is not specified!) so we must assume that at longest it is 255 octets. This or any lesser restriction should be spelt out here (like if RADIUS was being used). Given that (according to RFC4282) DIAMETER allows much longer NAIs, it is sensible to constrain a new protocol with limits that are removed by use of DIAMETER instead of RADIUS? Also there ought to be some words about internationalization and whether we are expecting to carry only normalized NAIs. s2: It would be a good idea to explain how the system gets bootstrapped.. how the client and server are to share the initial AK. How the CID is created etc. s2,para 3: I guess the terminology g^X is reasonably well understood but I think it would be a good idea to explain what is going on in this paragraph a little for the security algorithm neophyte. Personally I don't think I could work out what to do from the words here. There may be a missing article here - maybe 'an elliptic...' and possibly a word order problem. Do you mean 'computed either modulo prime P or over an elliptic curve...'. From later it appears that this operation is usually intended to create 256 bits of random data. How are the 256 bits selected? s2, para 4 (also s1): The shorthand server-side public key is perhaps slightly ambiguous. I *think* it means a public-private key pair provisioned on the server side. In the second sentence it is not clear that this only applies to PAX_SEC (or least I think it is intended to) - the first sentence talks about deployment and doing public-key operations is not about deployment. s2.1: 'The client and server each exchange 256 bits of random data.' It is difficult to tell but I think that the protocol lower down indicates that 128 bits of data go in each direction. This needs rephrasing. s2.1: There is a 'typical' in the definition of g. Does it matter what choice is made? Does the other partner need to know (if not why not)? s2.1/s2.2: It would be a good idea to say (i.e. define A and B) that A is data that goes from server to client and B is data that goes from client to server. It would be clearer to say explicitly that A=X/g^X is carried out in the server, B=Y/g^Y is carried out in the client. Hence I assume that E can be created in both client and server. It doesn't appear to be used in s2.1 and s2.2 so it would be good to say that it is used later in s2.4 (I think). s2.1/s2.2: Using the format A = X (256 bit random data) is confusing because it looks horribly like the function application defined earlier. It would be good to find a different way to express what is effectively a comment reminding people of the the definitions of X, Y etc. s2.1/s2.2: Just to check... presumably A and B are ALWAYS 256 bits long even in the key update case. As mentioned above.. are we guaranteed that g^X etc always delivers 256 bits output? If not how do we select the relevant bits? s2.1/s2.2: CK is used without prior comment on HOWit is derived from AK. s2.2: How is CID created? (presumably this is what the user supplies). s2.2: > > If the underlying > EAP transport protocol is known, then the client SHOULD differentiate > between these fields. > a/fields/values/ - What are the consequences of not doing... under what circumstances would it be reasonable or necessary not to differentiate? What is the mapping between types of EAP transport protocol and field values ( straight PPP is obvious but what other types map to the two kinds?). What happens if other certificate types are defined? s2.2: The table of threats should have a pointer to the discussions of the threats in the Security Considerations. s3: The formats of the various length fields are not precisely specified (i.e. are they integers encoded in binary?) s3.1.5:., para 4: I think the two 'shall's ought to be SHALL. s5: The IANA considerations should have pointers to the relevant sections where the initial populations are defined. Should IANA also manage the op codes for the messages? Editorial ====== Abstract: Good idea to make the link between Extensible Access Protocol and EAP and expand the PAX acronym. s1.2; In the first sentence PAX protocol is used rather than EAP-PAX.. Good idea to be consistent. There are a couple of other places (e.g., PAX key derivation function) where it might or might not be a good idea to say EAP-PAX. s2: Expand acronym - MAC s2: Figure should have a title. (applies throughout!) s2.1: Expand ADE. s2.1/s2.2: Explain that the 'full protocol' consists of a number of messages - probably best laid out as a table with columns Message Title/Direction/EAP Payload s2.2: s/however careful consideration should be applied/however careful consideration should be given before omitting the CertPK/ a2.2: s/be either "eapOverPPP"/is either "eapOverPPP"/ s2.2: s/match the SSID/matches the SSID/ s2.3: The explanation of channel binding is somewhat opaque. Maybe a reference would help. s3: The terms 'challenge and response messages' are not used elsewhere. Should use consistent terminology s3.1.5: s/begin executed/being executed/ (after first bulleted list) s3.2: The last paragraph should contain a pointer to s3.4 which tells how to compute the ICV properly. AppB.1: Using requirements language in an advisory implementation appendix is inappropriate.