Subject: RE: PANA protocol based on IKEv2?

From: <[email-masked]>
Date: Tue, 24 Jun 2003 19:42:33 +0300

Hi Hannes,

Sorry, I wasn't aware that this idea had been already discussed.
However, I don't 100% agree on the reasons given for rejecting
a protocol based on IKEv2-like messages.

Using IKEv2-like messages does not necessarily imply establishing 
a server-to-client authenticated tunnel.  I admit that IKEv2 is 
usually used with such a tunnel, and that is problematic for PANA; 
mostly for the reason that the tunnel requires certificates 
for the server-to-client authentication (which sort of breaks 
the extensibility idea in EAP).  

But PANA could easily use IKEv2-like messages without requiring 
this, so the server-to-client authentication would be based solely 
on EAP keys (just omit the AUTH payload from the 2nd message from
Responder, and all CERT/CERTREQ payloads).  The man-in-the-middle 
attack discovered by Kaisa Nyberg et al. is taken into account in IKEv2.

I'm not saying that using IKEv2-like messages would be a major 
security improvement (it would eliminate all passive eavesdropping 
attacks, though). I think the more important issue would be getting 
many of the other "small" details of the protocol (I'm referring to 
all the discussions about message formatting, calculating MACs, 
session-ids, cookies, retransmissions, error messages, key derivation, 
etc.)

Best regards,
Pasi

> -----Original Message-----
> From: ext Tschofenig Hannes [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2003 7:04 PM
> To: Eronen Pasi (NRC/Helsinki); [email-masked]
> Subject: RE: PANA protocol based on IKEv2?
> 
> 
> hi pasi, 
> 
> thanks for your observation. however, we discussed this issue 
> some time ago
> during the pana design team work at. please take a look at:
> http://danforsberg.info/pipermail/pana-dt/
> 
> furthermore, i briefly mentioned the two possible approaches 
> at the last
> ietf meeting - see slides at
> http://people.nokia.net/~patil/IETF56/PANA/
> see slide 18 and slide 34 at
> http://people.nokia.net/~patil/IETF56/PANA/PANA_Solution_Slide
> s_7.pdf. 
> the two-step approach thereby refers to the ikev2, pic and similar
> approaches. 
> 
> since the pana protocol does not only focus on establishing 
> ipsec sas and since we do not always want to establish a "tunnel" 
> (i.e. server-to-client auth.) before executing eap we rejected 
> this approach.  
> btw, with the discovered man-in-the-middle attacks by kaisa 
> nyberg and her collegues the justification for establishing a 
> tunnel is rather weak in the meanwhile. 
> 
> regarding secure address configuration please take a look at: 
> http://www.tschofenig.com/drafts/draft-tschofenig-pana-bootstr
> ap-rfc3118-00.
> txt
> 
> ciao
> hannes

---

From: Yoshihiro Ohba <[email-masked]>
Date: Tue, 24 Jun 2003 10:55:07 -0700

Hi Pasi,

I agree that using IKEv2-like messages does not necessarily imply
establishing a server-to-client authenticated tunnel.  However,
establising a secure tunnel is needed anyway.  As far as I understand,
using IKEv2-like messaging has the following characteristics:

  Establising a secure tunnel needs Diffie-Hellman key exchange.  Then
  EAP is carried through the tunnel.  If lower-layer is secure (this
  is one PANA usage scenario), such D-H is obviously not necessary.
  On the other hand, if lower-layer is insecure (this is also a PANA
  usage scenario), then we need to deal with cryptographic binding to
  deal with man-in-the-middle attacks for the compound authentication
  method.  IKEv2 solves this by using AUTH payload in IKE_AUTH
  exchange, where the AUTH payload is calculated by using a shared key
  derived from an EAP authentication method.  But this implies that
  another D-H (or other public-key based) key exchange is needed to
  derived the shared key from the EAP authentication method (if the
  EAP authentication method does another level(s) of tunneling, it may
  need more D-H(s)).  But if we follow the current PANA design, the
  number of D-Hs can be reduced by one compared to the IKEv2-based
  method and that's why we thought the current approach is simpler
  and better than IKEv2-like messaging though both approaches satisfy 
  the PANA requirements.

(I'd rather suggest considering to use IKEv2 as an EAP authentication
method [draft-tschofenig-eap-ikev2-00.txt], which provides a robuster
solution for "invalid-MIC" DoS attack than using TLS-bases EAP
authentication methods, since IKEv2 silently discards messages that
contain invalid MIC, instead of immediately ending the conversation.)

Regards,
Yoshihiro Ohba