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
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
