[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Son-of-IKE Performance
The draft leaves many things undefined; they are important, but given
available time and effort, some things were more critical for
inclusion in the draft. There's no reason why the PRF process or
something similar cannot be used for two-SA key derivation.
In message <200112062113.fB6LDj301886@fatty.lounge.org>, Dan Harkins writes:
> Yes, you can but I guess what I'm saying is that you're not. You can
>stretch it to produce bi-directional keys but such stretching is not
>specified anywhere in JFK.
>
> In <200112042306.BAA16872@burp.tkv.asdf.org> Markku Savela mentioned
>he preferred "a key negotiation [protocol] that only negotiates one
>directional SA as requested by the kernel side of the IPSEC." That
>is what JFK establishes today, a single session key for IPsec.
>
> If the intent, though, is that Kir should be stretched somehow to
>produce bi-directional keys I withdraw my comment, but you really should
>specify how. Leaving such things to the imagination of the implementor
>will probably result in disinteroperability.
>
> Dan.
>
>On Thu, 06 Dec 2001 22:17:50 EST you wrote
>> In message <200112061808.fB6I7t301682@fatty.lounge.org>, Dan Harkins writes:
>> > Actually to compare apples-to-apples you should note that
>> >JFK only produces a single key, Kir, for a single IPsec SA
>> >(I'm assuming it's the initiator's outbound although it's
>> >not specified). To end up with a pair of IPsec SAs, one in
>> >each direction, you'd need:
>> >
>> > Protocol Initiator Responder Latency
>> > ------------------------------------------------
>> > JFK(normal) 2 signature 2 signature 4 RTT
>> > 4 verifies 2 verify
>> > 2 DH agree 2 DH agree
>> >
>> > JFK(PFS)[2] 2 signature 4 signatures 4 RTT
>> > 4 verifies 2 verify
>> > 2 DH agree 2 DH agree
>> >
>>
>> I'm afraid I don't understand what you're saying. JFK ends up with an
>> authenticated DH exponential; we can clearly derive bidirectional keys
>> from that.
>>
>> --Steve Bellovin, http://www.research.att.com/~smb
>> Full text of "Firewalls" book now at http://www.wilyhacker.com
>>
>>
References: