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

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

Hi, 

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
keypairs 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 allows for decoupling the key derivation 
operations from CGA SEND message signing, without significant additional
computation or assymetric key generations.

The key-derivation keypair can be used for many different derivations,
and only be thrown out by the host or router when it has been used
too much, been compromised or reached a hard lifetime.

The cost is that the key-derivation key information (algorithm, public
key, etc) would have to be included in messages received before the host
could generate and transmit the handover keys.

This means that the host would have had to receive at least one RA before
sending the encrypted symmetric key.

Note that it is also important to ensure that the encypted key
derivations themselves are not used in replay attacks, especially as
the keys used in encrypting the symmetric key information are no longer
the CGA private keys.  This means the contents of the encrypted section
of the handover key option will need freshness and a mechanism to tie the
encrypted contents to the intended source and destination of the message.

Here is my view of the protocol:

Legend

h      Host

r      Router

CGA_n  Cryptographically generated address for node (n)

N_n_i  Nonce number (i) from node (n) 

T_n_i  Timestamp number (i) from node (n)

S_n_m    Symmetric handover key for data sent from node (n) to node (m)

PR_K_n  Private key derivation key for node (n)

PU_K_n  Public  key derivation key for node (n)

ID_S_n_m an identifier for the Secret Key between node (n) and node (m)

ID_C_n  CGA key identifier for node (n)

ID_K_n  Key identifier for the key derivation key of (n)

CGAOPT_n CGA option for node (n)

KDKOPT_n Key derivation keying option, for node (n) containing the
         public key used for key derivation  PU_K_n, and ID_K_n

HKOPT    Handover Key option.  The contents are specified in the square
         braces.

<identifier> ( ...  )  encryption using identifier, which is a key. 

SEND_n   SEND signature over previous message using CGA public key of (n)

Exchanges:

Step 0-optional:

RS: [ CGA_h ,All Routers, N_h_1, T_h_1, CGAOPT_h, KDKOPT_h-optional ],SEND_h

Step 1:

RA  [ CGA_r, CGA_h (or all nodes), T_r_1, CGAOPT_r, KDKOPT_r ) ],SEND_r

Note: that if this is a solicited RA, it also contains N_h_1.

Step 2:

NS  [ CGA_h, CGA_r, N_h_2, T_h_2, CGAOPT_h-optional?, KDKOPT_h, 
            HKOPT[ ID_S_h_r, ID_K_r, PU_K_r ( ID_C_h, ID_C_r, N_h_2,
                                  T_h_2, ID_S_h_r, S_h_r ) ] ],SEND_h

Note:  Can be NS or RS

       The section starting PU_K_r... is the contents of the handover-key
       option encrypted using r's public key (and readable only by r).

       Host h encrypts the ID_C_h and ID_C_r to show that the key derived
       is purposed for this router and host.  The Nonce and Timestamp
       information provide freshness.
       
       The encryption with PU_K_r ensures only r can read it, and the SEND
       signature using the key indicated in the ID_C_h prevents spoofing by
       third parties.

       ID_S_h_r is the identifier used in symmetric key communications
later.
       Plaintext of this is present in the handover keying option to prove
       that the CGA holder intended this key to key identifier binding.

       ID_K_r is present in the handover keying option to show which
handover
       keypair to use in decrypting the encrypted contents.

       The Router now has a handover key between h and r.

Step 3:

NA  [ CGA_r, CGA_h, N_h_2, T_r_2, CGAOPT_r-optional, 
            HKOPT[ ID_S_r_h, ID_K_h, PU_K_h ( ID_C_r, ID_C_h, N_h_2,
                                  T_r_2, ID_S_r_h, S_r_h ) ] ],SEND_r

Note:  Can be NA or RA

       The section starting PU_K_h... is the contents of the handover-key
       option encrypted using h's public key (and readable only by h).

       Router r encrypts the ID_C_r and ID_C_h to show that the key derived
       is purposed for this router and host.  The Nonce and Timestamp
       information provide freshness.
       
       The encryption with PU_K_h ensures only h can read it, and the SEND
       signature using the key indicated in the ID_C_r prevents spoofing by
       third parties.

       ID_S_r_h is the identifier used in symmetric key communications
later.
       Plaintext of this is present in the handover keying option to prove
       that the CGA holder intended this key to key identifier binding.

       ID_K_h is present in the handover keying option to show which
handover
       keypair to use in decrypting the encrypted contents.

       The Router now has a handover key between r and h.

The step 3 message is probably needed for acknowledgement of reception, even
if the same key is used from r-->h as h-->r.

Please let me know if this is helpful.

Greg

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