Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.txt

Yaron Sheffer <yaronf.ietf@gmail.com> Mon, 03 March 2014 23:04 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B431A027E for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 15:04:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPcfGz9-eAmV for <ipsec@ietfa.amsl.com>; Mon, 3 Mar 2014 15:04:45 -0800 (PST)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id F07CA1A0269 for <ipsec@ietf.org>; Mon, 3 Mar 2014 15:04:44 -0800 (PST)
Received: by mail-we0-f180.google.com with SMTP id p61so2826127wes.25 for <ipsec@ietf.org>; Mon, 03 Mar 2014 15:04:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=conpgL0rqIY3LnZzmDxVEqcIOpNThy0xc7ZF5hrAqmo=; b=D/KheFXw2ygR+XIt8LB81gtHj2/rEEPTr5X6/j8WmrG/X2QWO+G4v/qX/2LN0xiv2z YADBHDSQx6/rcNZhkT4/K3Pb8+FPqg90N/GBikijH+gnlgKQRDoMvz/J9bSCmlZmMMQt FYp65bQaZ+Me97hTsWhco1PAoYET5qIKD5KhUdJB8D1OTKWNCsYrP7y7b2dXhgwam2N0 i4a90nPL7/RX1DaUyjzAvxbwWSV7UnQHlZNtWSaqW12D1LANgfkY0RculdJjo//PCbft /rDP/nFXBgpehtfBanUMSZX5zBMRmDdcd3c8Rg/GFBiMMYRTnUoN3Npcp9H2R70iWHJo n88A==
X-Received: by 10.194.91.232 with SMTP id ch8mr22279011wjb.13.1393887881403; Mon, 03 Mar 2014 15:04:41 -0800 (PST)
Received: from [10.0.0.6] ([109.65.63.189]) by mx.google.com with ESMTPSA id xt1sm42540470wjb.17.2014.03.03.15.04.40 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Mar 2014 15:04:41 -0800 (PST)
Message-ID: <53150A87.6030305@gmail.com>
Date: Tue, 04 Mar 2014 01:04:39 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Paul Wouters <paul@cypherpunks.ca>, Tero Kivinen <kivinen@iki.fi>
References: <B1B032692C7045B7AEA06166F8AC9B9F@buildpc> <21268.39396.785431.297271@fireball.kivinen.iki.fi> <alpine.LFD.2.10.1403031755040.4233@bofh.nohats.ca>
In-Reply-To: <alpine.LFD.2.10.1403031755040.4233@bofh.nohats.ca>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/FYPnbRNCjQtjqtHAeHpk_B94iyc
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Valery Smyslov <svanru@gmail.com>
Subject: Re: [IPsec] Fw: New Version Notification for draft-smyslov-ipsecme-ikev2-null-auth-01.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 03 Mar 2014 23:04:47 -0000

Hi Paul,

Quoting from the abstract: "This method may be used to preserve 
anonymity or in situations, where no trust relationship exists between 
the parties." You seem to assume that all clients want to be anonymous. 
IMHO "unauthenticated" does not necessarily imply "anonymous". When I 
talk to someone on the plane and they tell me their name, they are not 
authenticated and they may well be lying. But in general, they are not 
anonymous either.

Thanks,
	Yaron

On 03/04/2014 12:57 AM, Paul Wouters wrote:
> On Mon, 3 Mar 2014, Tero Kivinen wrote:
>
>> It would be better to say that if you are sending empty ID payload,
>> you msut use ID_KEY_ID type which already allows any data, including
>> empty.
>
> That could work, if we really don't want to allow this document to
> change the ID payload from mandatory to optional (which I would prefer)
>
>> Actually I now noticed you changed the "SHOULD be ignored" to "MUST be
>> ignored", and I think that is again bad idea. I think logging and
>> auditing the ID for problem solving purposes is good idea even if it
>> does not have any meaning for the authentication. I.e. at least then I
>> can contact helpdesk and say that my NULL authentication connection to
>> server 1.2.3.4 failed, and I have no idea why, can you help. Oh, my ID
>> payload had ID_KEY_ID 0324234mkdsff43r5, if that helps you to find it
>> from your logs...
>
> I disagree strongly. The point here is that the client is anonymous. We
> should not add things that can be traced to a user. Someone will badly
> abuse this "feature" like you are suggesting for "diagnostics" and
> inadvertly compromise the client's anonimity.
>
> Paul
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec