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

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

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.

jak>> OK.

> 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).

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.

> 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.

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.

> 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.

jak>> OK.

> 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.

jak> OK.

>        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?

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

            jak 




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