One more thing about IKEv2 and EAP...

[Pasi.Eronen@nokia.com]

Hi,

While discussing IKEv2 and EAP with Hannes Tschofenig, we 
noticed some strangeness in IKEv2 handling of EAP keys
and AUTH payloads. The -12 version says:

  "In such an extended exchange, the EAP AUTH payloads MUST be
  included in the first message each end sends after having
  sufficient information to compute the key. This will usually 
  be in the last two messages of the exchange."

The part I'm a bit worried about is "after having sufficient
information to compute the key". EAP State Machine document 
currently specifies that the key is made available to the 
"lower layer protocol" outside EAP (in this case, IKEv2) 
only after an EAP-Success message has been sent (authenticator) 
or received (peer).

This practise is also reflected in AAA protocols such as RADIUS
and Diameter. The backend authentication server sends the key
together with EAP-Success (e.g. in RADIUS Access-Accept packet).

Furthermore, the last sentence is not correct: in most commonly
used EAP methods, the key can be calculated well before the last 
two messages (e.g. EAP-TLS, PEAP, EAP-SIM, EAP-AKA, ...). For 
instance, a typical EAP-TLS exchange (with TLS_RSA_WITH_RC4_128_SHA
ciphersuite) has 7 messages (including EAP-Success). The peer 
could include the AUTH payload already with message #4 and 
authenticator with message #5. 

There are other complications as well: 

- In some methods the peer can compute the key first 
  (e.g. EAP-TLS), in others the authenticator (e.g. EAP-SIM). 

- It would be possible to have an EAP method where the 
  authenticator has enough information to compute the key 
  already in the first message (e.g. "key transport type" stuff); 
  in this case, message #4 would contain two AUTH payloads 
  (and that probably complicates things).

- In some EAP methods the peer does not know in advance which is 
  the last EAP-Response it will send. It would be possible to have 
  a method where the final key depends on all messages exchanged,
  so the peer would not have enough information to calculate the 
  key until receiving EAP-Success.

- In some methods (e.g. PEAPv2) it is not always trivial to 
  even determine when the necessary information is present, 
  since this can depend on local policy about what methods can 
  be run inside the "PEAP tunnel". 

I think this is likely to lead to problems, interoperability 
and otherwise. However, using the normal EAP practise (key 
becomes available only after EAP Success) would mean one 
additional round-trip, either:

      HDR, SK { EAP(...last response...) }  -->

      <--   HDR, SK { EAP(Success), AUTH }

      HDR, SK { AUTH }  -->

      <--   HDR, SK { SAr2, TSi, TSr }

Or alternatively:

      HDR, SK { EAP(...last response...) }  -->

      <--   HDR, SK { EAP(Success) }

      HDR, SK { AUTH }  -->

      <--   HDR, SK { AUTH, SAr2, TSi, TSr }

Any comments on how to best handle this? Is an extra roundtrip
necessary (it is if EAP state machine is followed), or could
this be handled in some other way? 

Best regards,
Pasi