[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
>>
>
>