Subject: [IPsec] draft-nir-ipsecme-erx

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Mar 2012 18:08:58 +0200

Hi

This is about my presentation from the IPsecME meeting today (which for some reason is not on the website)

Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry ERP messages". This caused some controversy a year ago, but regardless, I did think of a use case, so I partnered with Qin Wu and wrote the draft.

The use case is being able to seamlessly move between two networks were network access is granted or denied based on EAP. Examples are 802.1x and IKEv2. IEEE has already revised 802.1x so that moving between two 802.1x access points can use ERP to be seamless, but IKEv2 has not. a mobile device could use 802.1x within the corporate network and move to IPsec as soon as it leaves the building. MCR has called this the "Elvis" use case, but it actually should work seamlessly in the other direction, when the mobile node enters the building, detects the 802.1x network, establishes an association, and deletes the no-longer-needed IKE and child SAs.

My first priority is for this to become a WG item. It probably needs some work, and there is an open question about whether there is any use case for multiple AAA domains.

If not, I'm also fine with taking this directly to Sean.

Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 26 Mar 2012 19:43:59 +0300

Yoav Nir writes:
> Anyways, RFC 5266 mentions that "RFC 4306 must be updated to carry
> ERP messages". This caused some controversy a year ago, but
> regardless, I did think of a use case, so I partnered with Qin Wu
> and wrote the draft. 

RFC5996 says:

   While this document references [EAP] with the intent that new methods
   can be added in the future without updating this specification, some
   simpler variations are documented here.  [EAP] defines an
   authentication protocol requiring a variable number of messages.

and

         A short summary of the EAP format is included here
   for clarity.

So my take there is that the EAP description in the RFC5996 is just
for clarity, and is not meant to be exhaustive, meaning it does not
limit codes we can use in the EAP messages. 

On the other hand RFC5996 also says that:

   Following such an extended exchange, the EAP AUTH payloads MUST be
   included in the two messages following the one containing the EAP
   Success message.

which means that as ERX uses different message to finish the
authentication, update to the RFC5996 is needed (i.e. not to allow
codes 5 and 6, but to say we can have EAP payloads in exchanges where
they normally do not be and tell that EAP exchange can finish with
these other codes too).

> My first priority is for this to become a WG item. It probably needs
> some work, and there is an open question about whether there is any
> use case for multiple AAA domains. 

I agree it could be WG item. On the other hand I also think it might
be quite fast document, so getting it out as individual rfc might be
faster.
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 26 Mar 2012 19:11:57 +0200

> limit codes we can use in the EAP messages. 

Agree. That's why my draft calls it "clarification"

> be quite fast document, so getting it out as individual rfc might be

They're not necessarily faster. What the draft needs is review, especially regarding the assumption that multiple AAA domains are not needed. I think WG documents get better review, but even that is not really clear.

Yoav