ipsec and keys used

[sarahr202]

Hi everybody.

When using ipsec (  AH/ESP), both authentication and encryption require a secret key as dicussed in the following extract:                 

Authentication calculates an Integrity Check Value (ICV) over the packet's contents, and it's usually built on top of a cryptographic hash such as MD5 or SHA-1. It incorporates a secret key known to both ends, and this allows the recipient to compute the ICV in the same way. If the recipient gets the same value, the sender has effectively authenticated itself (relying on the property that cryptographic hashes can't practically be reversed). AH always provides authentication, and ESP does so optionally.

Encryption uses a secret key to encrypt the data before transmission, and this hides the actual contents of the packet from eavesdroppers. There are quite a few choices for algorithms here, with DES, 3DES, Blowfish and AES being common. Others are possible too.

  -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

These keys can be manually configured or they can be exchanged using IKE as dicussed in following extract:

IKEversus manual keys

Since both sides of the conversation need to know the secret values used in hashing or encryption, there is the question of just how this data is exchanged. Manual keys require manual entry of the secret values on both ends, presumably conveyed by some out-of-band mechanism, and IKE (Internet Key Exchange) is a sophisticated mechanism for doing this online.

========================================================

When I look at the examples giiven in response to my last thread on vpn, I  do not see  those sectet keys required for authentication and encrption pf packets.;

Below is an example :

crypto isakmp policy 10

authentication pre-share

crypto isakmp key CISCO address 199.199.199.2

!

crypto ipsec transform-set MyTransSet esp-3des esp-sha-hmac

mode transport

!

crypto ipsec profile MyProfile

set transform-set MyTransSet

!

interface Tunnel0

ip address 10.10.10.1 255.255.255.252

tunnel source 199.199.199.1

tunnel destination 199.199.199.2

tunnel mode ipsec ipv4

tunnel protection ipsec profile MyProfile

!

interface serial0

ip address 199.199.199.1 255.255.255.0

duplex auto

speed auto

!

ip route 0.0.0.0 0.0.0.0 199.199.199.2

Above what keys are being used for authentication and encrption of packets ?

thanks and have a great weekend.

[Jeff Van Houten · Accepted solution]

As written in your citation, Ike negotiates those keys for you. Since you are using Ike, you don't have to manually configure the bulk encryption keys.

Sent from Cisco Technical Support iPad App

[Karsten Iwen · Accepted solution]

here is an example of manualy configured keys using the "old style" crypto maps:

hostname Router1
!
ip access-list ext crypto-hamburg

  permit ip 10.0.1.0 0.0.0.255 10.0.2.0 0.0.0.255
!
crypto ipsec transform-set esp-des-md5 esp-des esp-md5-hmac
crypto map vpn 20 ipsec-manual

  match address crypto-hamburg
  set transform esp-des-md5
  set peer 172.30.2.2

  set session-key inbound esp 2001 cipher fedcba9876543210 authenticator ffeeddccbbaa99887766554433221100

  set session-key outbound esp 1002 cipher 0123456789abcdef authenticator 00112233445566778899aabbccddeeff
!
interface fa0/1

  description WAN-Interface
  ip address 172.30.1.2 255.255.255.0
  crypto map vpn

hostname Router2
!
ip access-list ext crypto-muenchen

 permit ip 10.0.2.0 0.0.0.255 10.0.1.0 0.0.0.255
!
crypto ipsec transform-set esp-des-md5 esp-des esp-md5-hmac
crypto map vpn 20 ipsec-manual

  match address crypto- muenchen
  set transform esp-des-md5
  set peer 172.30.1.2
  set session-key inbound esp 1002 cipher 0123456789abcdef authenticator 00112233445566778899aabbccddeeff
  set session-key outbound esp 2001 cipher fedcba9876543210 authenticator ffeeddccbbaa99887766554433221100

!
interface fa0/1
  ip address 172.30.2.2 255.255.255.0
  crypto map vpn

The keys that protect the data outbound of Router1 is used inbound on Router 2 and vice versa. In this setup you don't need a phase1-config as anything for the ipsec-SAs is preconfigured. Of course this is only for education and should never be used for real VPNs.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[sarahr202]

Hi Karsten

In this setup you don't need a phase1-config as anything for the ipsec-SAs is preconfigured.

When you say " ip sec-SAs" phase 1 is preconfigured do you mean the following configurations( just as an example):

crypto isakmp policy 10

authentication pre-share

crypto isakmp key CISCO address 199.199.199.2

If they are preconfgured , they are not shown in your example.

thanks and have a great weekend.

[Karsten Iwen · Accepted solution]

no, it was ment differently. In Phase 1 you negotiate policies, session keys and so on. This is completly skipped if the *IPSec-SAs* are preconfigured (that's what is done with the "session-key"-command, normally they are negotiated in phase2, the quick-mode). When the Router1 in my example gets a packet from 10.0.1.10 to 10.0.2.10, then the IPSec-SAs are already build and the traffic can be sent directly to the other side. There is no need to negotiate anything. So the Phase 1-config like the one you showed is completely unneeded with a manual IPSec-config.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[sarahr202]

Thanks Karsten.

In phase 1 ( assuming quick mode is not configured)negotiations such as how the other end of tunnel is authenticated i.e using pre shared or digital certificates, how the packets ,required for building tunnel are encrypted and authenticated and how the session keys are negotiated which are later used  to encrypt and authenticate packets sent over the tunnel.

In our example , we configured the session key manually so we don't need phase1 configurations related to session keys, . But we still need phase1  other configurations to negotiates other parameters such as how the other end of tunnel is authenticated, how the packets used to establish tunnel are encrypted and authenticated.

Is my understanding correct ?

thanks and enjoy your weekend.

[Karsten Iwen · Accepted solution]

The negotiations of Phase1 give both routers the knowledge of a common set of options and the knowledge oh session-key-material for following SAs. Phase 2 negotiates compatible SAs. Both negotiations are not needed when you configure manual IPSec. Both sides have to be configured campatible and both sides have to use the right manually configured keys (on both routers with the "set session-key"). If it's not configured properly, it just won't work. But as there is no "management-protocol" running, you don't get a hint what's going wrong.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni