I read somewhere that ike1 does not support asymmetric authentication. Does that mean that it does nit support PKI authentication (digital certs)?
Thanks Champ
Add a comment
|
2 Answers
$\begingroup$
$\endgroup$
3
I read somewhere that ike1 does not support asymmetric authentication. Does that mean that it does nit support PKI authentication (digital certs)?
No, it doesn't mean that - IKEv1 does allow PKI authentication. What it means that both sides must share the same type of authentication.
To explain further:
IKEv1 supports several types of authentication: preshared keys, certificates, RSA encrypted nonces (don't ask). And, in IKEv1, both sides must authenticate themselves (unlike, say, TLS, where the server must authenticate itself, but the client may be anonymous).
What 'not supporting asymmetric authentication' means is that both sides must support the same type of authentication; if one side authenticates using a certificate, then the other side also must authenticate with a certificate; it cannot use a preshared key.
The reason for this is because how IKEv1 generates its keying material is tied up with the authentication method (e.g. the preshared keys, those keys are stirred into the key generation), and there are no recipes for "one side does PKI, the other side does preshared key". They cleaned this up in IKEv2 (which does support 'asymmetric authentication').
-
$\begingroup$ Wow! Good to know. I never even knew we could do different types of authentication from both ends on either Ike1 or Ike2. However, from security perspective hows this even possible on IKE2? For example as you mentioned, to use pki on one end and psk on the other? Isn’t the whole idea of ipsec security auth is that both sides must have the same auth methods? $\endgroup$– Champ885Commented Mar 23, 2023 at 23:45
-
$\begingroup$ @Champ885: with IKEv1, that assumption was built it; with IKEv2, no, it isn't. One side could authenticate using PKI and the other side could authenticate using PSK (which the first side would need to have, obviously). One might question why one would do that; however there might be some scenario that doesn't occur to me... $\endgroup$– ponchoCommented Mar 25, 2023 at 0:10
-
$\begingroup$
$\endgroup$
I'm not sure what it means. IKEv1 is specified in RFC2409 and section 5.1 lists a number of authentication mechanisms which are supported including digital signatures (including certificates) and public key encryption. It might be true that method 5.4 (authentication via Pre-shared Key) was more common in practice due to being less computationally burdensome. In the very common use case where an IPsec tunnel is being agreed between two points with a prior trust relationship, Pre-shared Keys would be a natural choice.
