Subject: [Nea] review of draft-ietf-nea-pt-eap-00.txt

From: <[email-masked]>
Date: Thu, 2 Feb 2012 19:56:39 -0500

Hello Nancy and Paul,

I volunteered to review the draft for the working group.  The document looks very good.  A number of my comments are nits and some are areas in which the document can benefit from additional specificity.  Here are my comments:

Section 3.1, could you include a diagram?  I think that will help the reader to see the flow on first read.  The text reads well, but not being familiar with the draft, I had to read it twice to make sure I had the background to continue reading.  It would be useful to reference while reading section 3.2 as well.

Section 3.3: Just a suggestion to reword the first paragraph:
In most cases, EAP-TNC fragmentation will not be required. However, PB-TNC
   batches can be very long and EAP message length is sometimes tightly
   constrained.  As a result, EAP-TNC includes a fragmentation mechanism to be used
   when a particular PB-TNC batch is too long to fit into a single EAP-
   TNC message.

Section 3.3: It would be helpful to distinguish the differences from the referenced specifications so that a developer knows where this specification differs.

"The fragmentation mechanism used in EAP-TNC is quite similar to the
   mechanism used by EAP-TLS [17], EAP-TTLS [14], and EAP-FAST [12]. It
   uses the L flag (length included) and the M flag (more fragments) as
   well as the Data Length field."

In the following paragraphs, including the references to the appropriate spec where there is a match and then pointing out the difference could be useful.

Section 3.3: Is there a reference that can be included to where one can find the 'variety of reasons' in the last paragraph?
"However, a
   NEA Server or peer still MAY decide to terminate an EAP-TNC exchange
   at any time for a variety of reasons."

Section 3.4: Type, I had the word please in a draft :) and someone recommended pulling it out and just directly making the request.  You may want to do the same here.

Section 3.4 Data Length: Recommend adding a comma in the first sentence and removing two in the second:
Data Length is an optional field, four octets in length. When present, it
      indicates the total length before fragmentation of a fragmented
      PB-TNC batch.

Section 3.5:  Should 'SHOULD' be 'MUST' in the following sentence to protect against the attack?  If this is not required of the protocol, then I suggest using non RFC2119 language, something like the following:
To protect against NEA Asokan attacks, it is necessary for the Posture Broker on an EMA-
   equipped endpoint to pass the tls-unique channel binding [18] for
   PT-EAP's tunnel method to the EMA.

I think the following sentence should be broken into two as follows (left in the page information so you can find it):
This value can then be included

Sangster et al.       Expires February 30, 2012               [Page 10]

Internet-Draft                  PT-EAP                      August 2011

   in the EMA's attestation and the Posture Validator responsible for
   communicating with the EMA.  The EMA may then confirm that the value matches
   the tls-unique channel binding for its end of the tunnel.

Can you reword the following sentence (next one in this section)?  It is a little tough for me to follow:
"If the
   values match and the integrity of the endpoint is good, the posture
   sent by the EMA and NEA Client is from the same endpoint as the
   client side of the TLS connection (since the endpoint knows the tls-
   unique value) so no man-in-the-middle is forwarding posture."

Security Considerations: Could you reference the documents where the security requirements exist.  I like that the introduction to this section clearly states that these are recommendations and not the requirements, but want o be sure the requirements are directly referenced.

In section 4.2.1, RFC2119 terms are used, this means they are requirements.  Is that the case?  If so, you may want to have a Security Requirements section prior to your Security Considerations Section and include items like these.  It is starting to become a trend in drafts so that security requirements are not ignored by developers.  This particular statement is high-level, so you may want to change it to use language not defined in RFC2119, but clearly point to the specification that provides the details of how the authentication and other security features are provided in the introduction.

Section 4.2.2, Consider breaking the last sentence into multiple sentences.

Section 4.2.5 also contains an RFC2119 term.  This is fine, just point it out as you decide how to handle considerations versus requirements with the current introductory remarks.

Same for 4.3: This includes a set of requirements nested inside a section that says it is not requirements.

Section 4.3: I think you need to be more specific and provide references to the acceptable authentication options to have interoperability between implementations.

Section 4.4: I like seeing the reference to TLS, can you also include the references to EAP-FAST and EAP-TLS here so the reader has links to the RFCs when the document is published?  It could help them figure out things like the necessary version of TLS to support, etc.  I realize this is already referenced higher in the document, so it is just to be helpful to the reader/developer.

Section 4.4: Last paragraph, this goes into authentication, but doesn't provide a reference to the appropriate specs to follow either.

Section 4.5:  It may only be me, but I had to read the introductory sentence a couple of times to get the context - to make sure I had it right.  Can you add 'for this specification' or something like that to the sentence?

Section 6: I think you can make a direct statement requesting registration of the value.  This text will live on in the document after the value is assigned.  Maybe ask IANA, but in the draft make it more direct - Registers value 38...

Section 6.1 looks good - I just finished similar IANA requests.

I am just in the NEA-digest list, so if you would like me to see it right away, you may want to copy me directly.

Thank you,
Kathleen