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

From: Dan Harkins <[email-masked]>
Date: Fri, 28 Feb 2003 09:09:46 -0800

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.

---

From: Derek Atkins <[email-masked]>
Date: 28 Feb 2003 13:11:33 -0500

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

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [email-masked]             www.ihtfp.com

---

From: Dan Harkins <[email-masked]>
Date: Fri, 28 Feb 2003 10:35:56 -0800

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

---

From: Uri Blumenthal <[email-masked]>
Date: Fri, 28 Feb 2003 15:54:33 -0500

I find it more straightforward and practical to have
the "Me Tarzan, You Jane" explicit capability. More
than one [RSA] key is just one case.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Feb 2003 13:24:47 -0800 (PST)

Dan,

If I can draw an analogy to real life, I think
this is somewhat like when I go shopping and go to
get out a credit card, I look at their register or
what have you to see which ones they take. If they
don't take, oh say, Diner's Club then I don't
bother to pull it out.

The question is whether you believe that this sort
of capability:

1) Is needed with IPsec/IKE
2) Can't reasonably be provided other ways

If I understand you correctly -- and I don't
disagree -- you're saying that this sort of
multi-personality arrangement is just not anything
approaching the current use of IKE. The thing I'm
a little concerned about is whether that's short
sighted. VPN technology in conjunction with
wireless and mobility is still in its infancy and
VPN terminators which provide both access control
(ie for $$$) and security for the bits in the air
is a very interesting use of IPsec. Like the
credit card scenario above, it's not very clear
that you are going to have anything approaching a
homogeneous set of providers, and thus the
credentials you need to provide may in fact be
variable, depending on the services you subscribe
to.

Which brings us to (2). This is not as clear to
me, but there are a few considerations to ponder: 

1) Fast mobility for, say, voip is very time
   critical and while it's not immediately clear
   whether this would be a win or not, suffice it
   to say that less messages in the air are always
   a Good Thing, perhaps even a critical thing
2) The one thing we *do* need to be concerned
   about if done other ways is bid down attacks.
   If the cure for bid down attacks effectively
   recreates many of the same basic mechanics of
   IKE, then that's probably a Bad Thing.

So I'm not going to take a side here, but I at
least want this scenario both considered, and if
not supported that we can at least convince
ourselves that IKE could reasonably be amended if
it becomes a serious problem later.

	   Mike