Re: Adding revised identities to IKEv2

[Stephen Kent <kent@bbn.com>]

At 9:13 AM -0800 11/13/02, Paul Hoffman / VPNC wrote:
>At 2:43 PM -0500 11/12/02, Stephen Kent wrote:
>>As many of you know, I try to avoid the T-word (trust) in almost 
>>all security technology discussions. I'd like to suggest that it is 
>>inappropriate in this discussion as well.  Let me explain:
>>
>>	- two IPsec peers do not necessarily trust one another. they 
>>need to communicate securely, but that does not equate to trust in 
>>a broader sense.  the access controls in IPsec permit each peer to 
>>limit the part of the address space to which the other is granted 
>>access, and to constrain the protocols that are employed.
>
>Assume you have someone who doesn't let most people communicate with 
>them in a particular way, but does let some people communicate with 
>them in that particular way after verifying their identity. You are 
>saying that that is not "trust"? If so, then we are splitting hairs. 
>"I authorize you to do X" means that I trust my method of being sure 
>that you are you, and that I trust you to do X correctly and safely.

In your example, I rely on my enforcement mechanisms to allow you to 
access only what we agree you should access. You could call that 
trusting my enforcement mechanisms, but that's not the way the term 
"trust" is usually employed here.

The term trust might be better applied to the second aspect of your 
example, but  again we are much better off from a security 
perspective if we put in place mechanisms to constrain the damage 
that can be done by the entity who is authorized to "do X." I think 
that is how we tend to engineer many systems, although with varying 
degrees of success. A security administrator does not trust all the 
folks authorized to access a system to do the right thing; he uses 
all available mechanisms to constrain their behavior as well as 
possible, just in case they don't do the right thing.

>>I suggest that we better document these notions, and offer as 
>>examples, the sort of identification and authentication processes I 
>>note above as we go forward with IKE v2.
>
>It doesn't look like this any different than what we have in IKEv1 
>today: it just looks like different nomenclature. Unless this would 
>make IKEv2 more secure, or would make it easier for administrators 
>to understand what it is they are doing, it doesn't seem like 
>changing the nomenclature from IKEv1 would be a good idea.

I don't recall the extent to which the T-word is used in existing IKE 
v1 documents, and I don't mean to suggest changes of terms just for 
the hell of it, but as we go forward creating new documents, 
including ones that try to better explain how to deal with IKE v1 and 
PKI, I'd suggest we avoid undue use of "trust."

Steve