Re: Adding revised identities to IKEv2

[Stephen Kent <kent@bbn.com>]

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.

	- with regard to identities, IPsec supports two basic types 
of identities: addresses and symbolic names. IP addresses are easy to 
understand and to use but don't work well for a growing number of 
circumstances where addresses are assigned dynamically. Names are 
also easy to understand, should be easier to manage, but require more 
infrastructure support. the SPD accommodates use of symbolic names in 
lieu of IP addresses to accommodate dynamic address assignment, or 
just for ease of access control management.

	- when names are used as identities, we need to be able to 
map the name to a current address (during SA establishment) so that 
we can make later decisions on a per-packet basis using the current 
address. in this case, we verify that the named entity is at whatever 
address is asserted by it in real time, and just use that address 
going forward.

	- we don't have to trust an IPsec peer to assert the right 
name for itself or an entity behind it. we need to have an 
authentication mechanism that allows us to verify that the asserted 
name is valid relative to some framework for names. for example, two 
organizations, a.com and b.com could each issue certs to their users 
and embed the DNS names of user machine in the certs.  (One could use 
the DC convention to embed a DNS name in the Subject field, or use 
dNSName type in the SubAltName extension.) I'd rather not say that 
the CA for each organization is  "trusted" by the other organization, 
but rather that each organization acknowledges that the CA for the 
other is authorized to name entities in its part of the DNS name 
space.  By using the NameConstraints extension in cross-certs, a.com 
can make sure that certs issued by the CA for b.com (and validated by 
users within a.com) all name entities under b.com, and not in a.com 
or c.com etc. thus cross-certification is not a blanket statement of 
trust, but just an acknowledgement that the CA for an organization is 
authorized to issue certs for entities associated with that 
organization.

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.

Comments?

Steve