RE: It's all over (except for the screaming & shouting) - transition from PPTP

["William Dixon" <wdixon@windows.microsoft.com>]

Alex, because so many people read this list, I feel compelled to correct
some things here, partially because I know many on the list don't use
Windows, so they might now know otherwise.  But also because it might
help understanding of L2TP/IPsec integration designs, and bears a little
on IKEv2 & JFK requirements (legacy auth, non-PKI auth, user vs.
machine, and do they address VPN remote access requirements or not).  

Customers - Yes I also see that many large, but also small, customers
prefer to use the native Microsoft VPN client, which in Win2k & XP's
case supports both PPTP and L2TP/IPsec.  There are many reasons.  But
the major security interest point I've heard from customers is that our
L2TP/IPsec design authenticates both machine and user independently.
And the user authentication supports both legacy passwords, and is
flexible enough to plug in their own auth methods using EAP.  This is a
deployment requirement for many customers that is not well supported in
current IPsec/IKE-only VPN products, and not well adopted in other IETF
work, and not currently addressed in the JFK or IKEv2 work.  IPsec
tunnel mode for remote access using IKECFG & XAUTH died years ago in the
standards process, but obviously is supported by many vendors who have
substantial VPN market share, typically measured by gateway, not by
clients.  The IPRSA work most recently completed to use IPsec tunnel
mode seems to have an unclear status, at least according the web page.
I see their drafts are stuck in the RFC Editor queue, not sure why.
Suffice to say however, that IPSRA's document status isn't blocking
customer IPsec adoption for remote access, and that adopting the Windows
VPN as a client doesn't equal adopting PPTP.  I'd hope the trend of
customers towards using the native VPN client means that customers are
willing to transition to L2TP/IPsec once we get the NAT-T client update
out, and that they finally have a solution for PKI deployment.

Transition from PPTP - A number of things happened in the market from
'98 to '01 that caused customers to move off of PPTP and adopt IPsec
solutions for remote access.  Customers are well served by having a
variety of choices based on IPsec.  I don't think you are seeing
customers transition back to PPTP if they have already deployed a 3rd
party IPsec tunnel mode solution, unless they found that NAT was just
too problematic, even with IPsec-aware NATs percolating slowly into the
infrastructure (which can only allow IPsec tunnel mode, not IPsec
transport mode required by L2TP without NAT-T).  Microsoft has been
committed to L2TP/IPsec for remote access as a replacement for PPTP.  We
shipped the first implementation of this in Windows 2000 Beta2 around
April 1998.  The Win2k VPN connectoid has detection logic called
"automatic mode" to help facilitate transition away from PPTP to
L2TP/IPsec.  The logic checks to see if a machine certificate exists,
and if so, attempts L2TP/IPsec, by first negotiating IKE with machine
cert auth, then L2TP SCCRQ (connection request control message) and all
other L2TP traffic is communicated over the IPsec SA protection.  This
provides an initial mutual machine authentication before a user ID or
the password hash is ever sent to the gateway.  The automatic IPsec
policy created by Win2k/XP/.NET L2TP requires IKE Main Mode machine
certificate authentication and sets the CA root list based on what certs
have been issued to the machine.  Cross-certs, deep-hierarchies, and
non-Microsoft PKI are supported by IPsec in general, so L2TP/IPsec
inherits this.  We only supported certificates for the IKE auth method
in Win2k because we didn't think pre-shared key was secure enough for
this scenario (referencing the published technique to discover IKE weak
preshared key values by Prof. John Pliam), and because we supported only
IKE Main Mode, which limited how a pre-shared key could be used with
many clients - essentially a group-preshared key.  We have actively
campaigned against using a preshared key in general.  The work on RFC
3193 was in progress so we provided the ability to use custom IPsec
policy for L2TP for gateway to gateway VPN connections and to not use
IPsec at all for connecting secure networks that only needed L2TP
encapsulation tunneling services.  This is explained in 
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q240262

Nevertheless, we received significant customer feedback that our
automatic preference for L2TP/IPsec was too aggressive, blocked by NATs,
and PKI was too hard to deploy.  Yet, people wanted to use IPsec instead
of PPTP - understandable.  Thus we changed the Windows XP VPN connectoid
"automatic" preference to be PPTP, and we provided the configuration for
an IKE preshared key in the client VPN config for L2TP/IPSec.  In all
cases the choice can be controlled by the user, and the VPN gateway
administrator or by the VPN client administrator who can bake in the
choice between PPTP and L2TP/IPsec, as well as a pre-shared key, in the
Connection Manager pre-packaged "connection" configuration (has a dial
phone book, VPN server list, custom extension code, etc).  We still
don't recommend preshared key, but it's there if you have to use it.

NAT-Traversal - We are almost done.  It's more than 1 1/2 years after
the Feb '01 drafts for UDP encapsulation, and the significant revision
of draft-02 Feb '02 to use a non-500 UDP port due to IPsec aware NATs.
These drafts are in last call WG, and should solve the remaining
technical blocker for transition from PPTP to L2TP/IPsec for those who
want to use the Windows native VPN client.  The NAT-T drafts also
provide the solution for IPsec tunnel mode VPN clients.  So all
IPsec-based VPN usages are served.

For transition away from PPTP, there remains the PKI deployment issue
which everyone is struggling with.  But there are solutions which scale
to make enrollment and renewal easy in certain environments, and most CA
vendors support web-based PKI enrollment services.  It should only be a
matter of time before customers understand what their options are, the
costs and can choose a solution.  However, I think a significant number
of customers will not deploy PKI as their user authentication mechanism.
The 802.1x wireless community has also been seeing that PKI is still too
hard to deploy, adding user password-based authentication inside a
server-authenticated TLS session.  Thus I think it is a mistake to
believe that even something like PIC will solve the PKI deployment
problem.  I think Son of IKE should provide for password-based
authentication of users, or adopt an EAP or GSS-API method to be
extensible.

Encryption - Win2k-2195 and Service Pack 1 (SP1) released with the high
encryption pack separate and included in the box where allowed.  Win2k
SP2 shipped with the high encryption pack installed by default where
allowed.  The high encryption pack provides 128bit RC4, as well as 3DES
encryption.  Windows XP ships with support for high encryption where
allowed, as will Windows .NET Server.  So using Windows native VPN does
not equal using 40bit RC4.
 
User Authentication - Win2k, XP and .NET Server implementations of PPTP
and L2TP provide user authentication via the normal and standard PPP
authentication mechanisms.  They can do this with legacy userid/password
via PAP, CHAP, MSCHAP, MSCHAPv2, etc and using EAP-TLS (RFC 2716), which
provides user certificate authentication, either using smartcards or
certificates in the user's account on disk.  Also EAP plugins on the
client, gateway and/or Radius Server for 3rd party authentication
schemes can be added.  So your PPTP client can use RC4 128bit encryption
authenticating users with their smartcard or RSA's SecurID system, or
something custom.  

PPTP vs. L2TP/IPsec.  Windows 2000 Server and many other gateways today
support both protocols, and the Windows VPN client functionality exists
to allow customers to use L2TP/IPsec when possible, and automatically
switch to PPTP if not.  Given the strong user authentication
capabilities in EAP-TLS in PPTP, this may be sufficient for many
customers until they can move to L2TP/IPsec entirely.

For those not actively engaged in the IPsec stds process, please refer
to this site for more details http://www.microsoft.com/vpn 

-----Original Message-----
From: Alex Alten [mailto:Alten@attbi.com] 
Sent: Sunday, September 08, 2002 3:08 PM
To: Lordello, Claudio; ipsec@lists.tislabs.com
Cc: Lordello, Claudio
Subject: RE: It's all over (except for the screaming & shouting).


I believe L2TP needs a cert and PPTP does not.  
That's a significant advantage for PPTP.

- Alex

At 09:41 AM 9/6/2002 -0400, Lordello, Claudio wrote:
>>From what I have observed in a client 2K or XP, when one creates a new

>>VPN
>connection, the default network protocol is "Automatic" which works for

>either PPTP or L2TP/IPsec. Unless one overrides that in the client to 
>specifically pick one or the other, which one is actually negotiated 
>will depend on the server one is dialing into. So I am not sure what 
>you mean by "the OS default is PPTP with 40b DES". Could you please 
>clarify.
>
>Claudio.
>
>-----Original Message-----
>From: Alex Alten [mailto:Alten@attbi.com]
>Sent: Friday, September 06, 2002 5:13 AM
>To: ipsec@lists.tislabs.com
>Subject: It's all over (except for the screaming & shouting).
>
>
>
>The market has finally spoken.  IPsec has lost the VPN race.
>
>Recently I talked with an number of very senior level people in the IT 
>trenchs. A lot of PC upgrades to XP & Win2K were done to get VPN 
>capability.  The OS default is PPTP with 40b DES (MPPE). Not L2TP 
>w/IPsec.  I bet many Cisco folks are upset.
>
>IPsec will probably hang on in specialized niches like net to net VPNs,

>etc.
>
>What a humbling result.
>
>- Alex
>--
>
>Alex Alten
>Alten@ATTBI.com
>
--

Alex Alten
Alten@ATTBI.com