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

[Derek Atkins <derek@ihtfp.com>]

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