Re: Adding revised identities to IKEv2

[Stephen Kent <kent@bbn.com>]

At 6:07 PM -0800 11/7/02, Jan Vilhuber wrote:
>I *think* what paul was saying (jump in any time, Paul ;), is that
>with pre-shared keys, the identity (in MM) is clear: It's the IP
>address on the IKE packet. After the exchange has completed, you know
>you've given access to the peer who's identity is "IP address
>X.X.X.X".
>
>With certificates people generally don't have a clear idea who exactly
>they are talking to, because the linkage between the 'key' and
>something we humans can grok is (apparently) confusing.
>
>So generally ALL you know/configure is some trusted root, and if the
>certificate can be validated, we let them in. The question of "who did
>we just let in" is a bit unclear, which I believe is what Paul is
>trying to fix with his proposal.
>
>It SORT of relates to authorization, I believe. In the above example,
>access-control is done via the CA, i.e. ANYONE with a (valid;
>non-revoked) cert from <this CA> gets access (i.e. as long as we can
>validate the cert, access is granted). While that seems
>semi-reasonable in some cases, I doubt it works for everyone..
>
>Now I'm not sure I was any clearer than Paul. Sigh.
>
>I've been meaning to read Brian Korver's draft for a few months now,
>and it keeps slipping through the cracks.
>
>jan
>

The intent in 2401 is that if one wants to make fine-grained access 
control decisions, the form of authentication used should not matter. 
The ability to specify a source or dest IP address in symbolic form 
is specifically intended to support use of certs with various name 
forms, e.g., when a user has a dynamically assigned address. So, for 
example, you can create and SPD entry with a DN or with a DNS name 
and have it bound, dynamically, to the IP address assigned to the 
named entity at the time the IKE exchange takes place.

In the course of working on 2401bis I have learned that we did not do 
a good enough job of explaining this in 2401, and the intent is to 
make it very clear in 2401bis. But I would hope that we do not 
anticipate degrading the capability in IKE v2. There is no good 
reason I can see for having coarser granularity access control 
capabilities based on the use of certs vs. legacy authentication 
systems.

Steve