Re: Adding revised identities to IKEv2

[Michael Thomas <mat@cisco.com>]

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