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

Re: Son-of-IKE Performance



  RFC2409 uses something not defined anywhere in JFK to expand
keys (SKEYID_d) and two other things whose exact location can only
be guessed at (the SPI and protocol fields of an "sa" structure
which itself is not defined). If your students generated interoperable
implementations they deserve either an A+ for their omniscience or 
an F for cheating.

  Dan.

On Thu, 06 Dec 2001 22:21:38 EST you wrote
> 
> 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: