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

[Tero Kivinen <[e-mail]>]

Rodney Thayer writes:
> [this draft we keep talking about is going through the ietf draft papermill as we speak... a preliminary version is at <http://wg.unitran.com/ietf-ipsec>]
> 
> At 02:54 PM 9/10/98 +0300, you wrote:
> >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
> >
> >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).
> So a random packet from an illegitimate address identified with a
> certificate from example.com (a defined-to-be-invalid domain) is
> fine?

Yes, provided that the other end also have the private key of that
public key in the certificate AND the certificate is signed by the CA
I trust AND my policy database have entry that example.com is valid
host to connect. 

> So the actual identity and the sanity of that identity are irrelevant?

Identity is just a key to be used when searching certificate and the
entries from the policy database. The actual value doesn't matter. If
my policy database says that the identity is valid and it should be
allowed to connect, the sanity of it is not a issue. How are you going
to check sanity of key-id? You just use that key id as a key to your
policy database and map it to some policy, and some authentication
information. 

> but you're saying ignore the legitimacy of the identities relative
> to the rest of the world... 

I am saying, that in most cases you should not trust only the
certificate to give access to your host, you also should have some
kind of policy statement (authorization) saying if that yes the owner
of that certificate is authorized to do something.

For some cases it is ok just to allow anybody in who can provide the
certificate signed by verisign, but at least in VPN boxes you propably
dont want to use that kind of policy. 
-- 
[e-mail]                               Work : [phone]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/