Subject: [Nea] Review of draft-ietf-nea-pt-eap-02.txt

From: Alan DeKok <[email-masked]>
Date: Wed, 06 Jun 2012 15:09:17 +0200

Some minor notes:

Section 1:

   The PT-EAP protocol
   must be protected by an outer EAP TLS-based tunnel to ensure the
   exchanged messages are protected from a variety of threats from
   hostile intermediaries.

 That should probably be MUST instead of "must".

 I also suggest adding text saying:

  The encapsulating EAP TLS-based tunnel MUST first authenticate
  the user prior to using PT-EAP.

 i.e. using EAP-TLS + PT-EAP might be OK.  Using EAP-TTLS with *only*
PT-EAP inside the TLS tunnel should be forbidden.

Section 3.3:

   Type

      TBD

 Suggestion: add a discussion of what the type field means, and what it
is likely to be used for.

  Data

      Variable length data.  The length of the Data field in a
      particular PT-EAP message may be determined by subtracting the
      length of the PT-EAP header fields from the value of the two octet
      Length field.

 It's worth saying what the data is expected to be.  Right now,
transport of JPGs inside of PT-EAP seems to be allowed.

Section 4.2.1:

   In order to protect against NEA assessment message theft, the EAP
   tunnel method carrying PT-EAP must provide strong cryptographic
   authentication, integrity and confidentiality protection.

 That should probably be MUST instead of "must".

Section 4.2.3:

   The
   strong integrity protections (hashing) offered by EAP-TTLS allows the
   PT-EAP message recipients to detect message alterations by other
   types of network based adversaries.

 Is "hashing" a method of strong integrity protection?  Or is it just
using the TLS message integrity methods?

Section 7:

  There is no IANA considerations for the "Type" field.  Since it is
being defined here, I presume there will be an IANA "PT-EAP Type" registry.

  It would be good to add a section (7.2) describing this registry.

  Alan DeKok.