ISAKMP identity on cisco routers

[ovt]

Hi!

Can anybody explain why shared key should be tied to source IP address (in

outer IP header), rather than to Identity on cisco routers if Main mode

is used and to Identity if Aggressive mode is used ???

For example, our peer router uses Identity = hostname ("Up.red.ru")

and IP address 192.168.1.1 to initiate IKE/IPSec tunnel in Main mode.

Router "Down" has config as follows:

hostname Down

ip domain-name red.ru

crypto isakmp policy 1

authentication pre-share

group 2

crypto isakmp key cisco address 192.168.1.1 no-xauth ! key tied to IP !!!

crypto isakmp identity hostname

!

!

crypto ipsec transform-set trans1 esp-des esp-sha-hmac

!

crypto map s2s 10 ipsec-isakmp

set peer 192.168.1.1

set transform-set trans1

set identity QQQ ! only accept peers with Identities in QQQ identity list

match address 100

!

!

crypto identity QQQ

fqdn Up.red.ru

This config works. If I change "fqdn Up.red.ru" to say "fqdn bla-bla-bla"

I see "IPSEC(validate_proposal): peer failed identity check 10.1.1.1",

"ISAKMP (0:9): atts not acceptable. Next payload is 0",

"%CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at

192.168.1.1". (Phase 1 SA is established).

So far as I understood this means that peer's Identity was really "Up.red.ru".

But shared secret is tied to 192.168.1.1 IP address! If I change this to

"crypto isakmp key cisco hostname Up.red.ru no-xauth" I see

"ISAKMP (0:10): No pre-shared key with 192.168.1.1!"

Can anybody explain this? IOS 12.2(11)T

Oleg Tipisov,

REDCENTER,

Moscow

[smahbub]

This might be a useful resource to you: http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/isakmp.htm#xtocid18 but you may need to dig into the rfc's to find the detailed answers.

[ovt]

Thank you for the replay, but cisco documentation lies.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/isakmp.htm#35879 lies also.

Eventually I found out, that it is not possible to use ISAKMP Identity (IDii) to

look up a key in Main mode, because Main mode encrypts Identity field ("hidden

identity" concept). Recepient cannot decrypt it until phase 1 SA is authenticated.

This is in turn requires shared secret to be determined by the recepient... So,

the only possibility for the recepient is to tie the secret to the initiator's IP address.

In general it would be possible to tie the secret to the peer's FQDN and use DNS

(or local "ip host" commands) to back-resolve sender IP to FQDN, but it doesn't

work with 12.2(11)T (BUG?). And it is not a secure method unless Secure DNS is

used.

Oleg Tipisov,

REDCENTER,

Moscow