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

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



Rodney Thayer wrote:
> 
> 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.

But you add a lot of complication. First I have to manage a lot of
certificates.  I also have to know by which name I am known to each
entity.


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

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

As with your original suggestion if the identity was changed you MUST
get a new certificate. If one of the identities is transient don't
include it in the cert, this is why I said SHOULD and not MUST.

As for the complication - it is more complicated to iterate through the
alternate names looking for something that you recognize. But it much
more complicated to manage several certificate and decide who should get
what.


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

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


References: