Migrate from Cisco VPN client 5.0.0.6 to AnyConnect 3.1.x.x.x

[Steffen Frederiksen]

Hi

Running today:

• ASA 5515x
  
• ASA Version 8.6(1)
  
• Cisco VPN Client 5.0.0.6 (ikev1 ipsec) with RADIUS auth of username and password
  
• Windows 7 x86 Clients
  

Gonna deploy Windows 8 x64 where the old Cisco VPN Client is not supported. We have purchaed AnyConnect Essetials License to all users.

But i cannot figure out how to setup AnyConnect for IPsec with a Pre-shared key.

Is it understood correct:

• AnyConnect does only support IKEv2 that not supports pre-shared key?
  
• AnyConnect Does not support pre-shared key deployment at all - another authentication method is need for two factor auth (like client cert or token etc)
  

Can you refer to any Offical documentation from cisco regarding this matter?

Best Regards,

Steffen.

[Marcin Latosiewicz]

IKEv2 for remote access requires certificate authentication, it's in the standard.

You can setup SSLVPN with AC.

An example for IKEv2 to ASA:

http://www.cisco.com/image/gif/paws/113692/ac-ikev2-ca-00.pdf (a shameless plug).

But you can find tons of IKEv2 docs for ASA/AC, if you're setting it up for the first time DO use the ASDM wizard to setup remote access.

[Steffen Frederiksen]

I've have no problem setting up IKEv2 and Ipsec for anyconnect. But i can't see that i should be possible to use a pre-shared key insted of certificate authentication or token etc.

I Would like to be confirmed on that its no logner possible when using AnyConnect to use Pre-shared keys + username and password for two factor authentication, like it was possible with the old Cisco VPN client and IKEv1.

[Marcin Latosiewicz]

http://tools.ietf.org/html/rfc5996#section-2.16

   In addition to authentication using public key signatures and shared
   secrets, IKE supports authentication using methods defined in RFC
   3748 [EAP].  Typically, these methods are asymmetric (designed for a
   user authenticating to a server), and they may not be mutual.  For
   this reason, these protocols are typically used to authenticate the
   initiator to the responder and MUST be used in conjunction with a
   public-key-signature-based authentication of the responder to the
   initiator.

[Steffen Frederiksen]

Hi Marcin

I'm still not quite sure.

Yes the responder (the ASA device) needs a public-key infrastructure to encryp the username and password send from the initiator (the AnyConnect client) right? AnyConnect client uses that Responders (the ASA Device) public key to encryp this information - and the ASA decrypt this information with its private key. I have a Certificate on the ASA from a trusted root certificate authority installed.

But the Initiator (the client is suppose) is using the AnyConnect Client, that only support IKEv2 - does IKEv2 support a preshared key setup for two factor authentication of the initiator (the client)?

Bear with me...

[Marcin Latosiewicz]

Steffen,

You're mixing up a bit SSL and IKEv2, or at least part of SSL.

If you chose to perform EAP (EAP-Anyconnect, -MD5 etc etc) the RFC dictates that a public-key-signature based authentication is to be used. For 99% of deployments this will mean using certificates.

The reason for this is that typically those methods will authenticate client to server but not server to client.

Now first have a look at appendix C.3 indicating the exchange done.

Now if you want to know what is protecting what and how the key is generated have a look how SKEYSEED is calculated in section 2.14.

The key here (as with IKEv1) is Diffie-Hellman exchnage, and not (directly) RSA.

It all depends how deep you want to go into RFC. :-)

M.

[Steffen Frederiksen]

Hmm..

I'm stilling not understand why it's so difficuelt to find an answer (Does AnyConnect 3.1.x.x support pre-shared key for two factor authentication)

But lets dive in som theory for better understanding :-)

It's an IPsec tunnel in transport mode i'm trying to establish - IPsec is a suite of protocols:

• AH -  integrity and data origin authentication for IP datagrams
  
• ESP provides origin authenticity, integrity and confidentiality protection of packets
  
• Security Associations provide the bundle of algorithms and data that provide the parameters necessary to AH and/or ESP operations. The Internet Security Association and Key Management Protocol (ISAKMP) provides a framework for authentication and key exchange. With actual authenticated keying material provided either by manual configuration with pre-shared keys, Internet Key Exchange (IKE and IKEv2)
  

IKE is used to setup SA's (IKE builds upon the Oakley protocol and ISAKMP.[1] IKE uses X.509 certificates for authentication which are either pre-shared or distributed using DNS (preferably with DNSSEC) and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived)

So the original IP Packet Header remain intact but the IP Packet is encapsulated in a ESP Header and Trailer.

Yes? :-)

But since the IKE protocol is used to etablish the SA's used by ESP, IKE needs to support Pre-Shared keys if I wan't to use this form for authentication.

So the big question is does IKEv2 supports pre-shared keys when establish SA's - and if so - how to setup in the AnyConnect Client Profile

[Marcin Latosiewicz]

You are mixing up a lot of concepts.

IKE SA and IPsec SA are different bests. AH and ESP are ways to encapsulate data (both can operate in tunnel or tarnsport mode) but this is not relevant yet, we're discussin IKE_AUTH and IKE_INIT.

AC allows you to perform following authneitcation

- EAP (shared in link below)

- EAP + cert 

http://www.cisco.com/en/US/products/ps10884/products_tech_note09186a0080bd8106.shtml

- cert only

(example with IOS)

http://www.cisco.com/en/US/products/ps12922/products_tech_note09186a0080bde100.shtml

IKE is used to setup SA's (IKE builds upon the Oakley protocol and ISAKMP.[1] IKE uses X.509 certificates for authentication 

which are either pre-shared
 or distributed using DNS (preferably with DNSSEC) and a Diffie–Hellman key exchange to set up a shared session secret from which cryptographic keys are derived)

This sections speaks of the way certificates are distributed.

Yes, IKEv2 supports PSK, but long story short not for AC (RA).

[Steffen Frederiksen]

Okay, thank you, confirmed AC does not support PSK.

Can you explain to me where EAP is comming into the picture for authentication?

I thought that IKE stood for the Key Exchange process. And when the endpoints has exchanged their keys it its used for ESP to encryp the IP-Packet?

Edit:

   This document specifies EAP-IKEv2, an EAP method that is based on the
   Internet Key Exchange Protocol version 2 (IKEv2) [1].  EAP-IKEv2
   provides mutual authentication and session key establishment between
   an EAP peer and an EAP server.  It supports authentication techniques
   that are based on the following types of credentials:

http://tools.ietf.org/html/rfc5106

OKay, so EAP is the authentication protocol that IKEv2 uses. To Establish the IPsec-sa's that is use by ESP to Encryp the IP-Packet?

[Marcin Latosiewicz · Accepted solution]

In IKEv1 we had xauth with was a de-facto standard for most implementations.

In IKEv2 the standard dictates usage of EAP to exchange authentication material which is not PSK or RSA related.

I.e. if you want to exchange user/password you will need to use EAP.

If you have a look at both references I sent you you will see what EAP is used for for and how exactly (at which stage of exchange it is used).

You will notice that EAP starts "half way" through IKE_AUTH, after successful IKE_INIT. i.e. after diffie hellman has been exchange and SKEYSEED can be calculated.

For actual IPsec encryption you can see that more clearly in CREATE_CHILD_SA exchange that KE and N are exchanged along with SA.

But typically this information is already in contained in IKE_AUTH, i.e. after IKE_AUTH you should have IKEv2 SA and IPsec SA.

For this part have a look at C.1 and C.3 appendix.

HTH,

M.

[Steffen Frederiksen]

Thank you for your time. You've been very helpful!