Re: Confirm decision on identity handling.

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

I wasn't at the San Francisco meeting, but I will add my voice to the 
consensus (thus slightly reducing its roughness).

I would argue that the identity payload has never been authoritative, and it 
has always functioned as a policy hint, even in shared secret mode. (It is 
theoretically possible to have more than one user sharing the same secret, 
or - in the case of the initiator - multiple users with different secrets 
sharing the same id. I have heard that this has even been attempted on the 
responder as well.) Anyway, I digress.

The receiver is authenticating the sender, so the receiver gets to choose 
which field in the certificate is authoritative. However, there may be cases 
where a user could match more than one policy rule (where the level of 
authorization is different). The receiver can use the sender's id to ensure 
that he agrees that the sender is who he thinks he is. The name I coined for 
this feature was the "gratuitous id check" (mostly because it tends to annoy 
people who don't care that their policy is incorrect as long as they can 
still set up a tunnel).

E.g. A gateway has a number of policy rules for static peers (servers, 
gateways, etc) and a fall-through rule for remote access users. The static 
peers have different levels of authorization. Due to an ambiguity in 
configuration, one of the servers is granted basic access but not the 
extended privileges. The gratuitous id check detects this and fails the 
connection (or does something else of your choosing).

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




_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail