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

Tero Kivinen <kivinen@iki.fi> Tue, 04 March 2014 11:28 UTC

Return-Path: <kivinen@iki.fi>
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 4D67C1A0727 for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:28:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, 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 oC1ttpTA481k for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 03:27:57 -0800 (PST)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2541A06B9 for <ipsec@ietf.org>; Tue, 4 Mar 2014 03:27:56 -0800 (PST)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.7/8.14.5) with ESMTP id s24BRkP2013406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 Mar 2014 13:27:46 +0200 (EET)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.7/8.12.11) id s24BRkSk019928; Tue, 4 Mar 2014 13:27:46 +0200 (EET)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <21269.47282.170859.595467@fireball.kivinen.iki.fi>
Date: Tue, 4 Mar 2014 13:27:46 +0200
From: Tero Kivinen <kivinen@iki.fi>
To: Paul Wouters <paul@cypherpunks.ca>
In-Reply-To: <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> <alpine.LFD.2.10.1403040603500.1910@bofh.nohats.ca>
X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd)
X-Edit-Time: 13 min
X-Total-Time: 13 min
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ezg4RUyMZZ-k_iEyYIoKQ_QN5E8
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:28:00 -0000

Paul Wouters writes:
> 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....

IKEv1 did allow sending payloads in any order, if I remember right.
RFC4306 is original IKEv2, not IKEv1...

> > 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.

The draft name is null-auth, and for me that means there is
no authentication. The abstract says it "may be used to preserve
anonymity" (one use case, it does not say it do provide anonymity),
and another use case is "in situations, where there no
trustrelationship exists between the parties.". This second use case
does not have anything to do with anonymity just unauthenticated
connections.

And the whole idea is to "omit peer authentication".

Hmm... funny typo in section 1:

   o  User wants to get anonymous access to some resource.  In this
      situation he/she should be able to authenticate server, but to
      leave out his/her own authentication to prevent anonymity.  In
      this case one-way authentication is desirable.

user will leave out authentication to PREVENT anonymity... I assume
preserve is the one word that was meant...

The second use case does not require any anonymity:

   o  Two peers without any trust relationship want to get some level of
      security in their communications.  Without trust relationship they
      cannot prevent active Man-in-the-Middle attacks, but it is still
      possible to prevent passive eavesdropping with opportunistic
      encryption.  In this case they have to perform unauthenticated key
      exchange.

Actually even the first use case, having non-authenticated identity
would still be useful in some cases. For example if I will protect my
home server with null-authenticated IPsec, people most likely will
still want to verify my servers authentication, and they might want to
provide meaningful unauthenticated ID, even when it is not needed. The
meaningful ID might be something that is not meaningful in global
context, but it might be meaningful for me, i.e. just nickname or
similar.

If they want to do something where I would require them to do
authentication then I would most likely still use my (self signed)
certificate based authentication for server (with certificate pinning
and TLSA records in DNSSEC signed zone), and they would use similar
locally meaningful ID and raw public key to authenticate themselves to
my server.

I.e. I will see the upgrade path from null-auth -> raw public keys
very logical in small private use setups.
-- 
kivinen@iki.fi