Re: Confirm decision on identity handling.

[Michael Thomas <mat@cisco.com>]

Eric Rescorla writes:
 > Uri Blumenthal <uri@bell-labs.com> writes:
 > 
 > > Eric Rescorla wrote:
 > > >> > >  > > You could have a security policy that ignored the identity in the cert
 > > >> > >  > > ("allow an SA with these restrictions to anyone who has a cert from
 > > >> > >  > > XYZRoot"), or one that was identity-based ("let chris@example.com make
 > > >> > >  > > an SA").
 > > >>Well, I don't see it. The desire to restrict or
 > > >>permit based on header classification seems
 > > >>completely orthogonal to the policy decision of
 > > >>what constitutes "authenticated enough".
 > > > Huh? Because I want to be able to have applications make security
 > > 
 > > > decisions based on the IP address of the peer and that means that
 > > > the certificate has to be bound to the IP address.
 > > 
 > > I jumped in late, so probably missed some important parts of this
 > > conversation. But binding certificates to IP addresses doesn't
 > > seem like a good idea at all, because of how short IP address
 > > lifespan may be.
 > Given the kind of information the stack has, there are many
 > cases where this is the only reasonable thing they might be 
 > bound to.

Ok, I'll bite: what are some of those cases? It
can't be the actual IPsec SA since that's fully
described by the SPI (excepting multicast). And a
CA which issues a cert for mat@cisco.com is a
fully unique identifier, so I don't need
additional information in the form of the routing
tag to disambiguate the identity. So what
information is it that the stack is lacking that
would *require* use of an IP address in the
credential itself?

I'm with Uri. Binding IP addresses to certs sucks.
Think mobile IP.

	     Mike