Skip navigation
Cisco Learning Home > CCNA Security Study Group > Discussions
This Question is Answered 2 Helpful Answers available (2 pts)
27821 Views 59 Replies Latest reply: Dec 31, 2013 5:19 AM by Gheorghe RSS 1 2 3 4 Previous Next

Currently Being Moderated

IKE Phase 1 and 2 symmetric key

Jan 22, 2011 7:34 AM

Steven Savoy 71 posts since
May 7, 2010

OK,  I have the concepts of the site-to-site VPN down pretty well, but there is something in the config that im confused about.

 

When you are configuring the IKE phase 1 part (the isakmp section), you have to define a symmetric encryption algorithm. (AES. DES, TDES)

 

When you are configuring the IKE phase 2 part (IPsec), you have to define the symmetric encryption in the transform set.

 

 

My question.

 

If the phase 1 part of the IPsec tunnel is used to protect the symmetric key exchanged for phase 2, why do we have to define a symmetric algorithm (AES, DES TDES) during the configuration of phase 1?

 

I thought DH was the only encryption we care about during the phase 1 config?

 

 

Hope thats clear enough.

  • Scott Morris - CCDE/4xCCIE/2xJNCIE 8,396 posts since
    Oct 7, 2008
    Currently Being Moderated
    1. Jan 22, 2011 8:19 AM (in response to Steven Savoy)
    Re: IKE Phase 1 and 2 symmetric key

    DH is what phase 1 uses.  but you tell it what to use for Phase 2.  It has to know that in order to get started.  Phase 2 is already expecting that information but it comes FROM phase 1.

     

    HTH,

     

    Scott

  • Paul Stewart  -  CCIE Security, CCSI 6,972 posts since
    Jul 18, 2008

    Exaclty.  So when you complete the IKE phase 1 process, you have a phase 1 sa that will allow you to exchange the information to build the phase 2 IPSEC SA's. 

     

    The phase 1 sa can specify encryption and hashing such as aes-256, sha1-hmac.  Through this tunnel, we may exchange a phase 2 sa.  This phase 2 sa would have information like 192.168.5.0/24 <> 192.168.6.0/24, relevant proxy (endpoint) address, and aes-192, sha1 hmac (for example).  In this case the phase 1 process would establish a tunnel to exchange phase 2 information.  The exchange of this information would be through an aes-256 bit tunnel.  However, the resultant tunnel (that will carry user data) would be aes-192.

  • Brian A 40 posts since
    Oct 29, 2009
    Currently Being Moderated
    4. Feb 11, 2011 1:48 AM (in response to Steven Savoy)
    Re: IKE Phase 1 and 2 symmetric key

      I never thought of the phase one isakmp policy containing the symmetric algorithm for phase 2 but there it is.  This leads me to a new question.  What happens if the symmetric algorithm in the isakmp policy does not match the symmetric algorithm stated in the ipsec transform set command?  I have not heard of the need for these two needing to match on the same router.

  • Paul Stewart  -  CCIE Security, CCSI 6,972 posts since
    Jul 18, 2008
    Currently Being Moderated
    5. Feb 11, 2011 2:41 AM (in response to Brian A)
    Re: IKE Phase 1 and 2 symmetric key

    It is okay to use a different Phase 1 and Phase 2 encryption.  The requirement is that Phase 1 on device 1 match Phase 1 on device 2.  Likewise Phase 2 encryption has to match on the devices.  Howeve, if there is some strange requirement that Phase 1 and Phase 2 use different encryption techniques, that is fine.

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    6. Feb 11, 2011 12:17 PM (in response to Brian A)
    Re: IKE Phase 1 and 2 symmetric key

    Great comments by all.

     

    As an add on, I like to think of it as DH generating the shared secret keying material, that is used by both IKE phase1 and IKE phase 2.

     

    If we want to use separate keying material for IKE phase 2, we can use PFS as part of our phase 2 policy, and it will generate a new set of keying material just for IKE phase 2, and regenerate it each time the tunnel expires/renews.

     

    Keith

  • Angu 76 posts since
    Feb 1, 2010

    Hi Keith,

     

    Can you please explain the sequence that happens in the formation of the IKE phase 1 and phase 2 tunnel. When i run the debugs i find that they send the security associations on either sides and the formation of the phase 1 tunnel and after that phase 2.

    My doubt is the sequence, like if i am using the preshare key for authentication and after the isakmp negotiation what happens? Or from my understanding i take this sequence, please correct me if i am wrong at any point.

     

    Sample:


    crypto isakmp policy 10

    encr aes

    authentication pre-share

    group 5

    lifetime 3600

    crypto isakmp key cisco address 10.1.1.1


    crypto ipsec security-association lifetime kilobytes 10000

    crypto ipsec transform-set VPN_IPSEC esp-aes esp-sha-hmac


    crypto map VPN_MAP 10 ipsec-isakmp

    set peer 10.1.1.1

    set transform-set VPN_IPSEC

    set pfs group5

    match address VPN_LIST

     


    ip access-list extended VPN_LIST

    permit ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255


    interface FastEthernet0/0

    crypto map VPN_MAP

     

     

    1. Interesting traffic matches the ACL and initiates the process

    2. The crypto map is matched and in the int fa 0/0 starts sending the sa for the formation of isakmp phase by identifying the peer address. (Does it carry only the isakmp policy or isakmp + transform-set? )

    3. After agreeing upon similar policies on either sides. DH Public keys are sent by both peers and key string (password )encrypted travels to the respecitive private key originator and gets decrypted.

     

    4. uhh i will stop with this, my brain is not working any more. Really confused. I know what is what ( encryption , hash etc...) but not what comes after what. And it took me 5 min to configure this and 30 min to write the above 3 points editing,editing. sorry for the long post.

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    8. Feb 11, 2011 3:17 PM (in response to Angu)
    Re: IKE Phase 1 and 2 symmetric key

    Hello Cisco-

    Here is the process, in human terms .

     

    1. Router has a packet that is about to be forwarded, and it notices that it matches a crypto ACL.
    2. Router looks to see if there is an IPSec SA in place, if not....
    3. Router looks to see if there is an IKE Phase 1 SA in place, if not...
    4. Router becomes initiator, and sends over all of its IKE phase 1 policies.
    5. Remote router responds, by specifying which IKE phase 1 policy is a match.
    6. Both peers run DH, and generate shared secret keying material.
    7. Both peer authenticate with each other, using authentication method agreed to in IKE phase 1 negotiations. (IKE phase 1 tunnel is now up.)
    8. Using the IKE phase 1 tunnel as a cloak of security, they two peers negotiate the details of IKE Phase 2.
    9. DH is not run again, and shared secret keying material is used from the DH in IKE phase 1, unless PFS is used.
    10. IKE phase 2 tunnel (AKA, the IPSec tunnel) is now in place, and the data is encapsulated and sent through the tunnel.

     

    I am grateful that the mathematicians and engineers of these security protocols did all the heavy lifting, and all we do is design networks that use the technology, configure the gear to work correctly, and troubleshoot when life happens.

     

     

     

    3 routers CLN4-no-user.png

     

     

    R3#show debug

     

     

    Cryptographic Subsystem:

      Crypto ISAKMP debugging is on

      Crypto IPSEC debugging is on

     

     

    R3#ping 1.1.1.1 source lo 0

     

    Type escape sequence to abort.

    Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

    Packet sent with a source address of 3.3.3.3

     

    IPSEC(sa_request): ,

      (key eng. msg.) OUTBOUND local= 23.0.0.3, remote= 10.0.0.1,

        local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),

        remote_proxy= 1.1.1.1/255.255.255.255/0/0 (type=1),

        protocol= ESP, transform= esp-aes esp-sha-hmac  (Tunnel),

        lifedur= 3600s and 4608000kb,

        spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0

    ISAKMP:(0): SA request profile is (NULL)

    ISAKMP: Created a peer struct for 10.0.0.1, peer port 500

    ISAKMP: New peer created peer = 0x66B52D5C peer_handle = 0x80000002

    ISAKMP: Locking peer struct 0x66B52D5C, refcount 1 for isakmp_initiator

    ISAKMP: local port 500, remote port 500

    ISAKMP: set new node 0 to QM_IDLE     

    insert sa successfully sa = 66715AA4

    ISAKMP:(0):Can not start Aggressive mode, trying Main mode.

    ISAKMP:(0):found peer pre-shared key matching 10.0.0.1

    ISAKMP:(0): constructed NAT-T vendor-rfc3947 ID

    ISAKMP:(0): constructed NAT-T vendor-07 ID

    ISAKMP:(0): constructed NAT-T vendor-03 ID

    ISAKMP:(0): constructed NAT-T vendor-02 ID

    ISAKMP:(0):Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM

    ISAKMP:(0):Old State = IKE_READY  New State = IKE_I_MM1

     

    ISAKMP:(0): beginning Main Mode exchange

    ISAKMP:(0): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_NO_STATE

    ISAKMP:(0):Sending an IKE IPv4 Packet.

    ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_NO_STATE

    ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

    ISAKMP:(0):Old State = IKE_I_MM1  New State = IKE_I_MM2

     

    ISAKMP:(0): processing SA payload. message ID = 0

    ISAKMP:(0): processing vendor id payload

    ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

    ISAKMP (0:0): vendor ID is NAT-T RFC 3947

    ISAKMP:(0):found peer pre-shared key matching 10.0.0.1

    ISAKMP:(0): local preshared key found

    ISAKMP : Scanning profiles for xauth ...

    ISAKMP:(0):Checking ISAKMP transform 1 against priority 1 policy

    ISAKMP:      encryption DES-CBC

    ISAKMP:      hash SHA

    ISAKMP:      default group 1

    ISAKMP:      auth pre-share

    ISAKMP:      life type in seconds

    ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80

    ISAKMP:(0):atts are acceptable. Next payload is 0

    ISAKMP:(0):Acceptable atts:actual life: 0

    ISAKMP:(0):Acceptable atts:life: 0

    ISAKMP:(0):Fill atts in sa vpi_length:4

    ISAKMP:(0):Fill atts in sa life_in_seconds:86400

    ISAKMP:(0):Returning Actual lifetime: 86400

    ISAKMP:(0)::Started lifetime timer: 86400.

     

    ISAKMP:(0): processing vendor id payload

    ISAKMP:(0): vendor ID seems Unity/DPD but major 69 mismatch

    ISAKMP (0:0): vendor ID is NAT-T RFC 3947

    ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

    ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM2

     

    ISAKMP:(0): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_SA_SETUP

    ISAKMP:(0):Sending an IKE IPv4 Packet.

    ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

    ISAKMP:(0):Old State = IKE_I_MM2  New State = IKE_I_MM3

     

    ISAKMP (0:0): received packet from 10.0.0.1 dport 500 sport 500 Global (

    R3#I) MM_SA_SETUP

    ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

    ISAKMP:(0):Old State = IKE_I_MM3  New State = IKE_I_MM4

     

    ISAKMP:(0): processing KE payload. message ID = 0

    ISAKMP:(0): processing NONCE payload. message ID = 0

    ISAKMP:(0):found peer pre-shared key matching 10.0.0.1

    ISAKMP:(1001): processing vendor id payload

    ISAKMP:(1001): vendor ID is Unity

    ISAKMP:(1001): processing vendor id payload

    ISAKMP:(1001): vendor ID is DPD

    ISAKMP:(1001): processing vendor id payload

    ISAKMP:(1001): speaking to another IOS box!

    ISAKMP:received payload type 20

    ISAKMP:received payload type 20

    ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

    ISAKMP:(1001):Old State = IKE_I_MM4  New State = IKE_I_MM4

     

    ISAKMP:(1001):Send initial contact

    ISAKMP:(1001):SA is doing pre-shared key authentication using id type ID_IPV4_ADDR

    ISAKMP (0:1001): ID payload

            next-payload : 8

            type         : 1

            address      : 23.0.0.3

            protocol     : 17

            port         : 500

            length  

    R3#    : 12

    ISAKMP:(1001):Total payload length: 12

    ISAKMP:(1001): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) MM_KEY_EXCH

    ISAKMP:(1001):Sending an IKE IPv4 Packet.

    ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

    ISAKMP:(1001):Old State = IKE_I_MM4  New State = IKE_I_MM5

     

    ISAKMP (0:1001): received packet from 10.0.0.1 dport 500 sport 500 Global (I) MM_KEY_EXCH

    ISAKMP:(1001): processing ID payload. message ID = 0

    ISAKMP (0:1001): ID payload

            next-payload : 8

            type         : 1

            address      : 10.0.0.1

            protocol     : 17

            port         : 500

            length       : 12

    ISAKMP:(0):: peer matches *none* of the profiles

    ISAKMP:(1001): processing HASH payload. message ID = 0

    ISAKMP:(1001):SA authentication status:

            authenticated

    ISAKMP:(1001):SA has been authenticated with 10.0.0.1

    ISAKMP: Trying to insert a peer 23.0.0.3/10.0.0.1/500/,  and inserted successfully 66B52D5C.

    ISAKMP:(1001):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH

    ISAKMP:(1001):Old State

    R3#= IKE_I_MM5  New State = IKE_I_MM6

     

    ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE

    ISAKMP:(1001):Old State = IKE_I_MM6  New State = IKE_I_MM6

     

    ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE

    ISAKMP:(1001):Old State = IKE_I_MM6  New State = IKE_P1_COMPLETE

     

    ISAKMP:(1001):beginning Quick Mode exchange, M-ID of -47238664

    ISAKMP:(1001):QM Initiator gets spi

    ISAKMP:(1001): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) QM_IDLE     

    ISAKMP:(1001):Sending an IKE IPv4 Packet.

    ISAKMP:(1001):Node -47238664, Input = IKE_MESG_INTERNAL, IKE_INIT_QM

    ISAKMP:(1001):Old State = IKE_QM_READY  New State = IKE_QM_I_QM1

    ISAKMP:(1001):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE

    ISAKMP:(1001):Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE

     

    ISAKMP (0:1001): received packet from 10.0.0.1 dport 500 sport 500 Global (I) QM_IDLE     

    ISAKMP:(1001): processing HASH payload. message ID = -47238664

    ISAKMP:(1001): processing SA payload. me

    R3#ssage ID = -47238664

    ISAKMP:(1001):Checking IPSec proposal 1

    ISAKMP: transform 1, ESP_AES

    ISAKMP:   attributes in transform:

    ISAKMP:      encaps is 1 (Tunnel)

    ISAKMP:      SA life type in seconds

    ISAKMP:      SA life duration (basic) of 3600

    ISAKMP:      SA life type in kilobytes

    ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0

    ISAKMP:      authenticator is HMAC-SHA

    ISAKMP:      key length is 128

    ISAKMP:(1001):atts are acceptable.

    IPSEC(validate_proposal_request): proposal part #1

    IPSEC(validate_proposal_request): proposal part #1,

      (key eng. msg.) INBOUND local= 23.0.0.3, remote= 10.0.0.1,

        local_proxy= 3.3.3.3/255.255.255.255/0/0 (type=1),

        remote_proxy= 1.1.1.1/255.255.255.255/0/0 (type=1),

        protocol= ESP, transform= NONE  (Tunnel),

        lifedur= 0s and 0kb,

        spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0

    Crypto mapdb : proxy_match

            src addr     : 3.3.3.3

            dst addr     : 1.1.1.1

            protocol     : 0

            src port     : 0

            dst port   

    R3# : 0

    ISAKMP:(1001): processing NONCE payload. message ID = -47238664

    ISAKMP:(1001): processing ID payload. message ID = -47238664

    ISAKMP:(1001): processing ID payload. message ID = -47238664

    ISAKMP:(1001): Creating IPSec SAs

            inbound SA from 10.0.0.1 to 23.0.0.3 (f/i)  0/ 0

            (proxy 1.1.1.1 to 3.3.3.3)

            has spi 0x8224B17D and conn_id 0

            lifetime of 3600 seconds

            lifetime of 4608000 kilobytes

            outbound SA from 23.0.0.3 to 10.0.0.1 (f/i) 0/0

            (proxy 3.3.3.3 to 1.1.1.1)

            has spi  0x8DC5BE8F and conn_id 0

            lifetime of 3600 seconds

            lifetime of 4608000 kilobytes

    ISAKMP:(1001): sending packet to 10.0.0.1 my_port 500 peer_port 500 (I) QM_IDLE     

    ISAKMP:(1001):Sending an IKE IPv4 Packet.

    ISAKMP:(1001):deleting node -47238664 error FALSE reason "No Error"

    ISAKMP:(1001):Node -47238664, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH

    ISAKMP:(1001):Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE

    IPSEC

    R3#(key_engine): got a queue event with 1 KMI message(s)

    Crypto mapdb : proxy_match

            src addr     : 3.3.3.3

            dst addr     : 1.1.1.1

            protocol     : 0

            src port     : 0

            dst port     : 0

    IPSEC(crypto_ipsec_sa_find_ident_head): reconnecting with the same proxies and peer 10.0.0.1

    IPSEC(policy_db_add_ident): src 3.3.3.3, dest 1.1.1.1, dest_port 0

     

    IPSEC(create_sa): sa created,

      (sa) sa_dest= 23.0.0.3, sa_proto= 50,

        sa_spi= 0x8224B17D(2183442813),

        sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 1

    IPSEC(create_sa): sa created,

      (sa) sa_dest= 10.0.0.1, sa_proto= 50,

        sa_spi= 0x8DC5BE8F(2378546831),

        sa_trans= esp-aes esp-sha-hmac , sa_conn_id= 2

    IPSEC(update_current_outbound_sa): updated peer 10.0.0.1 current outbound sa to SPI 8DC5BE8F

    R3#un all

    All possible debugging has been turned off

    R3#


    Best wishes in your detailed studies of IPSec


    Keith

  • Brian A 40 posts since
    Oct 29, 2009

    I hate to drag this out any more, but I have a question about step #9 above.

     

    9. DH is not run again and shared secret keying material is used from the DH in IKE phase 1...

     

    Wouldn't a new/different symmetric key for phase two (not the same one used for phase 1) need to be transmitted within the security of the phase one tunnel?

     

    That would keep the ISAKMP sa and the IPSEC sa independent, which is what I thought they were.

     

    The reason I think this is because the symmetric encryption for phase 1 and 2 can be different. If phase one used DES it would need to be 56 bits and if phase two used AES it could be 128 bits.  Since they vary quite a bit in length I don't see how the keying material from phase one could be used for phase two.

     

    I always thought phase 1 was its own independent sa and phase two just used it to set up its own independent sa with a new phase two key being shared in the protection of the phase one encryption.

  • Angu 76 posts since
    Feb 1, 2010

    Hi keith,

     

    The sequence is ok for me now. Still have to look at every line in the debugs.

    Then i have watched your private-vlans video recently and i have to admit that it is a awesome little one. Gave me a good idea about the pvlans. Thank you.

  • Keith Barker - CCIE RS/Security, CISSP 5,351 posts since
    Jul 3, 2009
    Currently Being Moderated
    11. Feb 20, 2011 10:47 PM (in response to Brian A)
    Re: IKE Phase 1 and 2 symmetric key

    Brian A wrote:

     

    I hate to drag this out any more, but I have a question about step #9 above.

     

    9. DH is not run again and shared secret keying material is used from the DH in IKE phase 1...

     

    Wouldn't a new/different symmetric key for phase two (not the same one used for phase 1) need to be transmitted within the security of the phase one tunnel?

     

    That would keep the ISAKMP sa and the IPSEC sa independent, which is what I thought they were.

     

    The reason I think this is because the symmetric encryption for phase 1 and 2 can be different. If phase one used DES it would need to be 56 bits and if phase two used AES it could be 128 bits.  Since they vary quite a bit in length I don't see how the keying material from phase one could be used for phase two.

     

    I always thought phase 1 was its own independent sa and phase two just used it to set up its own independent sa with a new phase two key being shared in the protection of the phase one encryption.

    Shared secret keying material is created via DH during IKE phase 1.

     

    This keying material can be used by any symmetrical algorithm that wants to use this keying material, or parts of that keying material.

     

    IKE phase 1 creates an SA based on the encryption agreed between the peers.

     

    IKE phase 2 creates an SA (the IPSec SA), based on the encryption agreed between the peers (these would be the IPSec transform sets that are negotiated.

     

    Phase 1 could use 3DES, and phase 2 could use AES.   Both dip into the pool of keying material created by DH during the IKE phase 1 process, but will create 2 separate SAs.

     

    Keith

  • Chris 811 posts since
    Jul 25, 2008
    Currently Being Moderated
    12. Feb 20, 2011 11:47 PM (in response to Angu)
    Re: IKE Phase 1 and 2 symmetric key

    Keith--Awesome posts!

     

    Brian your thinking is correct and adding to what Keith has stated:

     

    The IPsec SA(s) are unidirectional and with DH will use a separate Symmetric Session Key for sending and receiving with the remote peer.

     

    Chris

  • Chris 811 posts since
    Jul 25, 2008
    Currently Being Moderated
    13. Feb 20, 2011 11:51 PM (in response to Angu)
    Re: IKE Phase 1 and 2 symmetric key

    Keith--Awesome posts!

     

    Brian your thinking is correct and adding to what Keith has stated:

     

    The IPsec SA(s) are unidirectional and with DH will use a separate Symmetric Session Key for sending and receiving with the remote peer.

     

    Chris

  • Rajesh Agrawal 71 posts since
    Nov 2, 2009

    Very Nice Reply to the confusing Question really you really a man who can explain the things in best way which other can not and makes things lenthy.

Actions

More Like This

  • Retrieving data ...

Bookmarked By (9)