On Mar 7, 2011, at 5:58 PM, Tero Kivinen wrote: > 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. >> >> 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). > > 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.
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. > >> 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. 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. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
