I know that SSL/TLS authenticates the identity of a server (and/or client) by presenting a certificate which the client sends to a CA to check the validity. This happens before the SSL/TLS connection is made, so the client knows if it is actually communicating with the entity it meant to contact.

From what I understand, IPSec uses the Authentication Header to ensure the messages are coming from the same source with which the IPSec 'connection' was initiated. (I know it is not actually a connection, but I'm not sure how else to call it). This tells the client it is communicating with the same source, but it does not actually identify the source, does it?

Does IPSec have a way to authenticate the identity of a server before establishing the IPSec 'connection'?

  • 2
    There is a lot of material online for this. All the material that comes up on the top Google hits points you to the IKE process, which handles the exchange of public keys, which works like SSL/TLS, as you mention. Have you done research on the topic? – schroeder Dec 10 '15 at 19:43
  • Yes I have done research, but from why I understand IKE does not actually identify the server, so there is not guarantee the client is not getting the public key from a malicious source, because there is no verification from a third party. I probably have understood wrong, then? – Soulrot Dec 10 '15 at 19:57
  • 1
    but it's the same as SSL/TLS, I'm not sure what you're getting at with your question – schroeder Dec 10 '15 at 20:16
  • 1
    Do you have a link to the material that you've read and you feel is relevant? – Neil Smithline Dec 11 '15 at 5:17
  • FYI: "SSL/TLS authenticates the identity of a server (and/or client) by presenting a certificate which the client sends to a CA to check the validity" is incorrect. There is not interaction between the client and the CA during the SSL/TLS connection. The client checks the validity of the certificate by verifying the CA's signature on the certificate, using the CA's public key. – mti2935 Dec 11 '15 at 15:38

IPsec uses IKE (Internet Key Exchange) to establish a security association, which includes identifying the other party.

IKE is commonly done using x.509 certs (The same type of certs you already use for everything else). These certs allow each party to rely on the authority of the issuing CA to identify the other party (They must both trust that CA).

IKE can also be done through other means, like a pre-shared key. This allows no intrinsic way to verify the identity of the other party.

  • apparently, the OP has rejected IKE as server identification – schroeder Dec 11 '15 at 15:31
  • @schroeder, IKE w/ x.509 certs is just as good as TLS identification, and he accepts that. I think OP doesn't quite understand IKE. – ztk Dec 11 '15 at 15:32
  • I had not rejected IKE as server identification, it just was not clear to me that IKE actually does provide the option to use the same certificate/CA construction as TLS, even though I did search explicitly for it. So no, I did not quite understand IKE, thank you for clearing it up. – Soulrot Dec 11 '15 at 19:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.