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

[Elwyn Davies <[e-mail]>]

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