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

From: Greg Daley <[email-masked]>
Date: Wed, 25 Jul 2007 08:41:57 -0500

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 post
about these keys, and realize that the new keys would be exclusively
generated 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 the
encrypted 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 least
30 minutes ( or however long the original SEND message containing the
option is valid).  

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

---

From: Greg Daley <[email-masked]>
Date: Wed, 25 Jul 2007 09:47:51 -0500

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 <[email-masked]>
Date: Wednesday, July 25, 2007 8:42 am
Subject: [Mipshop] Key derivation keys for draft-ietf-mipshop-handover-key
To: [email-masked]
Cc: [email-masked]

> 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
> This requires that information tying the sender's CGA public key to 
> theencrypted block.
> 
> 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).  
> 
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 25 Jul 2007 09:42:07 -0700

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" <[email-masked]>
To: "Greg Daley" <[email-masked]>
Cc: <[email-masked]>; "James Kempf" <[email-masked]>
Sent: Wednesday, July 25, 2007 7:47 AM
Subject: Re: [Mipshop] Key derivation keys for 
draft-ietf-mipshop-handover-key

Hi James, et al.

Greg