Re: [IPsec] Comments to draft-ietf-ipsecme-eap-mutual-02.txt

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 18 May 2010 16:57 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A793A6A87 for <ipsec@core3.amsl.com>; Tue, 18 May 2010 09:57:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599]
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 z7ZPvBjFBBwy for <ipsec@core3.amsl.com>; Tue, 18 May 2010 09:57:28 -0700 (PDT)
Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by core3.amsl.com (Postfix) with ESMTP id 28FA53A688E for <ipsec@ietf.org>; Tue, 18 May 2010 09:56:58 -0700 (PDT)
Received: by wyf19 with SMTP id 19so1262354wyf.27 for <ipsec@ietf.org>; Tue, 18 May 2010 09:56:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=BTYwbU/JGjQ7dCa2wbkY24ae2MWjBSNIQGJ7OjcXvPM=; b=NvCNvGTlO6qCpSTr6KEivuWxpKb3YrCmVVvq4KaIQk/AZceebYxBI97IXOSmhAirMZ uXuqvROBNUbUEJieTegTTUq1hL5qyj0m0hHmq+ASMVkkMfw9C4GWSEgqknn9KkRrH5Um NJnYg9JC0s9RfdqO/+a8ho8utj691YXJs/3eQ=
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=u8PdxDVjqyEtkoKWqH9w/TQKeBSWhJMWhkqUhL8Y2iUUIVDiZ1DhdEwdeSOx3jupPE WxCSKekHNsrMzwGgmz7EKAJWAj8C3TN/RyR1AGzNFal8VOjpTjBAwWGZVzexJY+K7ers bxx51LWhGn24imnUyRxfDz7idR7EKZY7ouuzw=
Received: by 10.227.157.198 with SMTP id c6mr6484862wbx.173.1274201807176; Tue, 18 May 2010 09:56:47 -0700 (PDT)
Received: from [10.0.0.2] ([109.64.46.151]) by mx.google.com with ESMTPS id u36sm16670472wbv.18.2010.05.18.09.56.45 (version=SSLv3 cipher=RC4-MD5); Tue, 18 May 2010 09:56:46 -0700 (PDT)
Message-ID: <4BF2C6CB.2060907@gmail.com>
Date: Tue, 18 May 2010 19:56:43 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <19442.36613.651993.353644@fireball.kivinen.iki.fi>
In-Reply-To: <19442.36613.651993.353644@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Comments to draft-ietf-ipsecme-eap-mutual-02.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 18 May 2010 16:57:29 -0000

Hi Tero,

thanks for your comments. I (obviously) disagree with your position on 
EAP, but I'll leave it at that. The WG decided we will specify this 
extension, and the market will decide in what exact scenarios it is, or 
isn't, useful.

I will change the text in Sec. 3.

Regards,
	Yaron

On 05/18/2010 03:58 PM, Tero Kivinen wrote:
> I read this document and it seems to be mostly ok.
>
> I might disagree on some parts of the section 1 text talking why EAP
> is needed (I think the main reason was to support legacy systems. The
> public keys are flexible enough to meet requirements of many
> deployment scenarios unless your requirement includes "that must
> support old legacy infrastructure"), but I do not think there is need
> to change text there.
>
> The section 3 should add text telling what protocol ID is used for the
> notification, just like most of the other extensions do: "Protocol ID
> and the SPI Size fields MUST both be sent as 0.", i.e. change:
>
>                                               The SPI size field is set
>     to zero, and there is no additional data associated with this
>     notification.
>
> to
>
>                             The protocol ID and SPI size fields are set
>     to zero, and there is no additional data associated with this
>     notification.