Subject: [Mipshop] AD review of draft-ietf-mipshop-handover-key

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Oct 2007 18:27:54 +0200

I reviewed this specification. It is mostly in very good shape,
but there were a few issues. I'd like to discuss them before
moving forward -- and a new draft revision may be needed.

> The MN can reuse the key pair on different 
> access routers but MUST NOT use the key pair for 
> any other encryption or for signature operation.

I hope this does not imply that the same key pair could not be
used for SEND. Essentially, this would mean that SEND and
FMIP are incompatible. OTOH, I see no reason why this should
apply to anything involving the CGA address itself. Suggested
rewrite:

The MN can reuse the key pair on different 
access routers but MUST NOT use the key pair for 
any encryption or signature beyond operations
involving the given CGA address (such as Neighbor
Advertisements for the given address, secured 
with SEND).

> The AR MUST use its CGA as the source address for the
> PrRtAdv and include a SEND CGA Option and a SEND Signature
> Option with the SEND signature of the message. 

This is unusual and unexpected compared to what one would
do in SEND. CGA does not help you protect against someone
pretending to be a router. I would suggest a mechanisms similar
to SEND be applied here, i.e., router side is protected with
trusted root configuration in the mobile nodes and certificates
assigned to each router. This is similar to how TLS works for web,
and is fairly easily deployable.

> The handover key MUST be stored by the AR
> for  future  use,  indexed  by  the  CGA,  and  the  authentication
> algorithm type (i.e., the resolution of the AT field processing)
> and HK-LIFETIME MUST be recorded with the key.
...
> To avoid
>      state depletion attacks, the handover key MUST NOT be generated
>      prior to SEND processing that verifies the originator of RtSolPr.
>      State depletion attacks are possible if this ordering is not
>      respected.

The last statement is not true. Any number of hosts may appear on the link,
existing hosts may generate O(2^64) addresses and demand keys for them,
etc.

The document does not need a big change to fix this, though. Basically
s/MUST/SHOULD/ in the first piece of text, and then some explanation
of how to deal with state depletion in the second piece.

> Upon receipt of one or more PrRtAdvs secured with SEND and having
> the Handover Key Reply Option, the MN MUST first validate the
> PrRtAdvs  as  described  in  RFC  3971.  From  the  messages  that
> validate, the MN SHOULD choose one with an AT flag in the Handover
> Key Reply Option indicating an authentication algorithm that the
> MN supports. From that message, the MN MUST determine which
> handover key encryption public key to use in the event the MN has
> more than one. The MN finds the right public key to use by
> matching the SEND nonce from the RtSolPr. The MN MUST use the
> matching  private  key  to  decrypt  ...

I think it would be helpful to have a statement where the MN MUST drop
the PrRtAdv if it does not see a nonce from itself.

>        Encrypted Handover Key:
>   
>                      The shared handover key, encrypted with the MN's
>                      handover key encryption public key.
>  

In which format? Can you specify this more explicitly?

Jari

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Oct 2007 09:38:39 -0700

jak>> OK.

jak>> The handover key encryption key should not be used for any 
authentication operation including SEND. A separate key was introduced for 
encrypting because RSA has a vulnerability if the same key is used for both 
encryption and authentication. I can modify it to:

jak>> The MN can reuse the key pair on different
access routers for encrypting a handover key
but MUST NOT use the key pair for
any other encryption or signature operations, especially
for authentication with SEND.

jak>> I can add some text to this effect. The intent was that the
router's key is certified, but I agree that this should be explicitly
called out.

...

jak>> OK.

jak> OK.

jak>> I'll look into this. Do you have any preferences about the format?

            jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Oct 2007 18:48:49 +0200

James,

> authentication operation including SEND. A separate key was introduced
> for encrypting because RSA has a vulnerability if the same key is used
> for both encryption and authentication. I can modify it to:
>

This is very problematic. If I understand this correctly, it means that
the MN can pick a key pair and address and defend them in the
RtPrSol, but is unable to do so for regular ND operations on the
link. And you need to use ND operations on the link. Also, at
the same time any use of the given care of address with CGA
based techniques (SHIM6, RFC 4866) becomes impossible.

Did I get this correctly? If yes, I think we need to do something
about it.

Is the RSA vulnerability an issue for the key in question? What
if there was key pair P that was used to derive the care of address,
and to certify key pair Q. Both P and Q were included in RtPrSol,
and only Q would be used for encryption in RtPrAdv? But I'm
just thinking aloud here...

> jak>> I'll look into this. Do you have any preferences about the format?

No. I don't remember if RFC 4866 had something similar, you may
want to copy from there if it did.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Oct 2007 13:20:08 -0700

jak>> No, that is not the case. The intent is that the MN uses SEND NS/NA to 
defend the address, generates the address with the SEND public key, then 
uses the CGA as a source address in the RtPrSol . The signature on the 
RtPrSol ensure that the message came from the claimed address. The handover 
key encryption public key is included for the router to use only in 
encrypting the return key. In effect, the use of the CGA and SEND signature 
on the RtPrSol is no different than it would be on, for example, RS.

jak>> It is not the intent of handover keys to provide an alternate 
mechanism for claiming and defending an address. The CGA must be one that is 
generated with the SEND key and defended in the usual SEND fashion.

jak>> If this is not clear from the current text, then perhaps you can 
suggest a place where some additional text could be added to clarify?

jak>> The RSA vulnerability is only an issue if the same key pair is used 
for encryption and authentication, regardless of the key pair. The reason 
why we changed the design to use a different key from the SEND key was 
because of this vulnerability.

jak>> I suppose we could use both keys to generate the address, but that 
would change SEND, and I don't see any need for it. As long as the router 
has cryptographic assurance that the RtPrSol originated from the claimed 
source address and that the originator is the owner of that source address 
(which is provided by the CGA and SEND signature) then it can couple the 
shared handover key to the address. The encryption key is just used for 
security on the transport of the shared handover key, it plays no other 
role. Or am I missing something?

jak>> OK, I'll check that.

                 jak

---

From: Jari Arkko <[email-masked]>
Date: Mon, 29 Oct 2007 22:48:51 +0200

James,

> suggest a place where some additional text could be added to clarify?

Ok, I was merely confused about this. Let me go read the text again,
moment...

OLD:
     The mechanism utilizes SEND [SEND] and a public/private
     key pair, generated on the MN using the same public key algorithm
     as SEND, to encrypt/decrypt a shared handover key sent from the AR
     to the MN.
NEW:
     The mechanism utilizes SEND [SEND] and an additional public/private
     key pair, generated on the MN using the same public key algorithm
     as SEND, to encrypt/decrypt a shared handover key sent from the AR
     to the MN.

OLD:
    The message exchange between the MN and AR
     to provision the handover key is required to be protected by SEND;
     that is, the source address for the key provisioning messages must
     be a CGA and the messages must be signed with the CGA private key.
     This allows the AR to establish the MN's authorization to operate
     on the CGA. The AR uses the CGA to name the handover key.
NEW:
    The message exchange between the MN and AR
     to provision the handover key is required to be protected by SEND;
     that is, the source address for the key provisioning messages must
     be a CGA and the messages must be signed with the CGA private key.
     This allows the AR to establish the MN's authorization to operate
     on the CGA. The AR uses the CGA to name the handover key.
     The SEND key pair is, however, independent from the handover
     encryption/decryption key pair and the actual handover key.

OLD:
  The MN
  generates a public/private key pair for encrypting/decrypting the
  shared handover key, using the same public key algorithm as SEND.
NEW:
  First, the MN generates the necessary key pair and associated CGA
  addresses so that the MN can employ SEND. Then the MN
  generates a public/private key pair for encrypting/decrypting the
  shared handover key, using the same public key algorithm as was
  used for SEND.

Finally, I noticed that the acronym CGA needs expansion in the
the abstract.

Is this enough for you to work for a new draft revision? How soon
can you get it submitted?

Jari

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Oct 2007 13:55:14 -0700

Yes, that's fine.

I'll have the revisions completed by Fri. Do you want me to resubmit through 
the RFC Editor in the usual way, and bump the version number up?

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; "Mipshop" 
<[email-masked]>
Sent: Monday, October 29, 2007 1:48 PM
Subject: Re: AD review of draft-ietf-mipshop-handover-key

James,

OLD:

OLD:

OLD:
  The MN

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 29 Oct 2007 14:34:20 -0700

James Kempf wrote:
> Yes, that's fine.
> 
> I'll have the revisions completed by Fri. Do you want me to resubmit 
> through the RFC Editor in the usual way, 

You mean the IETF secretariat. :)

> and bump the version number up?

Yes.

Vijay

> 
>            jak
> 
> ----- Original Message ----- From: "Jari Arkko" <[email-masked]>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 29 Oct 2007 14:37:11 -0700

Right, sorry, I did mean the Drafts Editor.

            jak

----- Original Message ----- 
From: "Vijay Devarapalli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; "Mipshop" <[email-masked]>; 
<[email-masked]>
Sent: Monday, October 29, 2007 2:34 PM
Subject: Re: [Mipshop] Re: AD review of draft-ietf-mipshop-handover-key

Yes.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 30 Oct 2007 00:04:40 +0200

Internet drafts editor. And yes, bump the version number.
You should use the submission tool at

   https://datatracker.ietf.org/idst/upload.cgi

Friday sounds good.

Jari

James Kempf kirjoitti:
> through the RFC Editor in the usual way, and bump the version number up?
>
>            jak
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 31 Oct 2007 22:43:07 +0200

Thanks for the update.

The new draft solves my AD review issues, almost.
The one issue that still remains is that the explanation
on the use of SEND for securing AR's messages claims
that the AR must use a CGA. I believe this is incorrect,
and it is sufficient for the certified public key to be
used as a source address, as it is in SEND. I entered
the following edit to the tracker:

OLD:
     The AR MUST use the CGA constructed from its
     certified key as the source address for the PrRtAdv and include a
     SEND  CGA  Option  and  a  SEND  Signature  Option  with  the  SEND
     signature of the message.
NEW:
     The AR MUST have a certificate suitable for a SEND-capable router,
     support SEND certificate discovery, and include a SEND  CGA
     Option  and  a  SEND  Signature  Option  in the PrRtAdv messages
     it sends. Similarly, the mobile nodes MUST be configured with
     one or more SEND trust anchors so that they can verify these
     messages.

In any case, I'm sending the draft forward. If you can, update
the draft with this change so that other readers get it as well.
If not, the change will be retained as an RFC Editor note in
the tracker.

Jari

---

From: "James Kempf" <[email-masked]>
Date: Wed, 31 Oct 2007 14:06:21 -0700

Sure.

            jak

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>
Cc: "Mipshop" <[email-masked]>
Sent: Wednesday, October 31, 2007 1:43 PM
Subject: Re: AD review of draft-ietf-mipshop-handover-key

Thanks for the update.

OLD:

Jari