site to site ipsec vpn, ike phase 1

[sarahr202]

HI everybody

Please consider the following example.

   R1---VPN------R2

R1 and R2 are configured properly for vpn. Both routers use policy 1.

Let focus on R1

ISAKMP phase 1

R1(config)# crypto isakmp policy 1

R1(config-isakmp)# encr 3des

R1(config-isakmp)# hash md5

R1(config-isakmp)# authentication pre-share

R1(config-isakmp)# group 2

R1(config-isakmp)# lifetime 86400

R1(config)# crypto isakmp key cisco address 1.1.1.2

phase 2

crypto ipsec transform-set TS esp-3des esp-md5-hmac

Above R1 exchanges Policy 1 info i.e encryption and hashing algorithm and Diffie-hellman key length with R2.By this stage, both routers know what encryption, hashing  and how many bits long DH keys need to be used.

Next R1 and R2 exchanges public keys with each other.

In the next step R1 and R2 will authenticate each other. Following will occur:

R1  creates a packet carrying " shared key".  R1 will use R2's public key (DH 2) and sends this packet to R2. R2 receives it and decrypt it using its private key. Similarly, R2 sends its " shared key" after encrypting it with R1's public key.  At the end of this step, R1 and R2 successfully authenticates each other.

R1 and R2 did not use " 3des' ," md5" of policy 1 so far. All both routers did, is negotiate policy for phase 1 and after that, exchanged shared key encrypted with DH2 to authenticate to each other. I did not see any use of " 3des" and " md5" of policy one.    Am i correct?

I understand that actual data that  flows over vpn between R1 and R2 , will use " 3des" and "md5-hmac" based on negotiated transform set. However, I still do not know when R1 and R2 will use policy 1's 3des and md5 hash. Will R1 and R2 use policy 1 's 3des and "md5" when they negotiate ' transform set in phase 2?

thanks and have a great weekend.

[Gabriel Hill · Accepted solution]

Hello Sarah,

My understanding is that in main mode, the phase one encryption/hash is used during the last 2 packets of the exchange (packets 5/6).

No better way of seeing than looking at a wireshark capture. Check out these captures: http://ccie-or-null.net/2012/03/26/ike-main-mode-aggressive-mode-phase-2/

Look at packets 5/6.

Phase 2 is then negotiated by phase 1's SA (So if you watch the wireshark for phase 2, you will not see anything readable!)

Cheers,

Gabriel

[sarahr202]

Thanks Gabriel.

Great link.  Looks like the author of the video lecture was wrong when he said if we are using pre shared key to authenticate end points, Diffie hellman public and private keys are used . Based on your  wireshark and video lectures by Keith Barker, it looks like this is  not the case.  When using preshared key to authenticate end points, each end point of tunnel compute a hash over the secret shared key and sends it to other end point. The other end point computes the hash over its own stored shared key. If they both match, the other end point is authenticated.

I have two questions.

R1--------------------R2

key cisco         Key cisco

we have different hashing algorithm such as md5  sha etc.

Suppose R1 and R2 are in IKE phase 1 and they are trying to authenticate.

1) R1 computes a hash over its secret key and sends it to R2.

Now how does R2 know which hashing algorithm to use i.e md5 or sha? (  or R1 and R2 knows which hashing algorithm to use when negotiated the policy )

2) Let say both R1 and R2 are in IKe phase 1 where they are using DH to generate session key. Assume both R1 and R2 agreed on 3des for encryption and md5 hmac for data integrity.

My question is Will R1 use the same session key for  3des etc and md5-HMAC ? Or the session key is used to generate  one key for encryption and one different key for md5 hmac ?

thanks for your help.

[Gabriel Hill · Accepted solution]

Hello Sarah,

1. They would know what hashing due to the first two packet exchanges in IKE Phase 1, when they agree on a ISAKMP policy. If no ISAKMP policy is found that matches (for example one side is only using MD5 and the other side is using SHA) phase 1 fails, and they will not go any further. So this mismatch would never happen.

2. I am not sure I completely understand your second question. There are actually four session keys created during ISAKMP phase 1. The three keys (_e, _a, and _d) are derived from SKEYID. The math gets pretty deep when you start to read about these session keys.

SKEYID is a string derived from secret material known only to the active players in the exchange.
SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages.
SKEYID_a is the keying material used by the ISAKMP SA to authenticate its messages.
SKEYID_d is the keying material used to derive keys for non-ISAKMP security associations.

(http://www.ietf.org/rfc/rfc2409.txt)

[sarahr202]

Thanks Gabriel

My last question was do we have two separate keys generated during ike phase 1 ,one for encryption and one for authentication of message. You addressed that question. Sorry for not being very articulate.

SKEYID is a string derived from secret material known only to the active players in the exchange.
SKEYID_e is the keying material used by the ISAKMP SA to protect the confidentiality of its messages.
SKEYID_a is the keying material used by the ISAKMP SA to authenticate its message