eap Mailing List: some comments on draft-josefsson-pppext-eap-tls-eap-07 (peapv2)

[Jari Arkko (jari.arkko]

I read this document on the way to Minneapolis, and have
some questions and comments:

Substantial:

1. Section 1, identity protection. Wouldn't it still be
   possible to have an active attack against identity protection?
   This seems possible
     - if one of the other servers trusted by the CA
       wants to intervene (or do you require specific
       server cert?)
     - if the client won't or can't (network access case)
       check the CRL and the server's key has been compromised

2. Section 1, protected termination and dos attacks. I wonder
   if there still exists a dos attack where the attacker simply
   injects some bad TLS records into the stream. Will this cause
   a disconnect or is there some protection against that?

3. Section 2, the possibility of running zero EAP methods
   in part 2. What would be the usefulness of that over
   running EAP TLS? The ability to send TLVs?

4. Section 2.2.2.1, why is it just a "should" to decide that
   a tunnel compromise error has occurred when an invalid
   Crypto-Binding-TLV is received? And where does it say
   what actions "tunnel compromise error" implies?

5. I wonder if the protocol specification would be clearer
   with a state machine. I'm not 100% convinced that all
   the cases have been covered in the text, and its hard
   to visualize what is happening. Maybe its just me, but...

6. Section 4.7, Connection-Binding TLV. This is very
   interesting! You say that the actual parameters are
   defined by the link layers. But this does not appear
   to suffice for the definition of the format on how
   they are carried in this TLV, or? How would we know
   which parameters and in which order are sent here
   unless the 802.11i, for instance, explicitly said that
   SSID and MAC address were carried inside PEAPv2 in
   a particular way?

7. What is the purpose and semantics of the URI TLV?

8. I'm not sure if Section 5.2 contains enough information
   about the version negotiation and potential downgrade
   attacks involved in PEAPv2 - PEAPv1 choice.

9. Section 5.8 says "Hence, the recommended solution is
   to always deploy authentication methods with protection
   of PEAPv2." Hmm... I would formulate this slightly
   differently if the intent is to avoid mitm problems:
   "Hence, the recommended solution is to deploy
   authentication methods for a given user either always
   with the protection of PEAPv2 or never with PEAPv2."

Editorial:

1. Draft name would probably be more descriptive if it contained
   "peap".

2. Recommended author limit has been exceeded, I think.

3. Section 2.4 has some duplication, e.g. the paragraphs starting
   with "a single tls record may be up to 16384...".

--Jari