Subject: [eap] Questions and comments on draft-cam-winget-eap-fast-00.txt

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Apr 2004 23:22:44 +0300

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?

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

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

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

- 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? 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. Failure upon a bad Crypto-Binding TLV is
   only a should, etc.

- The draft should state more clearly what keying material is
   exported from inner methods. The MSK?

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

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

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

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

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

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