IETF Logo Mail Archive

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

"Valery Smyslov" <svanru@gmail.com> Tue, 04 March 2014 11:23 UTC

Return-Path: <svanru@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 A75CF1A0721 for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:23:35 -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 7nwWHoQJC7mc for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:23:34 -0800 (PST)
Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id BADC21A0713 for <ipsec@ietf.org>; Tue, 4 Mar 2014 03:23:33 -0800 (PST)
Received: by mail-la0-f46.google.com with SMTP id hr17so5536316lab.33 for <ipsec@ietf.org>; Tue, 04 Mar 2014 03:23:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=o20g0Va+86lB24mhECM6LpHMXE1+PIrfp12IhIBOcBc=; b=yWqYQrRJMjQO84XH6fMxyv1wezme2nd4vCAwrSsvWviV+N5vGRjsK0YJUKAaX0xYGd SOpLuUS3K3BWdT4gGm6RZSYxMyTC7uSEWOW8jIU7Dw6REyvm8zQyI1wuNaoyJbXme7Iz Z/xOX3RfQSJ26cK31UfgNGxBS7aSKSecUOJTt0zqIsrFnfYILFTMfIXXCCMga1R2PA6P 5U3xcyh1UpMeGAaHcjTbW/i4fWfPZNWOvqbc5vA7Qg9YCOLyfBoCOUiQy4Mt8MVDgSM6 0QydQRXVa63d/9dCRCdlyMA/F6ISXoTEAVtlqCOOEoG5K29JZp8f9584fIaD+HdIfZV1 eeLQ==
X-Received: by 10.152.9.1 with SMTP id v1mr14596298laa.31.1393932209633; Tue, 04 Mar 2014 03:23:29 -0800 (PST)
Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id mo3sm19355981lbb.17.2014.03.04.03.23.28 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 04 Mar 2014 03:23:28 -0800 (PST)
Message-ID: <C165B0187EAE46DB9B9AC3DD97338DEA@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: Paul Wouters <paul@cypherpunks.ca>, Tero Kivinen <kivinen@iki.fi>
References: <B1B032692C7045B7AEA06166F8AC9B9F@buildpc> <21268.39396.785431.297271@fireball.kivinen.iki.fi> <01FD5F789A0A406F9CCFC3033EA6721B@buildpc> <alpine.LFD.2.10.1403040450410.1910@bofh.nohats.ca> <21269.44464.979543.950214@fireball.kivinen.iki.fi> <alpine.LFD.2.10.1403040603500.1910@bofh.nohats.ca>
Date: Tue, 04 Mar 2014 15:23:46 +0400
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/lroKP2gXaJVAtvyfnXTQgCnLEL4
Cc: ipsec@ietf.org
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: Tue, 04 Mar 2014 11:23:36 -0000

>> But should you reject unauthenticated connections just because they
>> have ID which you are not authenticating anyways.
> 
> Yes I think so. You are changing the meaning of ID from implicitely
> "verified ID" to potentially "unverified ID". I think that is wrong.

But what prevent you from throwing away ID content in this case,
as you know that it is unauthenticated (you may even not to log it), 
and allow user to connect? User has already exposed the
content of ID, the damage (if any) has already occured,
so what you will you protect by rejecting the connection?

Regards,
Valery.

> Paul

v2.23.0 | Report a Bug | By Email