Re: Adding revised identities to IKEv2

[Jan Vilhuber <vilhuber@cisco.com>]

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



On Thu, 7 Nov 2002, Michael Thomas wrote:

>
> OK, I'm pretty confused let me try to tease this
> apart:
>
> Paul Hoffman / VPNC writes:
>  > At 12:58 PM -0800 11/7/02, Michael Thomas wrote:
>  > >Paul Hoffman / VPNC writes:
>  > >  > At 3:52 PM +0100 11/6/02, Francis Dupont wrote:
>  > >  > >But it shows we have to understand exactly what could/should
>  > >  > >be the usage of addresses in key management protocols too (see after).
>  > >  >
>  > >  > Why? What people have found from many years of VPN deployment is that
>  > >  > customers generally want one of two things:
>
>  > >  > - The ability to say "let any gateway with this identity set up any
>  > >  > kind of tunnel with me"
>  > >  > - The ability to say "let the gateway with this identity set up a
>  > >  > tunnel with these features"
>
> To my mind, the difference here is what a given
> identity is authorized to do: "any kind :: these features".
> This is regardless of how identity is established.
>
>  > >  > For preshared secrets, there is no question of the identity. For PKIX
>  > >  > certificates, the identity problem is so convoluted, almost all
>  > >  > customers say "any identity is OK as long as the certificate
>  > >  > correctly chains to this trusted root". The identity is logged, but
>  > >  > the type of identity is not related to the ability to set up tunnels.
>
> So I do not see how these two paragraphs relate to
> each other. Taken at face vallue, it seems that
> you might be saying that there is no way to take a
> cert-based identity and use it to differentiate
> authorization, where as a symmetric key based
> identity is easy. This doesn't make any sense to
> me unless there is some sort of difference with
> authz (method of application?) because it is
> incomprehensible to me that there is no clear
> binding between the public key and the name
> mapping the cert provides. If that were true, why
> would you bother with certs at? Or are you
> actually saying that the name binding provided
> by the certificate is worthless??
>
> There must be something that's missing here.
>
> 	   Mike
>

 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying