Re: "Me Tarzan, You Jane" in IKEv2-05

[Dan Harkins <dharkins@trpz.com>]

  If a gateway is both sgw.ihtfp.com and gateway.trpz.com it
will authenticate me and you differently. I will present
harkins.trpz.com (message 3 in IKEv2) and it will put me on
the appropriate VPN (for trpz.com) and make sure my packets go
where they're supposed to. You will present warlord.laptop.ihtfp.com
and it will put you on a different VPN (the one for ihtfp.com). And
it can maintain separation of flows. No problem. No need for
me to tell the security gateway who I want it to be. It'll figure
that out who to be based upon who I say I am. Since Alice identifies
herself first Bob has all the information he needs to assume the
proper role.

  I'll have to think a bit more about the raw RSA key scenario.
Off hand I don't see a need for telling Bob who I think he should
be to get that to work either. Is there a way to get your desired
functionality without "Me Tarzan, You Jane"?

  If this truely is a needed and useful feature I'll retract my
objection. I don't see a need though. 

  Dan.

On 28 Feb 2003 13:11:33 EST you wrote
> I happen to disagree with you here.
> 
> Consider a situation where you have a single IPsec security gateway
> sitting at a single IP Address serving a bunch of separate VPNs.  The
> Me Tarzan, You Jane concept allows the client to hint to the VPN server
> who it is and who it thinks it is.  For example:
> 
>         Me warlord.laptop.ihtfp.com; You sgw.ihtfp.com
> 
> Your client could say:
> 
>         Me harkins.trpz.com; You gateway.trpz.com
> 
> Someone else could say:
> 
>         Me myname; You yourname
> 
> In all cases it provides a hint of which identity to use, which is
> absolutely vital in a multi-identity situation.  It's also extremely
> useful in the case of pre-shared (cached) RSA keys, to know which key
> to lookup to verify the rest of the exchange.
> 
> Note that a number of IKEv1 implementations already have something
> like this (I know that both FreeS/WAN and KAME (racoon) have this kind
> of feature).  Also, I personally happen to use it.
> 
> -derek
> 
> Dan Harkins <dharkins@trpz.com> writes:
> 
> >   When we began the IKEv2 effort we looked at things in IKEv1 that
> > at the time sounded like good ideas but in practice were rarely,
> > if ever, used-- e.g. phase 1 negotiation (hence the 4/6 exchange),
> > complex SA offers of (((A & B) | (C & D)) | E), etc.-- and we
> > decided to get rid of them in IKEv2. While these things were rarely
> > used they had to be supported by all. They're mandatory options. 
> > I think "Me Tarzan, You Jane" will be another one.
> > 
> >   It is also poorly defined. What sort of identity is used as the
> > hint? What if the TR payloads are coarse and the identity is fine,
> > how does the SPD make sure that no packets mix that aren't from that
> > identity? When you have a pcb (or like data structure) to hang on
> > to it's possible but not all SAs will necessarily be tied to pcbs.
> > This is IP we're talking about anyway and identities and applications
> > are not in the realm of IP. Securing things based on identities or
> > applications is best left to protocol that have that context, like
> > TLS/SSL.
> > 
> >   This is a cute feature but I doubt it would be used in practice
> > and therefore it's just another mandatory option that everyone
> > has to implement but never use. It's the kind of thing we were
> > supposed to get rid of in IKEv2. Let's get rid of it.
> > 
> >   thanks,
> > 
> >     Dan.
> > 
> 
> -- 
>        Derek Atkins
>        Computer and Internet Security Consultant
>        derek@ihtfp.com             www.ihtfp.com
>