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

Re: Son-of-IKE Performance




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 

Now who's comparing apples to bananas ? :-)

At the end of JFK, you get the same key material as you get with any
of the other protocols (the result of a DH computation, mixed with
some other randomness --- the nonces). You can stretch that to your
heart's content, as has been done in all other protocols since the
dawn of history -- IKE, Photuris, TLS. The initial key derivation
process is intended to make the JFK session key and the application
key (e.g., IPsec) independent (a la SKEYID). You can then apply the
same PRF process to extend this to fit 3DES, AES, etc.

In fact, that's what my students' reference implementations do (even
though I never mentioned PRF to them, they found it on RFC 2409 by
themselves).
-Angelos


Follow-Ups: References: