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
Mipshop ietf.org
https:
//www1.ietf.org/mailman/listinfo/mipshop
|