Subject: [Mipshop] Your Opinion on RSA Key Length for CGA/CBA Protocol

From: Christian Vogt <[email-masked]>
Date: Sat, 04 Nov 2006 14:14:11 +0100

Hi everybody,

the CGA/CBA protocol spec [draft-ietf-mipshop-cga-cba-01] currently
stipulates a requirement for a minimum RSA key length of 384 bits.  This
might be too short, however, as discussed recently with Zhen Cao [1].
The reasons why longer RSA keys may be needed are also explained in [1].

[1]  http://www1.ietf.org/mail-archive/web/mipshop/current/msg02929.html

This email is to solicit expert opinions on (i) which minimum key length
would be appropriate today for the CGA/CBA protocol, and (ii) how to
enforce this minimum.

My personal opinion is that the current 384-bit minimum key length is
too small (see [1] for an explanation), and that it should be increased
to 1024 bit for the CGA/CBA protocol.  There are 3 options for enforcing
a higher minimum key length:

(1)  Specify a higher minimum key length as part of the CGA/CBA
protocol.

(2)  Let the correspondent node set the minimum key length, and specify
an error code in the CGA/CBA protocol which the correspondent node can
use in Binding Acknowledgment messages to inform a mobile node that its
public key is too short.  The mobile node can then either generate a
longer RSA key pair and try again, or it can fall back to a standard
IPv6 home address.  The CGA/CBA protocol draft already covers the case
where the home address is not a CGA.

(3)  Extend the CGA Sec registry entry specified in
[draft-bagnulo-multiple-hash-cga-01] by a minimum key length.  This
would enable the mobile node to set the key length and force an attacker
to use the same key length.  (If you allow the mobile node to set the
key length without encoding the key length into the CGA, then there is
nothing that prevents an attacker from spoofing the CGA with a shorter
key pair.  In other words, downgrading attacks would be possible.)

Option (1) is easy to realize, but not crypto agile.  Option (2)
provides crypto agility, but the mobile node's security hinges on the
correspondent node to enforce an appropriate minimum key length.  The
beauty of option (3) is that it is crypto agile AND enables the mobile
node to select a minimum key length (by choosing the right Sec value).
My personal preference is hence to go with option (3).

We will put these 3 options again on the table during the Mipshop
session, and it would be great if folks could speak out---either
directly during the session or on this mailing list---with respect to

(i)  which of the above 3 options they think is most appropriate, and

(ii)  what minimum key length would be reasonable to suggest today for
the CGA/CBA protocol.

Note that the keys must be good for at least 24 hours, since this is the
maximum lifetime of a correspondent registration permitted in the
CGA/CBA protocol.  Of course, it would be good if the keys were secure
for much longer than 24 hours, so that mobile nodes can use the same
keys again in subsequent correspondent registrations.

Thanks!
- Christian

PS:  I won't be in San Diego myself, so Wassim will give the Mipshop
presentation.  Nonetheless, I wish all of you a successful and fun
meeting over there!

-- 
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/

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

---

From: Jari Arkko <[email-masked]>
Date: Sat, 04 Nov 2006 21:24:31 +0200

In SEND, receivers were configured with a minimum
key length they accept. From what I recall (though
I could not find the text in the RFC), the idea is that
falling below the key length is treated just as if
you had not used SEND.

I think something similar should be done here.
That is, we can state that the receivers should have
a policy about the key length they accept, and that
falling below that causes the receiver to act as if
CGA was not used.

Also, I like Christian's suggestion to have a policy
also associated with the various Sec bit values.
But that is orthogonal to the MIPSHOP document.
Please contact Marcelo and see if he likes the
idea.

(Finally, I was not convinced that the 384 bits
is actually too short. But maybe that's besides
the point.)

--Jari

---

From: Christian Vogt <[email-masked]>
Date: Sun, 05 Nov 2006 01:45:24 +0100

> Please contact Marcelo and see if he likes the

Right, it allows the mobile node itself to protect its CGA from 
downgrading attacks by choosing a Sec value with a sufficient minimum 
key length.  No need for the correspondent node to decide which minimum 
key length would be appropriate.  (The correspondent node must still 
/enforce/ the respective minimum key length given the Sec value chosen 
by the mobile node.)

I contacted Marcelo and pointed him to this discussion.

- Christian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 8 Nov 2006 03:33:29 +0100

El 05/11/2006, a las 1:45, Christian Vogt escribió:

> key length.

yes i think this makes sense.

I think we should add a comment stating that the RFC defining a given 
Sec value should define the correspondent minimum RSA key length also

Regards, marcelo

>   No need for the correspondent node to decide which minimum key 
> length would be appropriate.  (The correspondent node must still