eap Mailing List: RE: methods and expert reviews

[Pasi.Eronen (Pasi.Eronen]

Hi,

Having read draft-tschofenig-eap-ikev2-06, I believe this 
document is not ready for expert review yet. It needs a 
substantial amount of work to make it a decent EAP method 
specification, and its compliance with RFC 3748 is best 
assessed once it has matured a bit more.

Some comments (not as RFC3748 expert reviewer, but an
ordinary reviewer):

- The description of the protocol is very confusing reading.
  In many cases, the document seems to pretend it is using IKEv2
  as an EAP method, or profiling IKEv2, but it's not: This is a
  new protocol that just happens to copy many aspects from IKEv2
  (which is mainly a good idea, of course).

  So talking about sending IKEv2 messages is plain wrong:
  in almost all cases, the messages are not a valid IKEv2 
  messages. Even when the message formats look similar, the 
  semantics of the payloads and exchanges are not.

  Sometimes this gets just plain silly: For instance, Section 4
  says "In particularly the following messages and payloads
  SHOULD not be sent Traffic Selector (TS) payloads...". So what
  exactly would be the "valid reasons in particular circumstances" 
  (from RFC2119 definition of "SHOULD") to ignore this item,
  and how should the other end process those payloads?

  My suggestion for rewriting the draft would be as follows:
  First, consider choosing a less confusing name for your
  protocol. Then describe whatever message exchanges you have 
  in correct terms: you're describing EAP-IKEv2 messages 
  (not IKEv2 messages) that contain EAP-IKEv2 payloads (which 
  may copy the details from IKEv2 payloads, but the semantics 
  often change slightly... and then you don't have to say that 
  "traffic selector payloads must not be included", because 
  there's no such payload type in EAP-IKEv2). Finally, when 
  you have described what the EAP-IKEv2 messages and payloads 
  mean, you can say that the syntax is the same as for similarly 
  named IKEv2 payloads (so you get to reuse the work done for IKEv2).

- While copying the cryptographic aspects from IKEv2 is a good
  idea, perhaps copying everything is not (e.g. the messages
  for fast reconnect could be called something else than
  a "CREATE_CHILD_SA exchange", since CHILD_SAs are not very
  meaningful in this context)

- Since this document does not defined a tunneled EAP method,
  I'd suggest deleting all mentions this feature of IKEv2 
  (or at least move the text talking about "if we supported 
  this feature, it would be done that way" to an Appendix).

- Section 6: "Currently five bits ... are defined": this
  section defines the meaning of only three bits. Strangely
  enough, two other bits are named ("S" and "F") but it
  is not described why they're named, or what they mean.

- Section 6: "Each fragment sent must subsequently be 
  acknowledged": how?

- Section 8: length of EAP-IKEv2's MSK and EMSK is at least 64
  octets: how do the parties decide how much longer than 64
  octets? (or if it's exactly 64 octets, say so)

- Section 9: The part starting with "To avoid this..." sounds
  fishy: what's the benefit of having two different options
  in this situation? 

- Section 10: What happens if the peer has forgotten the SA?
  (figures 8 and 9 assume the peer still has the SA, 
  since it can send messages having "SK{..}")

- Section 11.4: since we have payloads whose contents are not 
  described in this document, we need a normative reference
  to some document whey there are described. Otherwise,   
  an implementation can't process those contents in an
  interoperable fashion...

- Section 12 should include some text about identity privacy
  (especially when doing fast reconnect or authenticating both
  parties using shared secrets).

- Missing "IANA considerations" section.

Best regards,
Pasi