Re: Adding revised identities to IKEv2

[Jan Vilhuber <vilhuber@cisco.com>]

On Thu, 7 Nov 2002, Michael Thomas wrote:

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

Well that's why I said "(in MM)", because in main-mode you don't have
a choice for pre-shared keys: the IP address in the packet is your
identity.

And yes, as you point out, main-mode with pre-shared keys is
impossible to deploy when your peers have dynamic IP addresses, which
is why all (I think) deployments that include road-warriors or other
forms of dynamic addresses are relegated to aggressive mode, where you
CAN use the Identity Payload contents to select the keys.

Or use certificates. ;)

Or *shudder* a group-key for 0.0.0.0 (any) followed by xauth. Don't
laugh. This exists!

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

Agreed. It's not impossible. It's merely messy, as paul pointed
out.

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

Yes.

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

I'll step back and let Paul talk for himself again now :)


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

Correct. Assuming you can agree with others on exactly WHICH field is
the username etc etc. For a single domain of administration, that's
trivial. But across administrative boundries, it may be rather hard.

And then I'm far from sure I got Paul's argument correct, so I'll step
back into the shadows.

jan
 --
Jan Vilhuber                                            vilhuber@cisco.com
Cisco Systems, San Jose                                     (408) 527-0847

THE NETWORK WORKS,
NO EXCUS NFS server mastiff-fddi not responding still trying