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

[Christian Vogt <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop