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

["Steven M. Bellovin" <[e-mail]>]

In message <[e-mail]>, Tero Kivinen writes:
>Rodney Thayer writes:
>> >> 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
>> 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 think that there MUST not be any binding with the identity and the
>ip address of the source packet. The packets can come in from any
>source ip address, the identity payload contains the real identity
>information that should be used to first find the certificate (there
>is NO need to do any dns queries etc to map FQDN to ip address, if the
>identity payload is fqdn then the certificate MUST contain the same
>dns name in the dNSName).

There's a delicate point here.  You're absolutely right that certificate
identities are far better than addresses -- IP addresses are transient
and are quite meaningless as long-term addresses.

However -- consider the case of a bump-in-the-wire or firewall-based
IPsec box.  Such a box knows *only* the IP address of the destination.
For that matter, its policy table saying what should be encrypted
is based on IP addresses.  This has several implications.  First, of
course, certificates must be retrievable knowing only the IP address
of the destination.  (You could just ask the destination, of course.)
This certificate needs to mention the IP address in some fashion, to
guard against active attacks.  The original user undoubtedly typed a
DNS name, which means that we really need DNSsec, to protect that mapping.
In fact, there are a trio of resources that need to be linked:  the
"identity" certificate (see below), the domain name, and the IP address.
The latter two can be tied together via DNSsec (in both directions?, or
does the cross-check suffice?); I suggest that the identity certificate
be a signing certificate, and that it be used to create temporary
certificates that also contain the domain name and IP address.

(To avoid distractions -- when I say "identity certificate", I mean "your
identity to the party with whom you wish to communicate.  That is, it
may be a certificate issued to you by the corporate firewall administrator,
or your electronic bank, or whomever.  Or it may be an X.509 certificate
with your government's idea of your One True Name.  For our purposes here,
the question is irrelevant.)

There is an asymmetry between clients and servers.  For servers, the
domain name is often the primary identity to be used in the certificate.
We thus need strong protection on the domain name to IP address mapping,
and on the IP address to certificate mapping. For clients, the domain name
and IP address are quite transient, and the proferred certificate is
all that matters.  "Is this the party to whom I am speaking" is more
than just a tag line -- it's all you know, unless there's an identity
in the certificate.