Re: [HOKEY] Fwd: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 08 March 2011 07:34 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: hokey@core3.amsl.com
Delivered-To: hokey@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B0A3A6914; Mon, 7 Mar 2011 23:34:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG-K3MePsIdu; Mon, 7 Mar 2011 23:34:25 -0800 (PST)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6CA4C3A690F; Mon, 7 Mar 2011 23:34:24 -0800 (PST)
Received: by wwa36 with SMTP id 36so386445wwa.13 for <multiple recipients>; Mon, 07 Mar 2011 23:35:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4XudQRBVXEBhmdFlucipV91/MGOcUc4A6J65lCV1zio=; b=nVUFR664LGF2bTsIqv5jXJZ54M+7qNeh6WvWAg8x0ehCF8l9j0N1YrndHjt0Zut58S OAJb2IwDqdWD7CNpG4rZ8i4JKUKT81mSWWjK25bmIvhfH4JqMRDc1A2Rxe2RWlsF2Wy0 Wx/sKzSNsadM/+bfln0TCPinObdS5Y3yw399U=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NehwCKFg2ZMvwhBAGN+83CXtz1NYeSK2nhwuQtvNPpktdDeW4yBUL69ouZxLzpdb4q o58H5xAixkRHLXQhF9qPzme7bSC5aaKukJaJByMKMwQyq4XoX6xhLbHu/GtSHejf1O28 AoIpCe/Me84hHtCwBCLwizFu93VLcmIFozO1E=
Received: by 10.227.199.210 with SMTP id et18mr428604wbb.227.1299569738258; Mon, 07 Mar 2011 23:35:38 -0800 (PST)
Received: from [10.0.0.2] (93-173-136-159.bb.netvision.net.il [93.173.136.159]) by mx.google.com with ESMTPS id bd8sm364848wbb.13.2011.03.07.23.35.35 (version=SSLv3 cipher=OTHER); Mon, 07 Mar 2011 23:35:37 -0800 (PST)
Message-ID: <4D75DC45.6080309@gmail.com>
Date: Tue, 08 Mar 2011 09:35:33 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8
MIME-Version: 1.0
To: Glen Zorn <gwz@net-zen.net>
References: <4D73575C.6090808@gmail.com> <4D75B5ED.1050108@net-zen.net>
In-Reply-To: <4D75B5ED.1050108@net-zen.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 07 Mar 2011 23:59:23 -0800
Cc: IPsecme WG <ipsec@ietf.org>, Yoav Nir <ynir@checkpoint.com>, Paul Hoffman <paul.hoffman@vpnc.org>, hokey@ietf.org
Subject: Re: [HOKEY] Fwd: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis
X-BeenThere: hokey@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HOKEY WG Mailing List <hokey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hokey>
List-Post: <mailto:hokey@ietf.org>
List-Help: <mailto:hokey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hokey>, <mailto:hokey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Mar 2011 07:34:26 -0000

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 <ynir@checkpoint.com>
>> To: ipsec@ietf.org <ipsec@ietf.org>rg>,
>> draft-ietf-hokey-rfc5296bis@tools.ietf.org
>> <draft-ietf-hokey-rfc5296bis@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
>>
>>