[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

comments on draft-ietf-ipsec-pki-req-01.txt - alternate names

draft-ietf-ipsec-pki-req-01.txt policy about alternate names is:

> 4.1.2 subjectAltName Name Format
> 
> For IPSec devices the actual name of the subject is stored in the
> subjectAltName field.  This field MUST contain exactly one of
> these values:
> 
>    - ipAddress
>    - dNSName
>    - rFC822Name

And in section (3.3)

> The subjectAltName field must be checked for validity.  For
> ipAddress, the address MUST be checked to confirm it is valid for
> the IKE negotiation in progress.  For dNSName the name must be
> retrived from the DNS to validate it is valid for the IP address
> which was the source of the certificate, if known, and for the
> IKE negotiation in progress.  For rFC822Name, the email address
> must be checked according to the style of SMTP to ensure email
> name validity.

So the policy is that IPSEC devices must select ONE ID that must
recognized by all the other devices that want to communicate with it.
This may be problematic if the devices is known by different identities
to different peers. IPSEC devices are usually gateways and have more
than one IP addresses, forcing them to have only one ipAddress every one
to know them by that particular IP address.

Specifying thing that must not be in a certificate may prevent the
certificate to be used for other protocols. I.e. if one application
requires the certificate to contain IP address and another require DNS
name, the device will have to have at least two certificates.

Another situation may be when the IPSEC device is behind a NAT device,
it can put his translated address in the certificate, but then it would
not be able to use this certificate to communicate with local
application (IPSEC or others) that know him only by his local address.

I suggest an alternative approach where the IPSEC device will put his
certificate everything that might help some one to identify it, and let
the peers look there for something that identifies it for them, ignoring
all the other information. What I suggest is:

Certificate contents:
For IPSec devices the actual name of the subject is stored in the
subjectAltName field.  This field SHOULD contain all the names that the
device is know by other IPSEC devices. At least one of the following
names forms SHOULD be included:
    - ipAddress
    - dNSName
    - rFC822Name


Certificate validation:
The device MUST check that the certificate belongs to the peer in the
IKE negotiations. It SHOULD do it by testing the subject name, or the
alternate name forms: ipAddress, dNSName, rFC822Name or some combination
of them. The ipsec device MUST handle cases where there are multiply
alternate formats, or multiply values for the same formats. It SHOULD
ignore any name that it does not recognize.

regards,

	Moshe

-- 
-----------------------------------------------------------------------
Moshe Litvin                    Check Point Software Technologies Ltd.

moshe@checkpoint.com            Tel:   +972-3-753-4601 (972-3-753-4555)
                                Fax:   +972-3-575-9256
-----------------------------------------------------------------------
Follow-Ups: