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

[Greg Daley <[e-mail]>]

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