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

From: Nancy Cam-Winget <[email-masked]>
Date: Fri, 09 Mar 2012 19:13:06 -0800

Hi Kathleen,

Many thanks for the careful review, I have tried to incorporate most of your
comments and suggestions
 in the recently updated draft but had some further questions/comments below
(we can also discuss
 them at the IETF if you will be there?):

On 2/2/12 4:56 PM, "[email-masked]" <[email-masked]>
wrote:
 
> 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.
> [NCW] Will be happy to include a diagram but I wasn¹t exactly sure as to
> whether you were looking for an
> PT-EAP vs. EAP-tunnel-method+PT-EAP flow or general encapsulation of PT-EAP
> inside a tunnel method.
> If you can provide more guidance, I can make an attempt at such a diagram.
> 
> 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.
> [NCW] Given that there was agreement that PT-EAP did not need fragmentation I
> think that this
> and the next few comments no longer need to be addressed.
> 
> 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.
> [NCW] The note has been removed as the Type must now be assigned by IANA.
> 
> 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.
> [NCW] The sentence/paragraph was reworked given that there is no fragmentation
> within PT-EAP.
> 
> 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.
> [NCW] Updated per your suggestion.
> 
> 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.
> [NCW] I¹ve updated the text to reflect that it is the Posture Validator who is
> validating the tls-unique passed by the NEA Client to the EMA.  Please let me
> know if it is still unclear and we can try to make further adjustments.
> 
> 
> 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."
> [NCW] Reworded to ³If the tls-unique values between the NEA Client and NEA
> Server match endpoint, then the posture sent by the EMA (and thus the 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.²
> Again, please let me know if further adjustments need to be made.
> 
> 
> 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.
> [NCW] RFC5209 has been added as the reference.
> 
> 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.
> [NCW] In the interest of time and discussion, I¹d like to leave this one for
> us to close at the IETF meeting.
> I think I¹m OK moving the EAP Tunnel Security requirements but then am not
> sure that would leave much in the Security Considerations....or, we could also
> soften the language.  But I would like to get others in the WG to
> chime in as well....
> 
> Section 4.2.2, Consider breaking the last sentence into multiple sentences.
> [NCW] The last sentence of the last paragraph has been split into
> two....please let me know if more is needed.
> 
> 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.
> [NCW] Again, I¹ve put this in the general topic of ³how to organized the
> requirements vs. considerations²
> for us to discuss at the IETF (and of course, can continue to do so in the
> reflector as well).
> 
> 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.
> [NCW] References have been added.
> 
> Section 4.4: Last paragraph, this goes into authentication, but doesn't
> provide a reference to the appropriate specs to follow either.
> [NCW] Added EAP-FAST and TTLS as examples (with references).
> 
> 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?
> [NCW] Updated per your suggestion.
> 
> 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...
> [NCW] Text has been updated to reflect that IANA must assign a new EAP value.
> 
> Section 6.1 looks good - I just finished similar IANA requests.
> [NCW] Thanks!
> 
> 
> 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
> 
> 
> 
>

---

From: <[email-masked]>
Date: Mon, 12 Mar 2012 09:09:11 -0400

Hi Nancy,

You are welcome, I am glad you found the comments helpful.  Yes, I will be at the meeting in Paris and we can talk more then.  The responses in-line look good, thank you for making the updates.  I will look through the updated draft prior to the meeting and we can discuss the outstanding items along with any other comments.

Thank you,
Kathleen

From: Nancy Cam-Winget [mailto:[email-masked]]
Sent: Friday, March 09, 2012 10:13 PM
To: Moriarty, Kathleen; [email-masked]
Cc: [email-masked]
Subject: Re: review of draft-ietf-nea-pt-eap-00.txt

Hi Kathleen,

Many thanks for the careful review, I have tried to incorporate most of your comments and suggestions
 in the recently updated draft but had some further questions/comments below (we can also discuss
 them at the IETF if you will be there?):

On 2/2/12 4:56 PM, "[email-masked]" <[email-masked]> wrote:

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.
[NCW] Will be happy to include a diagram but I wasn't exactly sure as to whether you were looking for an
PT-EAP vs. EAP-tunnel-method+PT-EAP flow or general encapsulation of PT-EAP inside a tunnel method.
If you can provide more guidance, I can make an attempt at such a diagram.

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.
[NCW] Given that there was agreement that PT-EAP did not need fragmentation I think that this
and the next few comments no longer need to be addressed.

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

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.
[NCW] The note has been removed as the Type must now be assigned by IANA.

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.
[NCW] The sentence/paragraph was reworked given that there is no fragmentation within PT-EAP.

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.
[NCW] Updated per your suggestion.

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

   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.
[NCW] I've updated the text to reflect that it is the Posture Validator who is validating the tls-unique passed by the NEA Client to the EMA.  Please let me know if it is still unclear and we can try to make further adjustments.

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."
[NCW] Reworded to "If the tls-unique values between the NEA Client and NEA Server match endpoint, then the posture sent by the EMA (and thus the 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."
Again, please let me know if further adjustments need to be made.

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.
[NCW] RFC5209 has been added as the reference.

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.
[NCW] In the interest of time and discussion, I'd like to leave this one for us to close at the IETF meeting.
I think I'm OK moving the EAP Tunnel Security requirements but then am not sure that would leave much in the Security Considerations....or, we could also soften the language.  But I would like to get others in the WG to
chime in as well....

Section 4.2.2, Consider breaking the last sentence into multiple sentences.
[NCW] The last sentence of the last paragraph has been split into two....please let me know if more is needed.

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.
[NCW] Again, I've put this in the general topic of "how to organized the requirements vs. considerations"
for us to discuss at the IETF (and of course, can continue to do so in the reflector as well).

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.
[NCW] References have been added.

Section 4.4: Last paragraph, this goes into authentication, but doesn't provide a reference to the appropriate specs to follow either.
[NCW] Added EAP-FAST and TTLS as examples (with references).

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?
[NCW] Updated per your suggestion.

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...
[NCW] Text has been updated to reflect that IANA must assign a new EAP value.

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