eap Mailing List: RE: Questions and comments on draft-cam-winget-eap-fast-00.txt

[Joseph Salowey (jsalowey]

Hi Jari,

Thanks for looking at the draft. Comments and questions inline below:

Jari Arkko wrote:
> Hi Joe & co,
> 
> I have reviewed draft-cam-winget-eap-fast-00.txt and have
> the following comments and questions:
> 
> - The protocol is generally well constructed, and provides a useful
>    function. In particular taking into account the deployment aspects
> is excellent! 
> 
> - The protocol is also quite flexible, which is good. I'm somewhat
>    worried that the protocol leaves too much room for flexibility in
>    some case, however. For instance, is it really necessary to allow
>    other mechanisms than EAP-FAST to set up the PAC?
> 

[Joe] We have worked with some devices with weak processors that cannot
perform the provisioning protocol so we wanted to account for variation in
the way the PAC is delivered. I do think we need to be more specific about
what is required and recommended on server and client platforms. In any case
I think it is good to maintain some architectural separation between the PAC
establishment and usage.

> - I'm not sure how an Informational RFC like the one requested here
>    can allocate new TLS extensions, given the following statement   
> from RFC 3546: 
> 
>    "Traditionally for Internet protocols, the Internet
> Assigned Numbers
>     Authority (IANA) handles the allocation of new values for future
>     expansion, and RFCs usually define the procedure to be used by the
>     IANA.  However, there are subtle (and not so subtle) interactions
>     that may occur in this protocol between new features and existing
>     features which may result in a significant reduction in overall  
> security. 
> 
>     Therefore, requests to define new extensions (including assigning
>     extension and error alert numbers) must be approved by
> IETF Standards
>     Action."
> 
> - Similarly, I have understood that there is some other work in
>    progress at the IETF for addressing shared secret authentication
>    in TLS. It would have been good if EAP-FAST was in line with that.
> 

[Joe] We are preparing a draft that separates out the extensions so they can
be discussed with the TLS shared key discussions.

> - There needs to be a specification on how TLV type values are
>    allocated in the future. E.g., RFC required, FCFS, ...
> 

[Joe] Yes, we would like to keep these values in sync with PEAPv2

> - The relationship to EAP-TLS (i.e. similar but not the same thing and
>    not an extension of EAP-TLS) should be made clearer in the
> abstract. 
> 

[Joe] OK.

> - In some cases there's more room to interpretation and implementation
>    differences that I would perhaps like. For instance, inclusion of
>    the EAP header portion of EAP-TLV payloads is only a
> SHOULD; I'm not
>    sure I see how the format can differ, shouldn't this be a MUST? 

[Joe] Yes this should be more specific, The EAP-TLV within the tunnel MUST
NOT have an EAP header. 

> The
>    draft talks about "this version" and its possible future extensions
>    in several cases, perhaps some rules on what future versions can do
>    would be appropriate.

[Joe] OK

> Failure upon a bad Crypto-Binding TLV is   
> only a should, etc. 
> 
[Joe] Yes it seems that this should be a MUST as well.

> - The draft should state more clearly what keying material is
>    exported from inner methods. The MSK?
> 
[Joe] only the MSK is required from the inner method.

> - It would be good if the draft explicitly required the same authz
>    checks to be performed when doing fast resume vs. full   
> authentication. 
> 

[Joe] I'm not sure I follow, the authorization done can vary based on a
number of parameters.  Is there something that you are specifically trying
to address?

> - User identity protection should be described in more
>    detail. I think the draft assumes something like the
>    privacy NAI from draft-arkko-roamops-rfc2486bis-00.txt,
>    but I'm not sure. For interoperability, it would be good    to get
> this clear. 
> 

[Joe] OK, we'll look for opportunity to align with the draft. 

> - The official DNS example names should be used.
> 
> - I had a number of questions. Does the use of
>    TLS_RSA_WITH_RC4_128_SHA mean that you cannot change
> algorithms? 

[Joe] No, it is desirable to use different ciphers.  RC4 was chosen because
of some hardware constraints.  

>I'm
>    not sure I understood exactly what can be done with the PAC-Opaque,
>    can it make servers stateless, or just keep less state?
> 

[Joe] The amount of state that the PAC-Opaque allows you to avoid is
implementation dependant. In a minimal implementation the PAC-Opaque would
allow you to eliminate storing state for every resumable TLS session on the
server.  In this case the PAC-Opaque provides the server with a strong key
to use in protecting an weaker password based exchange such as MSCHAPv2.
The PAC-Opaque can be used to store more state to optimize authentication
and authorization as well.  Since the opaque is not understood by the client
the server can decide how to handle the PAC-Opaque.  

> More details and editorial issues can be found from
> http://www.arkko.com/publications/eap/eap_fast> _review.txt
> 
> 

[Joe] OK, Thanks for the detailed review.

> Note: My site and piuha.net are having some
> problems; if you can't access the URL ask me to send a copy.
> My kolumbus e-mail address also currently works better than
> the piuha one.
> 
> --Jari