Subject: [saag] looking to hold a TLS VPN side meeting at IETF 92

From: "Boyle, Vincent M" <[email-masked]>
Date: Fri, 13 Mar 2015 17:11:29 +0000

Hi all,
                I'm planning to hold a side meeting at IETF 92 to gauge interest in creating a standard for TLS VPNs. One motivating use case for my organization is the need to  protect data between an app on a mobile device and the enterprise network that it connects to.  For many of our customers, a TLS-based solution is preferable to IPSec (perhaps because their vendors support the former). For some sensitive military applications, there is a requirement to provide two layers of encryption, so using TLS for the second layer makes sense. Having each app invoke TLS is problematic because it introduces validation costs for each app before it is deployed (to ensure that it correctly implements TLS or makes the appropriate OS calls). We would prefer the option of validating a TLS VPN product and having it available for use by all apps on the device. To create the necessary validation requirements and test activities, we need to have a standard that we can point to.  The development of an open standard would provide a consistent and fair method of measuring security (using Protection Profiles) which scales to enable the validation and testing of TLS VPNs.

                Beyond this specific (but fairly pressing) use case, we believe that there are many organizations that would benefit from the availability of a standards-based, validated mechanism to protect communications between their mobile devices and the enterprise network.

                Please discuss on the  saag mail list. I will schedule a meeting time at a local drinking establishment for either Monday or Wednesday at 7:30 PM (local Dallas time). I'd appreciate feedback on the meeting times (if you expect to attend) as well as any comment on the usefulness or feasibility of this effort.

Thanks,
Mike Boyle
Standards Lead
Information Assurance Directorate, NSA

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 14 Mar 2015 18:20:42 +0100

On Fri, 2015-03-13 at 17:11 +0000, Boyle, Vincent M wrote:
> Hi all,
> 
>                 I’m planning to hold a side meeting at IETF 92 to
> gauge interest in creating a standard for TLS VPNs. One motivating use
> case for my organization is the need to  protect data between an app
> on a mobile device and the enterprise network that it connects to.
> For many of our customers, a TLS-based solution is preferable to IPSec
> (perhaps because their vendors support the former).

I'm certainly interested though I will not be at the meeting. I already
work on documenting -and implementing- such a protocol:
https://github.com/openconnect/protocol so a standardized variant is
certainly a good thing.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Sat, 14 Mar 2015 10:23:34 -0700

> https://github.com/openconnect/protocol so a standardized variant is

Isn't this exactly what OpenVPN does? It seems to me that we should
not reinvent the wheel, but instead focus on documenting existing work
and learning from experience.

>
> regards,
> Nikos
>
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Aaron Zauner <[email-masked]>
Date: Sat, 14 Mar 2015 18:31:21 +0100

> and learning from experience.

No. OpenVPN uses a duplexed connection (data, metadata), they
authenticate with TLS but from thereon they drop to AES-CBC
encrypt-then-mac.

Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 14 Mar 2015 18:40:54 +0100

> and learning from experience.

No it is not. We should check before we talk also.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 Mar 2015 20:21:34 +0200

Hi, Mike

>                 Please discuss on the  saag mail list. I will schedule a meeting time at a local drinking establishment for either Monday or Wednesday at 7:30 PM (local Dallas time). I’d appreciate feedback on the meeting times (if you expect to attend) as well as any comment on the usefulness or feasibility of this effort.

On Wednesday there is going to be a I2NSF side meeting that is likely to attract many of the same people. I would go with Monday.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 14 Mar 2015 18:26:34 +0000

> Isn't this exactly what OpenVPN does? It seems to me that we should not
> reinvent the wheel, but instead focus on documenting existing work and
> learning from experience.

Don't jump to conclusions; it could be that's "all" that's done.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 Mar 2015 20:36:03 +0200

> On Mar 14, 2015, at 7:23 PM, Watson Ladd <[email-masked]> wrote:
> 

No, but SSL VPNs are for the most part proprietary protocols, so each vendor has their own. The sort-of exception is Microsoft’s SSTP comes pre-packaged with Windows, so vendors could rely on it rather than allowing you to download the client from a portal.

The thing is that standardizing a protocol is only good where interoperability is required, so that one vendor’s client works with another vendor’s server. This is important in many applications, but hasn’t been in remote access VPNs, for which SSL is one technology. 

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Sat, 14 Mar 2015 14:38:04 -0400 (EDT)

On Sat, 14 Mar 2015, Yoav Nir wrote:

> Hi, Mike
>                       Please discuss on the  saag mail list. I will schedule a meeting time at a local
>       drinking establishment for either Monday or Wednesday at 7:30 PM (local Dallas time). I’d
>       appreciate feedback on the meeting times (if you expect to attend) as well as any comment on the
>       usefulness or feasibility of this effort.
> 
> 

Monday there will be an openpgp side meeting that is likely to attract
many of the same people.

Paul

---

From: Michael Richardson <[email-masked]>
Date: Sat, 14 Mar 2015 15:47:49 -0400

I sure hope that you will give us a definition of a TLS VPN.
It's really important that we know what is in scope and what is not.
My take is that solutions that run TCP and/or HTTPS proxy over TLS,
are not TLS VPNs, because they don't pass the "N"etwork part of
VPN.  They are useful mechanisms, and I'm all for standardizing them, but
the word VPN should not be applied.

OpenVPN is a TLS keyed VPN.  It can and does run over a single TCP port, but
that has congestion issues (tcp over tcp), so running the data part it over
UDP is preferrale, but not always possible.
(Meanwhile,there are IPsec vendors that run ESP over TCP in non-standard
fashions...)

I'd like to see some convergence at the dataplane side.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Boyle, Vincent M" <[email-masked]>
Date: Tue, 17 Mar 2015 12:10:18 +0000

I appreciate all the discussion on the list. To clarify a couple points, we don't have a fixed idea what a TLS VPN standards should look like. Rather, we have requirements, such as the ability to support mobile devices connecting back to an enterprise network. We also want to come up with a solution that would work with another layer of encryption (likely IPSec), without getting into fights in the kernel. I'm particularly interested to hear people's thoughts on that, as it has been a problem for us in the past (in situations where we don't employ virtualization). As others already said, interoperability between clients and servers of different vendors is highly desirable as well. I already mentioned that we need a standard to build our security testing around. I guess that's more a requirement for *any* standard, not a particular technical requirement.

Also, I want to second PHB's observation that we're not looking for new technology. We really want to leverage what's already available and get consensus on a standard that has good security properties and will promote interoperability. 

So, after hearing about some conflicts with other side meetings I'm leaning toward the Wednesday at 7:30 timeslot. I'll research a venue and send out an announcement tomorrow.

Mike

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 17 Mar 2015 13:24:48 +0100

> Also, I want to second PHB's observation that we're not looking for new technology. We really want to leverage what's already available and get consensus on a standard that has good security proper…

That is good on itself, but note that because of the ad-hoc designs of
SSL VPNs very few (to none) of them have good security properties.
Attempting to even document one of them is a non-trivial task due to
legacy cruft these systems carry. It's no surprise that none of these
systems have a single page of protocol description. While documenting
such a historic system would be a good first step, I hope it would
lead eventually to the design of a decent VPN protocol based on
SSL/TLS. With certain SSL VPNs that can be done in a backwards
compatible way, others cannot be extended at all.

regards,
Nikos

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Mar 2015 09:37:04 -0400

On Tue, Mar 17, 2015 at 8:10 AM, Boyle, Vincent M <[email-masked]> wrote:

> I appreciate all the discussion on the list. To clarify a couple points,
> we don't have a fixed idea what a TLS VPN standards should look like.
> Rather, we have requirements, such as the ability to support mobile devices
> connecting back to an enterprise network. We also want to come up with a
> solution that would work with another layer of encryption (likely IPSec),
> without getting into fights in the kernel. I'm particularly interested to
> hear people's thoughts on that, as it has been a problem for us in the past
> (in situations where we don't employ virtualization). As others already
> said, interoperability between clients and servers of different vendors is
> highly desirable as well. I already mentioned that we need a standard to
> build our security testing around. I guess that's more a requirement for
> *any* standard, not a particular technical requirement.
>
> Also, I want to second PHB's observation that we're not looking for new
> technology. We really want to leverage what's already available and get
> consensus on a standard that has good security properties and will promote
> interoperability.
>
> So, after hearing about some conflicts with other side meetings I'm
> leaning toward the Wednesday at 7:30 timeslot. I'll research a venue and
> send out an announcement tomorrow.
>

I think it would also be very worthwhile considering the intersection of
DPRIV and TLSVPN.

My proposal for DPRIV (and several others) replaces the traditional method
of configuring the recursive by IP address alone with a TLS based protocol
to establish a long term session between the client and the service. This
includes one or more hosts delivering the service and the corresponding
cryptographic parameters.

That session binding component could be shared between a DNS Privacy
protocol and a TLS VPN protocol.

The practical impact of this would be single point configuration for the
end user. End users do not want to have to configure their devices to do
DNS and then configure them for email and then configure them for the VPN
and then configure the dozen other protocols that they need to use.

Consider the case that Alice takes a job with the State Department and
wants to have access to all the State Dept material on the phone while
still being able to use the same phone to plan her daughter's wedding.

As far as Alice is concerned, this should be a one time configuration, she
types in the domain name she is given "it.state.gov" and the passcode
"1234" and the device asks "do you want to use this service for services in
*.state.gov". She says 'yes' and as far as she is concerned the job is done.

Under the covers the principal changes are that the device will now direct
all DNS requests for *.state.gov to their service over DPRIV protocol.

This is the place where I would also put the hook for a TLSVPN and the
reason I would want the two configurations to be tied together. Because
when we are using split horizon DNS we want to map the 10.x.x.x and
192.168.x.x space into the address space of the target network rather than
the local network.

Having had my wife trying to make use of a printer on our home network in
192.168.1.x space from a machine logged into a VPN in 192.168.1.x space,
this is certainly a concern.

So in my view, one reason to consider a standards effort in IETF would be
that if DPRIV does the job the right way, it will make it much easier to
provide a seamless end user experience. The current problem with VPNs in my
experience is that they are as reliable as a high school science
experiment.

If DPRIV is going to get widely adopted then it is going to have to find a
group of early adopters. VPNs remain a source of real and lasting pain for
end users. All the ones on the market today are very high administration.
The only way that is going to get fixed is if the platforms start to
support VPN in ways that meet enterprise needs in practice.