Re: [IPsec] Please Review Changes to AD VPN Problem Statement

Tero Kivinen <kivinen@iki.fi> Mon, 22 April 2013 12:08 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0476D21F902A for <ipsec@ietfa.amsl.com>; Mon, 22 Apr 2013 05:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY-aTXlcKYvi for <ipsec@ietfa.amsl.com>; Mon, 22 Apr 2013 05:08:51 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5D21F9029 for <ipsec@ietf.org>; Mon, 22 Apr 2013 05:08:50 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3MC8iS1023679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Apr 2013 15:08:44 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3MC8hT6019004; Mon, 22 Apr 2013 15:08:43 +0300 (EEST)
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: <20853.10315.629195.503822@fireball.kivinen.iki.fi>
Date: Mon, 22 Apr 2013 15:08:43 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Stephen Hanna <shanna@juniper.net>
In-Reply-To: <F1DFC16DCAA7D3468651A5A776D5796E1A95871E@SN2PRD0510MB372.namprd05.prod.outlook.com>
References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> <F1DFC16DCAA7D3468651A5A776D5796E1A91DA6C@SN2PRD0510MB372.namprd05.prod.outlook.com> <20849.13261.464684.303138@fireball.kivinen.iki.fi> <F1DFC16DCAA7D3468651A5A776D5796E1A95871E@SN2PRD0510MB372.namprd05.prod.outlook.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 12 min
X-Total-Time: 11 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.12
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, 22 Apr 2013 12:08:52 -0000

Stephen Hanna writes:
> I agree with you that requirement 5 as currently worded
> is too strict. We don't want to end up with a situation
> where no ADVPN peers can participate in the establishment
> of the ADVPN! On the other hand, we want to limit the
> effects of the compromise of an endpoint because endpoint
> compromise (not gateway compromise) is a common occurrence.
> A compromised endpoint shouldn't be able to impersonate
> other peers.

I agree. 

> You proposed this text:
> 
> > Any of the ADVPN peers MUST NOT have a way to get the long
> > term authentication credentials for any other ADVPN peers.
> 
> I think that's correct. But I also think we want to say:
> 
> > The compromise of an Endpoint MUST NOT affect the security
> > of communications between other Peers.
				    ^^^^^ => ADVPN Peers

> Are you OK with replacing the current text for requirement 5
> with those two sentences? I think that will preserve the
> essence of the requirement without making it too strict.

I am ok with those two sentences. Note, that Endpoint does not include
gateways, so the second sentence does not cover the compromize of the
Spokes. I would even add text saying that "The compromize of an
Gateway SHOULD NOT affect the security of the communications between
ADVPN Peers not associated with that Gateway". That last one cannot
easily be MUST NOT, as compromised gateway might be able to do all
kind of tricks to affect the security of other ADVPN Peers, for
example it can try to get the other ADVPN Peers to change their
current Gateway to himself and then it will be able to comprimise
them. Some of those we can protect, but plugging all possible holes
might end up very hard. For example it might be impossible to make so
that the ADVPN Peer who has been out of network for a while, will not
connect back to that compromized Gateway...
-- 
kivinen@iki.fi