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

[Jari Arkko (jari.arkko]

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