[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.


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