Subject: [eap] some comments on draft-josefsson-pppext-eap-tls-eap-07 (peapv2)

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Nov 2003 13:33:27 +0200

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

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 21 Nov 2003 11:37:17 -0800

Hi Jari,

Thanks for the review.  Comments inline below.

Thanks,

Joe

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Sunday, November 09, 2003 3:33 AM
> To: Joe Salowey
> Cc: [email-masked]
> Subject: some comments on 
> draft-josefsson-pppext-eap-tls-eap-07 (peapv2)
> 
> 
> 

[Joe] Yes, if the client fails to correctly authenticate and authorize
the server then attacks on identity are possible.  PEAP does not require
a particular certificate profile, it is currently up to the deployment.
Individaul servers could authenticated, but it is not clear that that is
generally required.  It is also possible for the client and server to
support TLS extensison to use OSCP for certificate validation.  

>     running EAP TLS? The ability to send TLVs?

[Joe] EAP-TLS requires client authentication. PEAP can be run with
server only authentication and provide anonymous access to the client.
The ability to send TLVs is also very very useful

>     to visualize what is happening. Maybe its just me, but...
[Joe] this would probably be helpful.

>     SSID and MAC address were carried inside PEAPv2 in
[Joe] The connection binding TLV is meant to provide a way to bind PEAP
to lower layer parameters.  The exact information is specific to the
application that is using PEAP such as 802.11i or IKE or ???.  We also
need to describe a bit more about the processing of this data since the
EAP-Server may not have enough information to validate it.  In general I
think this information would be provide to the AAA code as
"authenticated channel attributes" since the AAA portion of the system
would have a better idea of what to do with them.

> 7. What is the purpose and semantics of the URI TLV?
[Joe] Good question.  Maybe Ashwin can provide more details.