1 2 Previous Next 19 Replies Latest reply: Jul 20, 2019 3:29 AM by Hitesh RSS

    Diffie-Hellman operation - g and p aggrement

    MIKIS

      Hello

       

      According to Diffie-Hellman algorithm:

      The parties agree on two non-secret numbers, g (generator), and p (modulus)

      –g is small (e.g. 2), p is very large

      • Each party generates a random secret X

      • Based on g, p, and the secret, each party generates a public value

      –Y = gXmod p

      • Peers exchange public values

      Each party then exponentiates the received public value to its secret value to compute a common shared secret.

       

      Putting the above in the context of IKE exchange messages, the 2 peers will exchange the public values (Y = gXmod p) as KE in messages 3 and 4 of IKE phase 1 along with NONCE.

       

      The question is: how the 2 VPN peers will agree on the two non-secret numbers, g (generator), and p (modulus)? I have read that this is usually done in a master-slave relationship, where one party will derive the two numbers to be used in the DH exchange and forward them over to its peer ('IPsec Virtual Private Network Fundamentals' by James Henry Carmouche). If this is the case, in which IKE message or by which means this is done by Cisco devices?

       

      Regards

       

      Mikis

        • 1. Re: Diffie-Hellman operation - g and p aggrement
          Kingsley - CCSP/CCIP/ CCNP/CCIE Security

          It is done in IKE Phase 1.

           

          With regards

          Kings

          CCNA,CCSP,CCNP,CCIP,CCIE 35914 (Security)

          • 2. Re: Diffie-Hellman operation - g and p aggrement
            murali - Cisco Certified Specialist

            Yes i think it should be done in Phase 1 after each peer authenticated themselves with either pre-shared key or certificates.

             

            In wikipedia they explained the DH Key exchange process to be very simple , i liked it .

            you can navigate via http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

             

             

            Thank you

            • 3. Re: Diffie-Hellman operation - g and p aggrement
              MIKIS

              Thank you both for your responses

               

              As I mentioned in my initial post, the exchange of p and g (if there is exchange) should be done before messages 3 and 4 since in messages 3 and 4 they exchange the KE which derives from p and g. This also implies that should be done in IKE phase 1. Also, negotiating p and g after authentication (which is done in messages 5 and 6) cannot be the case.

               

              What I would like to know is how or when are negotiated the p and g values? I don't see anything about them in messages 1 and 2 since there we have only the SA propasals and the VIDs.

               

              Regards

               

              Mikis

              • 4. Re: Diffie-Hellman operation - g and p aggrement
                Kingsley - CCSP/CCIP/ CCNP/CCIE Security

                DH exchange takes place in MSG 3 & 4 with Main Mode and MSG 1 & 2 in Aggressive mode.

                 

                With regards

                Kings

                CCNA,CCSP,CCNP,CCIP,CCIE 35914 (Security)

                • 5. Re: Diffie-Hellman operation - g and p aggrement
                  MIKIS

                  I know that the DH KE exchange takes place in messages 3 and 4 when MM is used and messages 1 and 2 when AM is used.

                   

                  What I want to know is when the p (prime number) and g (generator) are negotiated because in order for the 2 peers to exchange the KE, first they must agree in common p and g values.

                   

                  Regards

                   

                  Mikis

                  • 6. Re: Diffie-Hellman operation - g and p aggrement
                    murali - Cisco Certified Specialist

                    Dear Mikis ,

                     

                    You are right they will authenticate in 5 and 6.

                     

                    I found the below  in RFC , i tried looking for IKE_SA_INIT message format with no luck.

                     

                    "IKE message flow always consists of a request followed by a response.

                       It is the responsibility of the requester to ensure reliability.  If

                       the response is not received within a timeout interval, the requester

                       needs to retransmit the request (or abandon the connection).

                     

                       The first request/response of an IKE session (IKE_SA_INIT) negotiates

                       security parameters for the IKE_SA, sends nonces, and sends Diffie-

                       Hellman values.

                     

                       The second request/response (IKE_AUTH) transmits identities, proves

                       knowledge of the secrets corresponding to the two identities, and

                       sets up an SA for the first (and often only) AH and/or ESP CHILD_SA"

                     

                     

                    I think we should probably do a packet capture and see all the details to figure this one

                     

                    Murali

                    • 7. Re: Diffie-Hellman operation - g and p aggrement
                      MIKIS

                      Dear murali

                       

                      What you were looking was the RFC of IKEv2 which operates completely different than IKEv1. Anyway, the DH operation should be still the same.

                       

                      I did debugs and captures in Wireshark before sending these posts, but as I mentioned I was not able to identify anything that resembles p and g values. Also in RFC 2409 (IKEv1) there is nothing about the p and g exchange nor in ISAKMP RFC. I also checked a couple of Cisco Press books, but none of them mentions how p and g negotiation is done, that's why I decided to send the question is this forum.

                       

                      Regards

                       

                      Mikis

                      • 8. Re: Diffie-Hellman operation - g and p aggrement
                        Mikael

                        Hi Mikis

                         

                        I might be wrong here but I think you get g and p (generator and modulus) from the DH group.

                        If you look at RFC 3526, in the diffrent groups, it gives you a prime (p) and a generator (g)

                        So if that's the case, DH gets p and g in the first two MSG and the transform payload.

                         

                        Found a hint in 'Cryptography and Network Security Principles and Practice'

                        IKE key determination supports the use of different groupsfor the Diffie-Hellman key exchange. Each group includes the definition of the two global parameters and the identity of the algorithm. The current specification includes the following

                        groups

                         

                        Regards

                        Mikael

                        • 9. Re: Diffie-Hellman operation - g and p aggrement
                          MIKIS

                          Hello Mikael

                           

                          In practice, when doing capture on ASA during the ISAKMP negotiation I don't see any 'p' and 'g' values during the first 2 messages of phase 1. The only thing I found in Cisco documentation is that the DH group specifies the size (in bits) of 'p' and 'g' so, for example in case of DH group 5 the 'p' and 'g' prime numbers will be 1536 bits long.

                          In my opinion, it could be a that after messages 1 and 2 the two peers will use somehow the same values without exchanging them and these values will be taken from some table of predefined prime numbers that are common between the 2 peers. Anyway, I think only developers who write the code for VPN will be able to provide accurate answer to this question. If I meet someone of them I will try to get the answer

                           

                           

                          Here is the capture output of the first 2 IKE messages and as you can see there is nothing that resembles a 'p' or 'g' value exchanged:

                          ASA1# show capture CAP_ISAKMP decode

                          22 packets captured

                             1: 02:35:23.8874000 10.0.12.10.500 > 10.0.23.12.500:  udp 192   <-- Phase 1 message 1 sent

                                ISAKMP Header

                                  Initiator COOKIE: b2 e3 0d 79 79 6f 32 12

                                  Responder COOKIE: 00 00 00 00 00 00 00 00

                                  Next Payload: Security Association

                                  Version: 1.0

                                  Exchange Type: Identity Protection (Main Mode)

                                  Flags: (none)

                                  MessageID: 00000000

                                  Length: 192

                                  Payload Security Association

                                    Next Payload: Vendor ID

                                    Reserved: 00

                                    Payload Length: 100

                                    DOI: IPsec

                                    Situation:(SIT_IDENTITY_ONLY)

                                    Payload Proposal

                                      Next Payload: None

                                      Reserved: 00

                                      Payload Length: 88

                                      Proposal #: 1

                                      Protocol-Id: PROTO_ISAKMP

                                      SPI Size: 0

                                      # of transforms: 2

                                      Payload Transform

                                        Next Payload: Transform

                                        Reserved: 00

                                        Payload Length: 40

                                        Transform #: 1

                                        Transform-Id: KEY_IKE

                                        Reserved2: 0000

                                        Group Description: Group 2

                                        Encryption Algorithm: AES-CBC

                                        Key Length: 128

                                        Hash Algorithm: SHA1

                                        Authentication Method: Preshared key

                                        Life Type: seconds

                                        Life Duration (Hex): 00 01 51 80

                                      Payload Transform

                                        Next Payload: None

                                        Reserved: 00

                                        Payload Length: 40

                                        Transform #: 2

                                        Transform-Id: KEY_IKE

                                        Reserved2: 0000

                                        Group Description: Group 2

                                        Encryption Algorithm: 3DES-CBC

                                        Key Length: 56797

                                        Hash Algorithm: SHA1

                                        Authentication Method: Preshared key

                                        Life Type: seconds

                                        Life Duration (Hex): 00 01 51 80

                                  Payload Vendor ID

                                    Next Payload: Vendor ID

                                    Reserved: 00

                                    Payload Length: 20

                                    Data (In Hex):

                                      90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f

                                  Payload Vendor ID

                                    Next Payload: Vendor ID

                                    Reserved: 00

                                    Payload Length: 20

                                    Data (In Hex):

                                      7d 94 19 a6 53 10 ca 6f 2c 17 9d 92 15 52 9d 56

                                  Payload Vendor ID

                                    Next Payload: None

                                    Reserved: 00

                                    Payload Length: 24

                                    Data (In Hex):

                                      40 48 b7 d5 6e bc e8 85 25 e7 de 7f 00 d6 c2 d3

                                      c0 00 00 00

                           

                             2: 02:35:23.8874020 10.0.23.12.500 > 10.0.12.10.500:  udp 132       <-- Phase 1 message 2 received

                                ISAKMP Header

                                  Initiator COOKIE: b2 e3 0d 79 79 6f 32 12

                                  Responder COOKIE: 4a 72 17 b0 84 76 b9 1a

                                  Next Payload: Security Association

                                  Version: 1.0

                                  Exchange Type: Identity Protection (Main Mode)

                                  Flags: (none)

                                  MessageID: 00000000

                                  Length: 132

                                  Payload Security Association

                                    Next Payload: Vendor ID

                                    Reserved: 00

                                    Payload Length: 60

                                    DOI: IPsec

                                    Situation:(SIT_IDENTITY_ONLY)

                                    Payload Proposal

                                      Next Payload: None

                                      Reserved: 00

                                      Payload Length: 48

                                      Proposal #: 1

                                      Protocol-Id: PROTO_ISAKMP

                                      SPI Size: 0

                                      # of transforms: 1

                                      Payload Transform

                                        Next Payload: None

                                        Reserved: 00

                                        Payload Length: 40

                                        Transform #: 1

                                        Transform-Id: KEY_IKE

                                        Reserved2: 0000

                                        Encryption Algorithm: AES-CBC

                                        Key Length: 128

                                        Hash Algorithm: SHA1

                                        Group Description: Group 2

                                        Authentication Method: Preshared key

                                        Life Type: seconds

                                        Life Duration (Hex): 00 01 51 80

                                  Payload Vendor ID

                                    Next Payload: Vendor ID

                                    Reserved: 00

                                    Payload Length: 20

                                    Data (In Hex):

                                      90 cb 80 91 3e bb 69 6e 08 63 81 b5 ec 42 7b 1f

                                  Payload Vendor ID

                                    Next Payload: None

                                    Reserved: 00

                                    Payload Length: 24

                                    Data (In Hex):

                                      40 48 b7 d5 6e bc e8 85 25 e7 de 7f 00 d6 c2 d3

                                      c0 00 00 00

                           

                          Regards

                           

                          Mikis

                          • 10. Re: Diffie-Hellman operation - g and p aggrement
                            Mikael

                            Yes, I think the values are predefined. In RFC 2409 for IKE, and the one for More MODP, RFC 3526, all the DH groups have a fixed generator of 2 and the only value that differs is the prime. So if both peers agree on a DH group they know p and g.

                             

                            But yes I think we need a developer :-)

                             

                            Cheers

                            M

                            • 11. Re: Diffie-Hellman operation - g and p aggrement
                              Rama Krishnan

                              I PRESUME that, g and p values have to exchange only in msg 1 and 2, could not be at 3,4/5,6, the reasons you well explained in your posts(I agree that). According to my knowledge, those(p,g) should be a global parameters/it would be set with the group(2,5,or7) which we going to use in the proposal. Assuming p (prime number) would be a largest prime and g smallest prime number of 1024 bit, when both parties using DH group 2.

                               

                              While googling, all DH calculation’s documents explains using with same numbers for g and p on both parties.

                               

                              I was very happy when you suited this question in our forum J, but still to make sure (curious to know) that, on which msg p and g values are being exchanged L. Please keep us to know if you would have a chance to get, a perfect defined answers from developerJJ

                               

                              Addition question:Can you explain what does actually Nonce(random #) faciliate? Key exchange or Encryption.?

                               

                              -Krishna

                              • 12. Re: Diffie-Hellman operation - g and p aggrement
                                emad

                                In IKEV2 DH Key public information is exchanged in packet 1&2 by the initiator and responder.

                                Below is the wireshark dump of  IKEV2 DH Key exchange data (Public information of DH algorithm, P,g and g^xa)

                                Can any body help me to  extract/decode exact  value of p,g and g^xa.

                                thanks in adavance

                                 

                                isakmp.typepayload

                                 

                                isakmp.nextpayload : nonce(40)

                                 

                                isakmp.payloadlength: 264 bytes

                                 

                                isakmp.key_exchange.data

                                33:1b:ca:15:c1:c7:19:e7:79:66:49:67:af:98:13:bc:6b:36:e4:d5:cb:26:37:bd:06:56:49:6b:95

                                :4c:7f:54:9c:5c:14:6a:68:df:c1:cb:de:60:f8:69:fa:1e:b3:e7:39:a1:03:00:b5:2f:a7:36:b9:a0

                                :74:85:6e:8e:a9:12:a6:e5:46:0c:96:c5:83:91:bb:e4:17:ce:f1:a2:7d:8b:7e:25:bf:9f:a9:69:4e:

                                c6:03:48:bc:ee:e5:fd:d2:41:d5:2c:68:c0:51:da:89:1b:bd:1d:0c:db:0b:3b:95:2f:9f:25:9b:ca:cc

                                :1a:c8:8b:6b:0c:ac:87:6c:99:e3:73:d1:f7:b4:0d:53:05:e1:77:3d:32:e7:47:0f:28:f8:7c:0c:7c:30

                                :9a:dd:2f:5a:6a:11:92:e5:87:3e:aa:da:36:67:9d:b2:26:84:4c:7a:5e:d2:fe:41:03:d6:b9:aa:96

                                :ad:db:49:7f:d4:79:e3:55:d3:10:95:51:1b:f6:d6:4c:d6:3e:69:01:98:dc:7b:c8:78:75:58:fa:1b

                                :ae:f9:07:f9:f2:e5:c2:66:9d:23:17:c0:bc:ae:95:12:e6:be:38:5c:fa:8d:8a:33:98:66:77:f5:91:b5

                                :47:24:06:8b:8c:7f:9e:94:5c:0d:d3:ae:6f:a5:2f:b0:06:40:ad:3f:93

                                 

                                Emad

                                • 13. Re: Diffie-Hellman operation - g and p aggrement
                                  CCruz

                                  All you need to know about DH and Hard function usign Generators and Prime Modulus.

                                   

                                  http://www.youtube.com/watch?v=3QnD2c4Xovk

                                   

                                  hope it helps,

                                  best,

                                  • 14. Re: Diffie-Hellman operation - g and p aggrement
                                    Rama Krishnan

                                    Mikis/All, Can you explain what does actually Nonce(random #) faciliate? Key exchange or Encryption.? Posing this question again since I still curious to know what exactly happening in before and after DH key exchnage(Particulary about SKEY_a,SKEY_d,SKEy_e)

                                    -Krishna

                                    1 2 Previous Next