Hi,
there have been some discussion about how to support multiple public key
algorithms in CGAs.
I include some thoughts below to continue the discussion
RFC3972 states that only RSA are supported and there is a mandatory
Public Key filed in the CGA PDS that contains:
The public key MUST be formatted as a DER-encoded
[ITU.X690.2002] ASN.1 structure of the type SubjectPublicKeyInfo,
defined in the Internet X.509 certificate profile [RFC3280]. SEND
SHOULD use an RSA public/private key pair. When RSA is used, the
algorithm identifier MUST be rsaEncryption, which is
1.2.840.113549.1.1.1, and the RSA public key MUST be formatted by
using the RSAPublicKey type as specified in Section 2.3.1 of RFC
3279 [RFC3279]. The RSA key length SHOULD be at least 384 bits.
Other public key types are undesirable in SEND, as they may result
in incompatibilities between implementations. The length of this
field is determined by the ASN.1 encoding.
So we have two options to support alternative public key algorithms in CGAs:
- one option is to allow to include a public key of another algortihm in
the Public Key field. In order to do that, we must provide a way to tell
which algorithm is used.
According to RFC3280,
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
and
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL }
I understand that RFC3279 defines the different algorithm identifiers
for RSA.
So, this option would be to simply allow to use other algorithms and see
if the Algorithm identifiers for these algorithms have been properly
defined.
While it seems that current RFC3972 allows this already, we may want to
update it to make it more explicitly.
In addition, we want to make sure that the ECC support is properly defined.
The main issue here is that we need a mechanism to deal with the case
that different nodes support different algorithms.
Note that today, CGAs are used by SEND, MIPv6 and SHIM6 and they all
assume that the key is RSA
I understand that in the case that a different AlgorithmIdentifier is
included in the Public Key field of the CGA PDS, the receiving peer will
fail the verification. Since the key is bound to the address, the sender
will need to retry, but using a different public key, hence using a
different address. It seems that what may be needed then is an error
message in these protocols. The potential problem of such error message
is that it could open the door for downgrading attacks.
In any case, it seems clear that if we go this path, we should reccomend
that the usage of alternative aplgorithms would break the aforementioned
protocols assumptions and needs to be deployed and used in a controlled
manner, to avoid failure modes.
The other option is to define a new CGA extension that could carry an
additional public key (of eventually a different algorithm)
In this case, a node could have multipla public keys of different
algorithms, associated to the same CGA. this would have no backward
compatibility problems, since the "main" public key would be RSA and the
additional ones could be of other algortihms.
The problem here, is that in order to do this, we impose that all nodes
must have a RSA public key and one of the motivations for this was that
some lighweight nodes couldn't use RSA. However, this approach seems
particularly attractive imho for routers and servers, that need to
communicate both with normal SEND nodes and lighweight nodes. In this
case,they can choose to use RSA for backward comaptibility and also to
use ECC when talking to lighwieght nodes.
One intermediate approach could be to require to all nodes to always be
capable of verifying RSA signatures, but not requiring to have a RSA key
itself. This would allow to always be able to fall back to RSA when at
least one of the nodes has an rsa key to have a secure channel
.
I think we probably need to do both, but i am not certian yet.
comments?
Regards, marcelo
_______________________________________________
CGA-EXT mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cga-ext
