1 2 3 4 Previous Next 59 Replies Latest reply: Dec 31, 2013 5:19 AM by Gheorghe RSS

    IKE Phase 1 and 2 symmetric key

    Steven Savoy

      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.

        • 1. Re: IKE Phase 1 and 2 symmetric key
          Scott Morris - CCDE/4xCCIE/2xJNCIE

          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

          • 2. Re: IKE Phase 1 and 2 symmetric key
            Steven Savoy

            Thanks!  That makes sense.

            • 3. Re: IKE Phase 1 and 2 symmetric key
              Paul Stewart  -  CCIE Security

              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.

              • 4. Re: IKE Phase 1 and 2 symmetric key
                Brian A

                  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.

                • 5. Re: IKE Phase 1 and 2 symmetric key
                  Paul Stewart  -  CCIE Security

                  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.

                  • 6. Re: IKE Phase 1 and 2 symmetric key
                    Keith Barker - CCIE RS/Security, CISSP

                    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

                    • 7. Re: IKE Phase 1 and 2 symmetric key
                      Angu

                      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.

                      • 8. Re: IKE Phase 1 and 2 symmetric key
                        Keith Barker - CCIE RS/Security, CISSP

                        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

                        • 9. Re: IKE Phase 1 and 2 symmetric key
                          Brian A

                          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.

                          • 10. Re: IKE Phase 1 and 2 symmetric key
                            Angu

                            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.

                            • 11. Re: IKE Phase 1 and 2 symmetric key
                              Keith Barker - CCIE RS/Security, CISSP

                              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

                              • 12. Re: IKE Phase 1 and 2 symmetric key
                                Chris

                                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

                                • 13. Re: IKE Phase 1 and 2 symmetric key
                                  Chris

                                  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

                                  • 14. Re: IKE Phase 1 and 2 symmetric key
                                    Rajesh Agrawal

                                    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.

                                    1 2 3 4 Previous Next