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

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 04 March 2014 21:15 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 19CE01A02F8 for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 13:15:24 -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 QyEiRTcCe_rv for <ipsec@ietfa.amsl.com>; Tue, 4 Mar 2014 13:15:21 -0800 (PST)
Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2021A02D6 for <ipsec@ietf.org>; Tue, 4 Mar 2014 13:15:21 -0800 (PST)
Received: by mail-we0-f171.google.com with SMTP id t61so126832wes.16 for <ipsec@ietf.org>; Tue, 04 Mar 2014 13:15:17 -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=97J+OrqOzxiPadxroIs9B2RPzG6Z0zt4kshgiEknruM=; b=SAy+eu0U6cvmFJ925+oAy58LKttNVyLpAKIUGHznW9SC1xrnqc5ntr3eajStb9ZW+i i5f51TtU4QkfaCo9en64rdqQr+dXkntVodkOgY4SczYttcw0e3KN099H6GmiinMWqAjK LdUn1M0Cb1xkKeGB0V3vubHEzfYVgQBc0YeB95ykfWPi59vIUVHmcbhho5QtO6bor+Nx EkIn/GGtaBAGwtB4u/tkvkfgP+KT3l3NEPQSWtyvyYI6L2c6G9pK4Wo+VMUBQMO+/bvW JOmmENyD3NpZL/t2gnelFhIHmCCcHZxTJAXioku7Kyt6viWKDUyPITSwtkLKBudtIYS+ s5Tw==
X-Received: by 10.195.12.102 with SMTP id ep6mr2717224wjd.76.1393967717655; Tue, 04 Mar 2014 13:15:17 -0800 (PST)
Received: from [10.0.0.6] ([109.65.63.189]) by mx.google.com with ESMTPSA id ci4sm621282wjc.21.2014.03.04.13.15.16 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Mar 2014 13:15:17 -0800 (PST)
Message-ID: <53164262.6010700@gmail.com>
Date: Tue, 04 Mar 2014 23:15:14 +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: Tero Kivinen <kivinen@iki.fi>, Paul Wouters <paul@cypherpunks.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> <21269.47282.170859.595467@fireball.kivinen.iki.fi>
In-Reply-To: <21269.47282.170859.595467@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/L12x5_Pqb8jTIsCDVgcbbA9EmtU
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 21:15:24 -0000

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

And once we start using raw public keys (or self signed certs), we can 
use out-of-band means to upgrade the identity from "claimed but 
unauthenticated" to "authenticated". This is what we're proposing in 
AutoVPN.

Thanks,
	Yaron