In case anyone wonders, my reply to Yaron was basically: "I dunno & will be interested to find out if you're missing something or not"
S. On 08/03/11 07:35, Yaron Sheffer wrote: > Hi Glen, > > thank you for your kind words. It is always a pleasure to help a fellow > security working group, and your positive and helpful feedback makes it > doubly so. > > Back to the subject at hand: EAP is one of the rare security protocols > that are truly reusable. And in fact it is used by multiple protocols, > including 802.1X, IKE and the TNC protocols. With success comes > responsibility. If your working group makes significant, architectural > changes to the protocol, it is *your responsibility* to ensure they can > be accommodated by users of the protocol. And in the case of IETF > working groups, it is indeed the job of the Security AD to ensure such > coordination takes place. > > ERP is such a major change because (correct me if I am wrong): > > - Its transport behavior is different from the base EAP, allowing > multiple exchanges to be in flight at the same time. > - ERP peers actually *degrade* the behavior of EAP, because of > timeouts/retransmissions introduced when talking to non-ERP auth > servers, and similarly for ERP auth servers with non-ERP peers (this > behavior is spelled out quite clearly on p. 8 of the bis draft). > > PS: I'm glad to hear that 802.1X-2010 supports ERP. I just wonder why > the bis draft does not recognize this fact. > > Best regards, > > Yaron > > On 03/08/2011 06:51 AM, Glen Zorn wrote: >> On 3/6/2011 4:43 PM, Yaron Sheffer wrote: >>> Hi Stephen, >>> >>> I gather you are the incoming responsible AD for HOKEY. >>> >>> ERP (RFC 5296, now reincarnated as a bis document) is one of HOKEY's >>> principal work items. The document is making major changes to EAP, and >>> seems to have gotten a life of its own, despite the fact that AFAIU >>> neither of its protocol users (802.1X and IKEv2) has been changed to >>> accommodate it. It seems to me at best like wasted effort, more likely a >>> disconnect between the working groups. >> >> >> First of all, I'd like to express my deep appreciation (& I think that I >> can speak for all the members of the hokey WG) for you kind concern for >> the use of our time. It is especially wonderful since AFAIK you have >> heretofore shown no interest at all in our activities; to extend >> yourself in this way for a group with which you have essentially no >> connection is truly magnanimous; and to go straight to the Area >> Director, the one person who might be able to save us from this terrible >> waste of effort & time! I must say that I find it hard to express in >> words how it makes me feel. Nonetheless, I admit to some puzzlement as >> to the rationale for this action: the referenced draft is a chartered >> work item of the hokey WG, adopted after a call for consensus from the >> members. Of course, you could not know about the call since you aren't a >> WG member but it did occur. So while I do appreciate your obviously deep >> and selfless concern, I am inclined to let the actual members of the WG >> decide what (if anything) they deem worthy of effort. But, thanks again! >> >> P.S. >> I'm pretty sure that IEEE 802.1X-2010 supports ERP. >> >>> >>> Am I missing anything? >>> >>> Thanks, >>> Yaron >>> >>> -------- Original Message -------- >>> Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis >>> Date: Sun, 6 Mar 2011 11:25:54 +0200 >>> From: Yoav Nir <y...@checkpoint.com> >>> To: ipsec@ietf.org <ipsec@ietf.org>, >>> draft-ietf-hokey-rfc5296...@tools.ietf.org >>> <draft-ietf-hokey-rfc5296...@tools.ietf.org> >>> >>> 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 >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
