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

[Michael Thomas <mat@cisco.com>]

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

Dan Harkins writes:
 >   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
 > > 
 >