Re: Adding revised identities to IKEv2

[Michael Thomas <mat@cisco.com>]

Jan Vilhuber writes:
 > I *think* what paul was saying (jump in any time, Paul ;), is that
 > with pre-shared keys, the identity (in MM) is clear: It's the IP
 > address on the IKE packet. After the exchange has completed, you know
 > you've given access to the peer who's identity is "IP address
 > X.X.X.X".

   I assume we're talking about IKE identities, not
   IPsec manual key "identies" where that's your only
   choice... I suppose that this all depends on what
   you use for the identifier for the symmetric key
   identity. It could well be an IP address, but that's
   rather messy and obviously would have issues with
   DHCP, blah, blah, blah.

   So once you change to some more abstract notion
   of an identity, you end up a name/key binding which
   needs to be accounted for. With symmetric keys, that's
   fairly straightforward: you always have to store the tuple somewhere
   and fetch it when you need to auth/authz. For public
   key identities, that's not inevitable since the cert
   provides a portable credential (possibly with 
   attributes), but it certainly doesn't *preclude* 
   fetching those name/key tuples in an analogous way
   as one would with symmetric key identities.

   So, I guess I'm lost unless there are some
   assumptions about where the auth/authz
   information is transported/formated. I can
   easily understand how trying to encode authz
   into a cert as being a huge minefield. I don't
   understand it if it's only a identity and is
   used in a similar way to symmetric key identities.

 > With certificates people generally don't have a clear idea who exactly
 > they are talking to, because the linkage between the 'key' and
 > something we humans can grok is (apparently) confusing.

   Er, why? If I put some x.500 version of
   mat@cisco.com into the DN, or mat@cisco.com in
   the subjectaltname, or whatever, it's just a
   matter of agreeing which one to look up the
   authz information, right? I can see how
   confusion of which one to agree on might be
   a bit messy, but it doesn't seem like it's
   the ridiculously messy that Paul's alluding to.

 > So generally ALL you know/configure is some trusted root, and if the
 > certificate can be validated, we let them in. The question of "who did
 > we just let in" is a bit unclear, which I believe is what Paul is
 > trying to fix with his proposal.

   *Only* if you don't have access to a name/key
   store elsewhere (including authz info), right?

		   Mike