Re: Confirm decision on identity handling.

["Andrew Krywaniuk" <askrywan@hotmail.com>]

>Can you give a real-world example of the process you describe below?
>That is, what sort of ID payload would be sent, what might it contain,
>and how would the policies look against which this compared?

Sorry for the late reply (I wasn't following the list last week). Anyway, I 
think we sometimes get too hung up on defining scenarios, rather than 
providing a framework for interoperability and allowing vendors to choose 
their own problem spaces. But nonetheless, I can give you a few scenarios:

1. A customer decides to consolidate its VPNs. Previously, there were 3 
different VPNs at various branch offices and the policies were not 
homogenous. Some of the policies are expressed in terms of USER_FQDNs, 
others by IP address and still others by distinguished name. The id payload 
provides a key into the policy database and allows a single search pass 
instead of 3.

2. For remote access, it is common to use some kind of XAuth-like process 
where the true identity of the user is not authenticated by IKE itsself. For 
IKEv2, the decision on whether to authenticate the user with EAP may depend 
on the contents of the id payload. Imagine that the phase 1 authentication 
is performed with a machine certificate and the user's id is completely 
divorced from the certificate.

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.





>From: "Scott G. Kelly" <scott@airespace.com>
>To: Andrew Krywaniuk <askrywan@hotmail.com>
>CC: ipsec@lists.tislabs.com
>Subject: Re: Confirm decision on identity handling.
>Date: Thu, 01 May 2003 09:10:05 -0700
>
>Hi Andrew,
>

>
>Thanks,
>
>Scott
>
>Andrew Krywaniuk wrote:
> >
> > >And what is the point of this? It seems to make the policy lookup
> > >slightly simpler, since you can get the ID payload from the packet
> > >instead of parsing the cert. But this is only on the front end, because
> > >you still have to parse the cert, and you have the added step of
> > >verifying that the ID matches something in the cert (if you care about
> > >security).
> >
> > Some people have been referring to the id as a "key for policy lookup". 
>The
> > idea is that if you have a decorrelated database (or an ordered database
> > where more specific rules serve only to grant privileges and not to take
> > them away), a unique id can allow a very fast policy lookup.
> >
> > However, once this lookup is complete, you can throw the id away. It is 
>not
> > necessary to check the id against a field in the certificate. You only 
>have
> > to check the certificate against the policy (and the signature against 
>the
> > public key and the validity of the cert chain).
> >
> > I wish people would stop saying thing like "you can check the id against 
>the
> > certificate if you require a more stringent policy check."
> >
> > Andrew
> > --------------------------------------
> > The odd thing about fairness is when
> > we strive so hard to be equitable
> > that we forget to be correct.
> >
> > _________________________________________________________________
> > STOP MORE SPAM with the new MSN 8 and get 2 months FREE*
> > http://join.msn.com/?page=features/junkmail

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail