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

[Rodney Thayer <[e-mail]>]

At 07:33 PM 9/8/98 +0200, you wrote:
>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.

Suppose you have a multi-homed firewall device, with if1, if2 and if3.
I believe that you'd possibly have several certificates, and you'd use 
the appropriate certificate to talk in different situations.  So, for example, 
you might have three certs issued, one for each interface.

>
>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.

That's right.  Life is complicated, IPSec life is more complicated, let's keep the certs simple.
If you are known as 10.0.0.1 to some people and xxx.yyy.com to others, your life is already complicated.

>
>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.

If you put an IPSec device behind an NAT device then your IP address isn't your identity and you should use something else, like an FQDN.  Or, the device on the other end has to somehow be willing to cope with the difference between the identity in the cert and the ip address it's talking to.

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

This makes the cert processing at all levels more complicated... I don't like it.  What if my ip address changes?  what if the rfc822name changes relative to the host?  I think we'd end up with some lowest common denominator where the only safe thing to do is to ignore the identity in the cert, which wasn't the intent.

>
>
>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.
>
>[e-mail]            Tel:   [phone] (972-3-753-4555)
>                                Fax:   [phone]
>-----------------------------------------------------------------------
>