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

The process should go like this:

1) First find a valid certificate matching the identity payload. This
means that if the identity payload contains ip address the certificate
must contain same ip address (it may contain other ip address also).
If the identity payload contains fqdn then the certificate must
contain the same name (the ip address matching the fqdn is not enough
unless the dns query was done in the secure way (dns sec or local
database)).

2) Find the policy information using the identity payload. This policy
information informs if the other end is allowed to connect and what
kind of parameters are needed for it.

3) Verify the signature sent by the other end using the public key in
the certificate found.

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

Sorry you cannot get everything. Certificate processing is complicated
thing, but that matching is some of the most easiest thing to do.
There is only one key (identity payload) and you know the type of the
key (ip, fqdn, user@fqdn, distinguished name). You just find the
certificate that matches that. 

> What if my ip address changes?

Then you get a new certificate and revoke the old one. If you plan to
change your ip address often, you propably want to use something else
like fqdn or user@fqdn instead. 

> what if the rfc822name changes relative to the host?

If the username changes then you propably want to create new
certificate anyway. 

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

No, you must not ignore it you must simply match it against the
contents of the identity payload, and that matching must be done
securely so no dns queries etc can be involved in that.
-- 
kivinen@iki.fi                               Work : +358-9-4354 3218
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/
Follow-Ups: References: