Re: [Mipshop] Key derivation keys for draft-ietf-mipshop-handover-key

["James Kempf" <[e-mail]>]

Greg,

I got the copy you sent to the mailing list. It seems my problems with 
posting and reception have cleared up. I'll take a more detailed look at 
your proposal when I get to revising the draft and post any questions, but, 
after a quick read, I think it looks OK. I hope to quickly rev the document 
after the drafts gate opens and have Vijay issue a last call, so that we can 
get FMIP to the IESG before the November meeting.

             jak

----- Original Message ----- 
From: "Greg Daley" <[e-mail]>
To: "Greg Daley" <[e-mail]>
Cc: <[e-mail]>; "James Kempf" <[e-mail]>
Sent: Wednesday, July 25, 2007 7:47 AM
Subject: Re: [Mipshop] Key derivation keys for 
draft-ietf-mipshop-handover-key


Hi James, et al.

please note, I have sent a more complete version of this e-mail to the list.

Sorry for the klutziness.

Greg

----- Original Message -----
From: Greg Daley <[e-mail]>
Date: Wednesday, July 25, 2007 8:42 am
Subject: [Mipshop] Key derivation keys for draft-ietf-mipshop-handover-key
To: [e-mail]
Cc: [e-mail]

>
> I made a comment at the mike yesterday concerned about the requirement
> to use an additional (non-CGA) public/private keypair in the
> handover-keys draft.
>
> The comment I made was based on misunderstanding the issues
> presented in
> Rajeev's presentation.
>
> Now I have had the chance to go through the meat of James' earlier
> postabout these keys, and realize that the new keys would be
> exclusivelygenerated for key derivation, and would not require any
> bulk data
> encryption using assymmetric cryptography.
>
>
> I think this is a very good idea, in that it allows the key-
> derivation keys
> to be limited in lifetime, without affecting the stability or security
> of the CGA.
>
> The lifetime of any public key which is used in cryptography should be
> limited both by the number of key deriving encryption operations they
> perform, and an absolute lifetime, in order to prevent cryptanalysis.
>
>
> Having the router and host autonomously generate a shorter lived
> key-derivation keypair can be made to provide significant security
> without causing undue additional computation.
> This is because the key can be used and reused for key derivations
> with many different hosts and only discarded when it is worn out or
> old.
>
> The cost is that the key-derivation key information (algorithm, public
> key, etc) would have to be included in messages between the host
> and router
> before the keys could be derived, and additional information would
> need to
> be provided in the encrypted block of the Handover Key option.
>
>
> Note that it is important to ensure that the encypted key derivations
> themselves are not used in replay attacks, especially as the keys for
> the encryption of the symmetric key information are no longer the CGA
> private keys.
>
> This requires that information tying the sender's CGA public key to
> theencrypted block.
>
> Here is my view of the protocol:
>
>
> Legend
>
> N_n_i  Nonce number (i) from node (n)
>
> T_n_i  Timestamp number (i) from node (n)
>
> CGAOPT_n CGA option for node (n)
>
> KDKOPT_n Key Derivation Keying Option for node (n)
>             Contains:
>             information about key algorithm
>             public key
>             public key identifier (perhaps implicit, SHA-1 of
> public key)
>
> SIGNED_n  signature using the CGA private key of (n)
>
> h      Host
>
> r      Router
>
>
> RS:    Signed_h  ( h,All Routers,   N_r_1, T_r_1, KDKOPT_h,
> CGAOPT_h )
>
> RA:
>
>
>
> There is an assumption that the information in the KDK option is
> valid for a period where the subsequent messages key derivation
> exchanges are to be sent.
>
> Either this validity time can be included explicitly in the KDK option
> itself, or there can be a reasonable assumption provided, e.g.:
>
> A node only sends a KDK option containing information valid for at
> least30 minutes ( or however long the original SEND message
> containing the
> option is valid).
>
>
>
> _______________________________________________
> Mipshop mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mipshop
>



_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop