Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-05.txt

From: [email-masked]
Date: Mon, 08 Apr 2013 19:53:46 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF.

	Title           : Auto Discovery VPN Problem Statement and Requirements
	Author(s)       : Steve Hanna
                          Vishwas Manral
	Filename        : draft-ietf-ipsecme-ad-vpn-problem-05.txt
	Pages           : 11
	Date            : 2013-04-08

Abstract:
   This document describes the problem of enabling a large number of
   systems to communicate directly using IPsec to protect the traffic
   between them.  It then expands on the requirements, for such a
   solution.

   Manual configuration of all possible tunnels is too cumbersome in
   many such cases.  In other cases the IP address of endpoints change
   or the endpoints may be behind NAT gateways, making static
   configuration impossible.  The Auto Discovery VPN solution will
   address these requirements.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ad-vpn-problem

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-ipsecme-ad-vpn-problem-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ad-vpn-problem-05

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 9 Apr 2013 03:00:23 +0000

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?

The new draft is available at

Since the changes are few, it may be easier for you
to look at the diff linked to here:

Thanks,

Steve

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Monday, April 08, 2013 10:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ad-vpn-problem-05.txt
> 
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 19 Apr 2013 15:08:45 +0300

> comment. Is everyone (especially Tero) OK with the

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

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

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.
-- 
[email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 19 Apr 2013 22:05:47 +0000

Tero,

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.

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.

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.

Thanks,

Steve

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 22 Apr 2013 15:08:43 +0300

> A compromised endpoint shouldn't be able to impersonate

I agree. 

> > of communications between other Peers.
				    ^^^^^ => ADVPN Peers

> 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...
-- 
[email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 22 Apr 2013 12:57:20 +0000

Tero,

Thanks for your additional suggestions. I agree with
those also. I will post a revised draft shortly
containing the text that we have agreed upon.

Take care,

Steve

> Of Tero Kivinen
> Sent: Monday, April 22, 2013 8:09 AM
> To: Stephen Hanna
> Cc: [email-masked]
> Subject: Re: [IPsec] Please Review Changes to AD VPN Problem Statement
> 
> Stephen Hanna writes: