[IPsec] Please Review Changes to AD VPN Problem Statement

Tero Kivinen <kivinen@iki.fi> Fri, 19 April 2013 12:10 UTC

Return-Path: <kivinen@iki.fi>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E59D521F8F67 for <ipsec@ietfa.amsl.com>; Fri, 19 Apr 2013 05:10:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hbb3Q+orBd93 for <ipsec@ietfa.amsl.com>; Fri, 19 Apr 2013 05:10:08 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.acr.fi []) by ietfa.amsl.com (Postfix) with ESMTP id 0A5EC21F8F63 for <ipsec@ietf.org>; Fri, 19 Apr 2013 05:10:07 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost []) by mail.kivinen.iki.fi (8.14.5/8.14.5) with ESMTP id r3JC8k47023369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Apr 2013 15:08:46 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.5/8.12.11) id r3JC8jkq019013; Fri, 19 Apr 2013 15:08:45 +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: <20849.13261.464684.303138@fireball.kivinen.iki.fi>
Date: Fri, 19 Apr 2013 15:08:45 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Stephen Hanna <shanna@juniper.net>
In-Reply-To: <F1DFC16DCAA7D3468651A5A776D5796E1A91DA6C@SN2PRD0510MB372.namprd05.prod.outlook.com>
References: <20130409025346.7391.95143.idtracker@ietfa.amsl.com> <F1DFC16DCAA7D3468651A5A776D5796E1A91DA6C@SN2PRD0510MB372.namprd05.prod.outlook.com>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 10 min
X-Total-Time: 9 min
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: [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: Fri, 19 Apr 2013 12:10:09 -0000

Stephen Hanna writes:
> I have posted a new version of the AD VPN Problem
> Statement that adds clarifying text to requirements
> 6 and 7, as suggested by Tero. Please review and
> comment. Is everyone (especially Tero) OK with the
> new text?

Those requirement 6 and 7 seems to be ok, but I am still bit concerned
about the requirement 5.

It seems to be bit too strict, and will forbid all kind of trusted 3rd
party where the trusted 3rd party is any of the ADVPN peers. This of
course rules out that temporary credentials cannot be any kind of
shared secrets given out by the spoke, but it also forbids the spoke
to act as introductioner and sending for example the hash of the
end-points public key to the other end-point, and saying this public
key hash matches that peer.

The requirement 5 is:
   5.  One ADVPN peer MUST NOT be able to impersonate another ADVPN

   This requirement is driven by use case 2.1.  ADVPN peers (especially
   spokes) become compromised fairly often.  The compromise of one ADVPN
   peer SHOULD NOT affect the security of other peers.

If endpoint receives any kind of intrduction, or credential
information from any other node from the ADVPN, that means that the
node giving that information out can impersonate that other ADVPN

I.e. if endpoint A asks from spoke or hub S how endpoint B is
authenticated, and where it is located, so it can take direct
connection to it, the compromised spoke or hub S can provide incorrect
credentials for the endpoint A claiming endpoint A's public key is Sp
instead Bp, and do the same for endpoint B. It can also claim that
endpoint B is located in his ownIP-address, so when endpoint A tries
to move to point-to-point communication mode, it actually still goes
through the S, as S can impersonate to be the other end.

If the requirement 5 stays as it is, the only way I can think how
authentication can be done is by using some other 3rd party which is
not ADVPN peer.

I think what is tried to be said here, is that any of the ADVPN peers
MUST NOT have a way to get the long term authentication credentials
for any othe ADVPN peers. The ADVPN peer giving out some kind of
temporary authentication credentials, or providing information to
other ADVPN peers how to authenticate some other ADVPN peer can still
give out false information and cause possibility for ADVPN peer to
impersonate some other ADVPN peer.