Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Mar 2011 11:25:54 +0200

Hi all

I have just read the subject draft, and found this in section 6 (and similar text in the introduction):

   Note that to support ERP, lower-layer specifications may need to be
   revised.  Specifically, the IEEE802.1x specification must be revised
   to allow carrying EAP messages of the new codes defined in this
   document in order to support ERP.  Similarly, RFC 4306 must be
   updated to include EAP code values higher than 4 in order to use ERP
   with Internet Key Exchange Protocol version 2 (IKEv2).  IKEv2 may
   also be updated to support peer-initiated ERP for optimized
   operation.  Other lower layers may need similar revisions.

Note that this is not new text, and it appears pretty much the same way in RFC 5296.

There's the obvious nit with this text, that RFC 4306 is not a reference. If it was, the id-nits would warn about this RFC being obsolete. But that's the small problem here. 

A bigger problem is that this text says that IKEv2 needs to be updated, but there is no draft for this update, nor has there been any message to this list about this proposed change. 

The simple change they require is to section 3.16:
   o  Code (1 octet) indicates whether this message is a Request (1),
      Response (2), Success (3), or Failure (4).

I think this could be done with an errata or a 1-page draft, if all that was required was pass-through of codes (5) and (6). But I think it's more involved than that.

There's peer-initiated ERP (which would require peer-initiated IKE?) and multiple simultaneous operations. I think it may come to a somewhat larger draft.

I think there should be at least a work-in-progress reference for 802.1x and IKEv2 before the hokey draft progresses.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Sun, 6 Mar 2011 11:45:45 +0200

> There's peer-initiated ERP (which would require peer-initiated IKE?) and multiple simultaneous operations. I think it may come to a somewhat larger draft.

Sorry. peer=remote access client, so peer-initiated IKE is the norm. They real changes would be either allowing two EAP messages in a single IKE_AUTH response, or something that's more lock-step than this:
                                                The authenticator MAY
   initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start
   message, and if there is no response, it will send the EAP-Request/
   Identity message.  

IKEv2 doesn't do "no response", so we'd have to respond either within EAP or in an IKE notification. Then we have a problem with how to communicate this to the back-end authentication server.

Definitely looking like a big draft.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 7 Mar 2011 17:58:53 +0200

Yoav Nir writes:
> A bigger problem is that this text says that IKEv2 needs to be
> updated, but there is no draft for this update, nor has there been
> any message to this list about this proposed change.  
> 

Note also that section 2.16 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.

and section 3.16 says:

                                                           Many
   of these methods have been defined, specifying the protocol's use
   with various authentication mechanisms.  EAP method types are listed
   in [EAP-IANA].  A short summary of the EAP format is included here
   for clarity.

meaning that the rfc5996 does not even try to be definite guide for
EAP, it just includes some information about EAP protocol for clarity. 

> I think this could be done with an errata or a 1-page draft, if all
> that was required was pass-through of codes (5) and (6). But I think
> it's more involved than that.

If it just for pass-through then I do not think even errata is needed,
as it does not change the protocol. The EAP payload contains full EAP
payloads inside, and the EAP payload format listed in the RFC5996 is
only there for clarity and is not mean to be definite protocol
description.

If it changes anything else than pass-through codes not listed in the
RFC5996 then new draft is needed. We should not make same mistakes
again and do techinal changes in errata. 
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Mar 2011 23:03:38 +0200

> EAP, it just includes some information about EAP protocol for clarity. 

Yes, and we got rid of the list of types that we had in 4306, but still, there is text there that says that only requests and responses have types. Not so under 5296.

> again and do techinal changes in errata. 

Unfortunately the changes are much more involved. the first IKE_AUTH response would have to have not one, but two EAP messages, one for "initiate" and one for "request identity". This conflicts with the usual practice in IKEv2 to have the identity in the first IKE_AUTH request, so you would be more likely to have two EAP messages, one for "initiate", while the other is for a specific EAP method.

Alternatively, you could send just the "initiate" message. With EAP you wait, and if you get no response, you revert to "request identity" or "request MSChapv2". There is no negative response to the "initiate" in ERP. But in IKE, we can't wait, so we'd have to add an IKE-level notification that says "no ERP response".

Either way, it's a major enough change that you can't do it without negotiating the capability in either IKE_INIT or the IKE_AUTH request.

So this becomes a big change, and AFAIK nobody's working on such a draft for either IKEv2 or for 802.1x, which would require similar changes.

---

From: Qin Wu <[email-masked]>
Date: Mon, 14 Mar 2011 14:53:53 +0800

Hi, Yoav:
Sorry for my late feedback.
Thank for your reviewing this document and catching this nits. I will update rfc5296bis to get alignment with RFC5996.
Also I think it will be good to see the update of RFC5996 to support ERP.

Regards!
-Qin
----- Original Message ----- 
From: "Yoav Nir" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Sunday, March 06, 2011 5:25 PM
Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>