Skip to main content

IKE and Diffie-Hellman

More
17 years 10 months ago #18010 by ramasamy
Hi,

Can any one tell me the difference between IKE and Diffie-Hellman
More
17 years 10 months ago #18012 by Smurf
Replied by Smurf on topic Re: IKE and Diffie-Hellman
Hi there,

IKE is used in the IPSec process to setup a secure means of communication between the two IPSec peers to then start building the IPSec Tunnels, also authenticates the peers. IKE will use Diffie-Hellman as a way of deriving a shared secret key that can be used to secure the communication process for setting up things like an IKE Security Association and the 2 IPSec Security Associations (i am pretty sure there is 2, one for each way).

Security Associations are generated to govern the settings that are agreed to secure the communications (for example, Hashing, Encryption, Lifetimes, etc...)

So to re-cap

IKE - Used to authenticate and protect the identity of the peers, setup a secure channel to then start negotiating the IPSec (or IKE Phase 2) parameters.
Diffie-Hellman - This is the mathematical process of taking a shared, unsecured path and negotiating a shared secret key (dynamically) so both ends can start to secure communications

Hope it helps

Wayne Murphy
Firewall.cx Team Member
www.firewall.cx

Now working for a Security Company called Sec-1 Ltd in the UK, for any
Penetration Testing work visit www.sec-1.com or PM me for details.
More
17 years 10 months ago #18320 by Maki
Replied by Maki on topic Re: IKE and Diffie-Hellman
Just to support what Smurf has described...have a look at the following link:

docs.hp.com/en/J4256-90003/ch01s04.html

Diffie-Hellman was one of the first algorithms used for encryption using public keys. SSL comunications over the internet incorporates a Diffie-Hellman exchange at some point. The famous RSA algorithm follows the same method. Here is an extract from the RFC2246:

RFC 2246 The TLS Protocol Version 1.0 January 1999


F.1.1.3. Diffie-Hellman key exchange with authentication

When Diffie-Hellman key exchange is used, the server can either
supply a certificate containing fixed Diffie-Hellman parameters or
can use the server key exchange message to send a set of temporary
Diffie-Hellman parameters signed with a DSS or RSA certificate.
Temporary parameters are hashed with the hello.random values before
signing to ensure that attackers do not replay old parameters. In
either case, the client can verify the certificate or signature to
ensure that the parameters belong to the server.

If the client has a certificate containing fixed Diffie-Hellman
parameters, its certificate contains the information required to
complete the key exchange. Note that in this case the client and
server will generate the same Diffie-Hellman result (i.e.,
pre_master_secret) every time they communicate. To prevent the
pre_master_secret from staying in memory any longer than necessary,
it should be converted into the master_secret as soon as possible.
Client Diffie-Hellman parameters must be compatible with those
supplied by the server for the key exchange to work.

If the client has a standard DSS or RSA certificate or is
unauthenticated, it sends a set of temporary parameters to the server
in the client key exchange message, then optionally uses a
certificate verify message to authenticate itself.



Cheers ;-)

Maki

"Appear weak when you are strong and strong when you are weak"
Time to create page: 0.117 seconds