Re: Adding revised identities to IKEv2

[Uri Blumenthal <uri@lucent.com>]

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. 

Fully agree. Trust is about authorization, which is not IPsec's
domain (IMHO).

> - 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. 

Agreed.

> - with regard to identities, IPsec supports two basic types
> of identities: addresses and symbolic names.

And symbolic names IMHO is the only way to establish/authenticate
a secure connection in a dynamic environment.

> - 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.

Absolutely. But start from symbolic names, and map them to IP address
for Phase 2. Seems easy/trivial to implement.

> - 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.

Oh sure. If I say the entity name is "Uri Blumenthal" - then there
has to be a key/cert associated with that name. As it only matters
for signing the Phase 1 exchange to validate IP address from which
the traffic is originating, for subsequent Phase 2 things.

> 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?

I strongly support.  

And I want a relaxed identification - something like "as long as 
I can associate a key with the identity, the identity is OK".