[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-ietf-ipsec-pki-req-01.txt - alternate names
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Moshe" == Moshe Litvin <moshe@cale.checkpoint.com> writes:
Moshe> So the policy is that IPSEC devices must select ONE ID that must
Moshe> recognized by all the other devices that want to communicate with
Moshe> it. This may be problematic if the devices is known by different
Moshe> identities to different peers. IPSEC devices are usually gateways
Moshe> and have more than one IP addresses, forcing them to have only one
Moshe> ipAddress every one to know them by that particular IP address.
The case of the gateway with multiple IP addresses is a redherring:
gateways should be abiding by the router requirements RFC, which means that
the should have a well known router-id (i.e. one of their IP addresses).
The problem still exists: some devices may prefer to be known by IP address
for some peers and by DNS name for other peers (or the same peer at
different times)
[i.e. when my notebook is on the road, its uses a DNS or DN name, while
when it is in my home office with a static IP, and some physical security, it
is known by its IP address and gets some additional priviledge]
Moshe> Specifying thing that must not be in a certificate may prevent the
Moshe> certificate to be used for other protocols. I.e. if one
Moshe> application requires the certificate to contain IP address and
Moshe> another require DNS name, the device will have to have at least
Moshe> two certificates.
I'm not sure that we should prevent certificates from being used for
multiple purposes, but I'm not sure that we should encourage it either.
Moshe> Certificate contents: For IPSec devices the actual name of the
Moshe> subject is stored in the subjectAltName field. This field SHOULD
Moshe> contain all the names that the device is know by other IPSEC
Moshe> devices. At least one of the following names forms SHOULD be
Moshe> included: - ipAddress - dNSName - rFC822Name
I would change the second SHOULD to MUST. (i.e. at least one MUST be included)
Moshe> Certificate validation: The device MUST check that the certificate
Moshe> belongs to the peer in the IKE negotiations. It SHOULD do it by
Moshe> testing the subject name, or the alternate name forms: ipAddress,
Moshe> dNSName, rFC822Name or some combination of them. The ipsec device
Moshe> MUST handle cases where there are multiply alternate formats, or
Moshe> multiply values for the same formats. It SHOULD ignore any name
Moshe> that it does not recognize.
We still get into the question of whether the CA is authorized to verify
all of these things with a single signature. For the matter, it seems clear
to me that these are all totally useless unless signed by a CA key directly
under the control of the person administrating the gateway. But, perhaps
we shouldn't try to solve that problem, just to document it.
:!mcr!: | Network and security consulting/contract programming
Michael Richardson | Firewalls, TCP/IP and Unix administration
Personal: <A HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
Corporate: <A HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca</A>.
ON HUMILITY: To err is human, to moo bovine.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQB1AwUBNfV2B9iXVu0RiA21AQHcDAMAugpRDVCp+EIuZfGez5nosFoTQSVeJbAO
H972XoagMvfh7uxq3tx2iO35B+ya6GpAwniea9bkWpw41jIW5ZCja40g+PWL+KY0
aFHrJ7HqWH00DRrHpMob+/DgjcpdBz46
=tk31
-----END PGP SIGNATURE-----
References: