[Gen-art] Re: Gen-art review of draft-clancy-eap-pax-08

[Charles Clancy <[e-mail]>]

Elwyn,

Thanks for your very thorough review.  You bring up some good points, 
particular with regard to the length of the NAI and the length of g^XY.

I'll work through your comments, and hopefully put together a -09 by 
next week.  Thanks again!

-- 
Dr. Charles Clancy, Research Scientist
Laboratory for Telecommunications Sciences
[e-mail]


Elwyn Davies wrote:
> I am the assigned Gen-ART reviewer for
> draft-clancy-eap-pax-08.txt. For background on Gen-ART, please see the 
> FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> 
> Please consider these comments along with any other last call comments 
> you may receive.
> 
> 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.


_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art