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

Paul Wouters <paul@cypherpunks.ca> Tue, 04 March 2014 11:08 UTC

Return-Path: <paul@cypherpunks.ca>
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 BE2FF1A06E3 for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:08:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Js2yuZz29OJo for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:08:48 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8431A06CD for <ipsec@ietf.org>; Tue, 4 Mar 2014 03:08:48 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6AD90800AF; Tue, 4 Mar 2014 06:08:44 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s24B8h1b005345; Tue, 4 Mar 2014 06:08:44 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Tue, 04 Mar 2014 06:08:43 -0500
From: Paul Wouters <paul@cypherpunks.ca>
X-X-Sender: paul@bofh.nohats.ca
To: Tero Kivinen <kivinen@iki.fi>
In-Reply-To: <21269.44464.979543.950214@fireball.kivinen.iki.fi>
Message-ID: <alpine.LFD.2.10.1403040603500.1910@bofh.nohats.ca>
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>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wK8ibqYuy_hduM8fBYjmLQcq9IU
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: Tue, 04 Mar 2014 11:08:51 -0000

On Tue, 4 Mar 2014, Tero Kivinen wrote:

>> I have actually thought about a mode where we scramble the order or
>> payloads just to see which implementations would die :P
>
> That only works for RFC5996 version, RFC4306 version are allowed to
> reject packets which have payloads in "wrong" order:

I did not realise IKEv1 did not allow that. How quaint....

> And for example my ID parsing code already checks that there must be 4
> bytes of data, if the ID type is ID_TYPE_IPV4_ADDR, and will return
> error immediately there if that is not true. This is way before I even
> start checking what is the authentication type etc.

That's exactly how we do it. Parse each payload and store it, throw an
immediate error if any of these are wrong. Then lookup the SPIs, find
the right state and check if all required payloads are there and all
other payloads are valid optional payloads, and only then proceed with
processing.

> This is not anonymous method, this is unauthenticated method. We
> cannot really provide anonymity with this method.

Okay, I guess we disagree.

>> And I feel that I need to reject anonymous connections that have an ID
>> to protect the anonymity of the user.
>
> 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.

Paul