Subject: [Nea] WGLC Comments on PT-EAP

From: Stephen Hanna <[email-masked]>
Date: Mon, 19 Mar 2012 16:46:57 -0400

Here are my comments on draft-ietf-nea-pt-eap-01.txt.
I have divided these comments into substantive ones
and typos. I don't think any of these comments will
be controversial but please review them and see what
you think. If you disagree, please speak up.

Also, I'd like to ask all NEA WG participants to
PLEASE look over the PT-EAP and PT-TLS specs and
send comments to the [email-masked] email list.
These documents are in WGLC. As a WG participant,
it's your responsibility to review the documents
and send your comments to the list. Even just saying
"Good with me" or "OK" is fine but you shouldn't
abdicate your duty by letting the documents fly by
without even looking at them.

Thanks,

Steve

----------

Substantive Comments on draft-ietf-nea-pt-eap-01.txt

* There's no need for the L bit or the Data Length field
  since we have removed fragmentation. The recipient of
  a PT-EAP message can determine the length of that message
  by just looking at the EAP Length field.

* In the last sentence on page 8, "match endpoint"
  should be "match and this is confirmed by the EMA".
  In order to prevent a NEA Asokan attack, the server
  needs to confirm that the EMA has the same tls-unique
  value. Another way to clarify this would be to change
  the words "NEA Client" where they first appear in
  that sentence to "EMA".

* In section 4.2.2, I think that "Similarly" should be
  "Therefore". This better explains the causality between
  hiding the PT-EAP method and increasing the difficulty
  for a passive MITM to tamper with the method. However,
  this argument is fairly weak since the PT-EAP method
  might always occur at the same offset in the exchange.
  Probably it would be better to just remove the last
  two sentences in this paragraph lest they give a false
  understanding of the protections that prevent a MITM
  from inserting falsified messages without detection.
  Those protections reside primarily in integrity
  protection and authentication not in encryption.

* In section 4.5, the claim for Fragmentation should be
  "No" since that has been removed from this draft.

* Could you please add my name to the Acknowledgments
  section? I did write the original version of this draft.

Typos in draft-ietf-nea-pt-eap-01.txt

* In the abstract, the first sentence should say "in
  a TLS protected tunnel method" not just "in TLS
  protected tunnel method". The difference here is
  adding the word "a".

* In the next sentence, delete "As such". It doesn't
  really add anything.

* In the last sentence of the first paragraph of the
  Introduction, change "The PT protocol must" to "The
  PT-EAP protocol must". That requirement doesn't apply
  to PT-TLS (i.e. PT-TLS needn't be protected by an
  outer tunnel because it already includes one).

* The heading at the start of section 3 should begin
  with a capital D not a lower case d.

* In the last sentence on page 8, the word "between"
  should be the word "of".

* In section 4 (just before section 4.1), the phrase
  "requirements for the NEA" should be just "requirements
  for NEA".

* In section 4.4, please insert a space after "[RFC5281]".
  This happens twice in that section.

* In section 4.5, delete the comma after the word "claims"
  in the first sentence. It's unneeded and confusing.
  Also, there are problems with the indentation of the
  table of claims in this section.

---

From: Carolin Latze <[email-masked]>
Date: Sun, 25 Mar 2012 22:39:16 +0200

Sorry for the late reply, but here are my (minor) comments:

- On the authors names, Nancy is listed with full name, Paul just with 
family name
- in the Introduction it is written that there is another PT protocol to 
run on top of IP. Maybe it would make sense to put a reference to 
PT-TLS? Just in case the reader wants to know the details on this protocol.
- Section 2: Since you talked about TLS-based tunnel methods before, you 
might want to add a "like TLS" to the last sentence.
- "3. definition of PT-EAP" -> capital "D"
- Section 3.4: In the sections before, you said PT-EAP could run over a 
TLS-based tunnel or one with comparable features. However, the channel 
bindings solution is only for TLS, right? So maybe, we need another 
sentence there, mentioning how to do this for other tunnel methods
- Section 4.1.1: "Expose the authenticated identity of the Posture 
Transport Server" -> " ... to the Posture Broker Client only" ?
- Section 4.1.2: same just for the server
- Section 4.4: "EAP-FAST [RFC4851] and EAP-TTLS [RFC5281]make use of TLS 
[RFC5246] to" -> space missing after [RFC5281]
- " With all these methods (e.g. EAP-FAST [RFC4851] and EAP-TTLS 
[RFC5281], a cryptographic key is derived from the authentication..." -> 
closing ")" is missing

Regards
Carolin

On 03/19/2012 09:46 PM, Stephen Hanna wrote:
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea
>