[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Matching ID with cetificate's subjectName and subjectAltName
At 09:40 08.08.01 -0700, Eissa, Mohamed wrote:
>Hi,
>
>The "PKIX profile for IKE" draft mentioned that the ID used in IKE
>negotiation, must match with the subjectName or SubjectAltName within the
>peer certificate.
>
>Can someone please help me to understand the risk involved with not doing
>this match during MAIN/AGGR modes?
>
>Mohamed Eissa
>Intel of Canada
>
Risk? The protocol is simply useless if you don't check it.
Example:
You contact server 192.168.22.9. Now, the server sends a certificate
with DN = "C=US, O=corp". The certificate is still valid and
the signature check succeeds.
Now. What good this is? Anybody with a valid certificate can
the hook of the server 192.168.22.9 and place his own there,
and you won't notice. He won't have the private key of the server, but
that does not matter. He puts his _own_ private key and cert there.
You won't notice because you accept all certificates.
So, the main goal, making sure that the server is really the server
you expect it to be, can't be reached.
=> A client must know which certificate to expect.
Solution (1):
You tell the client which certificate the server will use. The
full DN. letter by letter.
Solution (2):
You put the IP address (or dns) into the certificate.
The client will check that the cert actually contains the ID
it's expecting.
Solution (1) is subjectName, solution (2) is SubjectAltName.
The IKE ID simply tells the client which (server) cert to use. It points
to a certificate. After all, the client could ignore all
certs sent by the server, take the IKE ID and ask LDAP for
a cert.
Again:
The client contacts server 192.168.22.9. The server answeres
with IKE ID 192.168.22.9. The client is happy with that. The
client also receives one or several certs. It looks for the one
with SubjectAltName 192.168.22.9 and checks the signature with it.
Jörn