Hello Marcelo,
Thanks for your comments.
Comments inline:
In the introduction you state:
The secure neighbor discovery usage scenarios have recently been
extended to include environments with mobile or nomadic nodes. These
nodes can often be limited in power and memory capabilities, and thus
may only be able to support lightweight public key cryptography; that
is, RSA-based public keys and algorithm support may not be feasible.
But the proposed solution still requires to have an RSA key in the Public Key
field of the CGA PDS, right?
No, it won't. The Public Key field in the CGA PDS can contain a RSA
Public Key, but it can also contain another type of Public Key (for
example, ECC). The document draft-cheneau-cga-pk-agility-00 only
contains necessary materials to allow multi-key CGA. In the companion
document draft-cheneau-send-sig-agility-00, we explain how to use these
multi-key CGA with SEND.
The main idea is that we want to keep backward compatibility with
RFC3971 nodes, three cases here:
- we have a multi-CGA containing at least one RSA Public Key. The RSA
Public Key is stored in the Public Key field of the CGA PDS. So
RFC3971 will at least be able to read this Public Key. In this case,
the advantage is not in generating this multi-CGA, but in the
possibility of using a Signature Algorithm different than RSA with
SEND, where it can save some CPU.
- we have a multi-CGA containing no RSA Public Key. Any of the Public
Key can be stored in the Public Key field of the CGA PDS. RFC3971
nodes won't be able to communicate with us anyway.
- a CGA based on a single signature algorithm (which may not be RSA).
So, i am confused about how the goal of not having RAS keys is achieved with
this apporach
This is indeed confusing, as we advocate for using something else that
RSA and still we talk about storing RSA in the Public Key field of the
CGA PDS. This is only for transitional phases and interactions with
RFC 3971 nodes. In homogeneous network, CGA will only need to be formed
from a single type of Public Key, that may not be RSA.
next:
The secure neighbor discovery usage scenarios have recently been
extended to include environments with mobile or nomadic nodes. These
nodes can often be limited in power and memory capabilities, and thus
may only be able to support lightweight public key cryptography; that
is, RSA-based public keys and algorithm support may not be feasible.
i am not sure this belongs to this doc or to the send one
We will change it. It doesn't fit well in this document as we intent it
to define an extension field that is usable for CGA based protocols (and
not restricted to SEND).
then it reads:
However , it should be noted that the resulting security level of a
multiple-key CGA is only that of the weakest key. Therefore, the
requirement remains that every key in use should have a security
level matching or exceeding that of a 384-bit RSA key.
I am not sure this is true
I mean, this depends on how the receiving node is implemented, right? I mean,
if the receiver only acceptes keys with a given length, then it won't accept
signatures with other shorter keys, even if the keys are part of the CGA.
Yes, this is a problem that belong to the send-sig-agility draft and
will be described in more details the next version of the draft.
In this document, we only state that the Public Keys carried in this new
extension field should not be weaker than a equivalent 384-bit RSA key.
The issue arise with multi-key CGA, where a CGA can have Public Keys of
different security level.
I hope I answered your questions/comments.
Regards,
Tony
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
