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

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

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

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

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

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

but you're saying ignore the legitimacy of the identities relative to the rest of the world...
Follow-Ups: References: