Subject: [eap] EAP IKEv2 Method

From: [email-masked] (Hannes Tschofenig)
Date: Thu, 24 Apr 2003 13:01:28 +0200

hi all,

some time ago we submitted a new eap method (EAP IKEv2) for publication.
unfortunately the draft is not yet available at the official ietf draft
directory. if you would like to read the draft already please then please
take a look at:

http://www.tschofenig.com/drafts/draft-tschofenig-eap-ikev2-00.txt

ciao

hannes

---

From: [email-masked] (Jari Arkko)
Date: Thu, 24 Apr 2003 15:28:52 +0300

Hannes, Dirk,

Thank you for your contribution. An interesting new method!
A few comments after the first quick read:

* I found it funny that you list "support of legacy
   authentication" as one of the improvements in IKEv2 ;-)

   Seriously though, the introduction of your document
   should be more clear about the scope of the protocol.
   This appears to be:

      (1) use a well known IKEv2 shared/cert authentication,
          AND
      (2) provide a new EAP tunneling method

   All in all, this would be quite a super method by any
   standards! Shared secrets, certs, CRL exchange, and
   EAP tunneling in a single method.

   At the very least, you should have a requirement
   that implementations MUST check they don't perform
   infinite recursion just because the bad guy offers
   to run EAP and IKEv2 in a looping fashion against it ;-)

* Section 1 talks about phases, but I believe the adopted
   IKEv2 term is "exchange". I think your intention is
   to use the IKE_SA_INIT and IKE_AUTH exchanges?

* I believe SAi2, SAr2, TSi, TSr are mandatory in IKE_AUTH
   exchange currently. So this is one case where you have to
   deviate from the IKEv2 specification? Should be listed at
   the start of Section 3, I think.

* I don't understand the statement "... differs from IKEv2
   only in the computation of the AUTH payload. For symmetric
   authentication no CERT and CERTREQ payloads are required."
   Is the latter statement the difference? Anyway, in IKEv2
   thees payloads are optional so you may not need to state
   this.

* s/provides information where the protocol messages described
   below terminate/provides information about the identities
   of the EAP endpoints/

* The discussion of identities probably deserves its own
   section. I suspect the current scheme is quite complex,
   and might benefit from simplification e.g. by requiring
   that some of the identities either be either omitted
   or are always the same as some other identities.

   FYI: Figure 3 example and some of the text in Section 3
   is in conflict with the IKEv2 requirement that
   EAP identity requests should not be used (section
   3.16 of ikev2-07).

* "To counter this threat IKEv2 provides a compound
    authentication by including the EAP provided session
    key inside the AUTH payload." To my knowledge IKEv2
   does this only for methods that provide session keys.
   Note that it does not currently specify anything
   meaningful (imho) for non-key-generating methods.

* Open issue on fragmentation: IKEv2 does not need to
   worry about fragmentation because lower layer provides
   that (well, there are debates about that too). However,
   in EAP we do not provide fragmentation at the lower layer,
   at least not in all contexts where EAP is used. So it
   seems like you do need to handle fragmentation, and extend
   the packet format accordingly. Or?

* Open issue on cert revokation. Wouldn't it be easiest to
   follow IKEv2? Is there a specific need to do OCSP in this
   protocol which does not exist for IKEv2? (Perhaps the lack
   of network access by the time EAP is typically run could be
   one such reason...)

Jari

---

From: [email-masked] (Hannes Tschofenig)
Date: Tue, 29 Apr 2003 13:17:43 +0200

hi jari,

thank you for the review. please see my comments inline:

----- Original Message -----

From: "Jari Arkko" <[email-masked]

To: "Tschofenig Hannes" <[email-masked] >

Cc: [email-masked]

Sent: Thursday, April 24, 2003 2:28 PM

Subject: Re: [eap] EAP IKEv2 Method

> (2) provide a new EAP tunneling method

you are certainly right. we should highlight these issues.

> to run EAP and IKEv2 in a looping fashion against it ;-)

yes, we should add a short comment to this fact.

> to use the IKE_SA_INIT and IKE_AUTH exchanges?

right. needs to be fixed in order to be aligned better with the language
used in ikev2 (i.e. not using ikev1 language)

> the start of Section 3, I think.

we have pointed to this circumstance in a separate paragraph.

we thought that it might be good not to exchange these payloads (since they
are not used afterwards). however, it might be good point to this issue at
the beginning of section 3.

> thees payloads are optional so you may not need to state

this sentence sounds somewhat strange.

the statements about the IKEv2 payloads still need some more

clarification in the draft.

> or are always the same as some other identities.

yes, this complexity indeed is an issue, as it is for other EAP methods
(particularly for all tunneling methods).

Is there any general guideline on dealing with this, or are there any

recommendations?

We agree that some simplification is useful here.

> EAP identity requests should not be used (section

the ipsec group was very busy in the last few month. this was introduced
with a recent version of the ikev2 draft. with the next version of the
document we try to get these issues updated.

> meaningful (imho) for non-key-generating methods.

this is certainly true. i have contacted the authors regarding this issue (a
nd others) some time ago. they indicated that this is subject to change in
future document versions.

i might need to contact them again.

> the packet format accordingly. Or?

thank you for you comment. we will add fragmentation support (as done by
other methods)

especially with fragmentation handling i guess it would be good to have a
general guidelines since the procedure might be applicable to a number of
documents (basically to all pk-based authentication methods).

> of network access by the time EAP is typically run could be

we certainly want to follow the approach taken by ikev2. there are reasons
to include support for ocsp (you mention one of them). we see some room for
improvement (in ikev2) :-)

ciao

hannes