Re: Confirm decision on identity handling.

[Eric Rescorla <ekr@rtfm.com>]

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?

-Ekr

-- 
[Eric Rescorla                                   ekr@rtfm.com]
                http://www.rtfm.com/