[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: