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

Re: Confirm decision on identity handling.



Eric Rescorla writes:
 > Michael Thomas <mat@cisco.com> writes:
 > 
 > > 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?
 > Huh? The user asks you to initiate a TCP connection to
 > 1.2.3.4. How else do you propose to ensure that you've
 > done that other than by checking the certificate at
 > SA establishment time?

You didn't answer my question. And I hardly know
where to start on the identity/routing tag
conflation you seem to be making. There isn't a
binding in IPsec between TCP connection -- or any
sort of transport connection -- and the SA
establishment, so your question is a non-sequitur.

IP addresses can be used as identities, but so can
RFC 822 addresses, etc. And IP addresses have huge
downsides, especially for mobility, unlike RFC 822
addresses. Any desire to use IP addresses as
identities should be considered harmful.

		Mike