RE: some comments on draft-josefsson-pppext-eap-tls-eap-07 (peapv2)
From: Joseph Salowey (jsaloweycisco.com)
Date: Fri, 21 Nov 2003 13:37:32 -0600 (CST)
Hi Jari,

Thanks for the review.  Comments inline below.

Thanks,

Joe

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko [at] piuha.net] 
> Sent: Sunday, November 09, 2003 3:33 AM
> To: Joe Salowey
> Cc: eap [at] frascone.com
> Subject: some comments on 
> draft-josefsson-pppext-eap-tls-eap-07 (peapv2)
> 
> 
> 
> 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

[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.  

 
> 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?
> 

[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

> 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...
> 
[Joe] this would probably be helpful.


> 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?
> 
[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.



Results generated by Tiger Technologies using MHonArc.