]>
Support for Multiple Signature Algorithms in Cryptographically Generated
Addresses (CGAs)
Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
9 rue Charles Fourier Evry91011Francetony.cheneau@it-sudparis.eu
Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
9 rue Charles Fourier Evry91011Francemaryline.maknavicius@it-sudparis.euHuaweisshen@huawei.com
Qualcomm
mvandervn@gmail.com
Internet
CGA & Send maintenanceCGAextensionECDSA
This document defines an extension field for the CGA Parameter data structure specified in RFC 3972. This extension field carries a Public Key that is used in Cryptographically Generated Address (CGA) generation. This extension enables protocols using CGAs, such as SEND, to use multiple Public Key signing algorithms and/or multiple Public Keys. Cryptographically Generated Addresses (CGA) have been
designed primarily for securing Neighbor Discovery .
A digital signature algorithm is used to
provide authentication and integrity protection when CGA is used.
CGAs were defined to only use RSA as the associated signature algorithm.
Only one RSA public key is associated with a CGA and this public key is carried in
the Public Key field of the CGA Parameter data structure.
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. Therefore, support for signature algorithm agility in CGA is desired. However,
since the CGA specification states that SEND "SHOULD"
use an RSA public/private key pair, backward compatibility is preserved herein.
A logical place for extending the CGA Parameter data structure to include other
types of public keys is its "extension fields". Some guidance on the format of
these extensions is provided in .
One type of CGA Parameter data structure extension is defined in
and this type of extension is able to carry public keys,
in addition to the RSA public key defined in the Public Key field of CGA Parameters data structure.
These extensions allows new functionnalities on CGA based protocols, such as the Signature Algorithm Agility in SEND .
This section describes an extension field that conforms to the guidelines of .This extension allows a CGA Parameters data structure to carry public keys in addition to the key in the Public Key field.
This approach paves the way for one CGA to possibly be associated with multiple public keys.This extension allows a node to select a Public Key value that is different from the one in the Public Key field of the CGA Parameters data
structure option. This Public Key is placed in an extension embedded in the Extension field of the CGA Parameters data structure,
described in .TBA. (16-bit unsigned integer. See .) The length of the Public Key field to follow, in octets.
16-bit unsigned integer.
This is a variable-length field containing the public key of the
sender. The public key MUST be formatted as a DER-encoded
ASN.1 structure of the type SubjectPublicKeyInfo,
defined in the Internet X.509 certificate profile .
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 .
The RSA key length SHOULD be at least 384 bits.
When ECC is used, the algorithm identifier MUST be of type id-ecPublicKey (OID 1.2.840.10045.2.1), as defined in
. ECC public key encoding is specified in this reference.
Note that the ECC key lengths are determined by the ECParameters field named namedCurves (curves implying key length).
When a node supports two or more types of signing algorithms, and is able to generate two or more corresponding public keys,
then it can derive a single CGA using all these keys. The derivation is done exactly as in ; one key is
placed in the CGA Parameters data structure "Public Key" field while the rest of the keys are placed in separate extension fields . This is illustrated in .
It should be noted that the type of the public key (RSA, ECC, etc.) is already encoded into the
"Public Key" field itself, and thus there is no need to identify the public key type separately. This is due to the fact that the "Public Key" field, according to
is a DER-encoded ASN.1 structure of the type "SubjectPublicKeyInfo", and therefore
includes a subfield called "AlgorithmIdentifier".
The resulting CGA Parameters data structure is inserted into a CGA option as per .
When sending a NDP packet, the node includes this CGA option and also one signature option of choice,
computed with a private key whose corresponding Public Key is present in the CGA Parameters data structure.
This signature option can be the RSA signature option as per ,
or another signature option, e.g. the ECC signature option as per ,
or any other signature defined. The signature option contains the hash of the key used to sign
the message.
Note that an implementation should choose the number of simultaneous Public Key Extensions fields used so as the
total length of the extension fields does not exceed a threshold that requires fragmentation support at the
SEND or other upper-layer protocol layer.
Support for RSA Public Keys and signature algorithm is only RECOMMENDED for backward compatibility.
This specification does not mandate support for any particular public key signature algorithm.
Therefore, nodes can be configured to choose/support only a single additional signature algorithm
besides RSA. However, a node is also free to not support RSA and still claim
compatibility with this specification.
Since mandates the use of RSA keys in the Public Key field, a node compatible with
only will extract the RSA public key from the Public Key field and ignore the extension fields.
Therefore, in order to achieve backward compatibility, if a node uses a CGA associated with multiple public keys (through
the use of the Public Key extension), the following procedures are in place: if one of the public keys is of RSA type,
then that key SHOULD be placed in the Public Key field of the CGA Parameter data structure, while the other
key(s) SHOULD be placed in the Extension field(s).
The document specifies a CGA extension field format. No additional vulnerabilities
appear besides those described in section 7 of .
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. Whenever protocols negotiate signature algorithms, downgrade attacks are considered.
This document only provides the ability for CGA options to carry multiple public keys;
negotiations of signature algorithms or public keys are out of the scope of this document.
This document defines one new CGA Extension Type option, which must
be assigned by IANA: Name: Public Key Extension Type; Value: TBA. Description: see .
&RFC5280;
&RFC3972;
&RFC3971;
&RFC4982;
&RFC4861;
&RFC4581;
&RFC3279;
&RFC4866;
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER),
Canonical Encoding Rules (CER) and Distinguished
Encoding Rules (DER)
International Telecommunication Union
ECC Support for SEND/CGAThis draft proposes an upgrade to the SEND/CGA protocols to incorporate support for
elliptic curve cryptography.Elliptic Curve Cryptography Subject Public Key Information
This document specifies the syntax and semantics for the Subject
Public Key Information field in certificates that support Elliptic
Curve Cryptography. This document updates Sections 2.3.5 and 5, and
the ASN.1 module of Algorithms and Identifiers for the Internet X.509......
Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol
This draft describes a mechanism to enable the Secure Neighbor Discovery (SEND) protocol to select
between different signature algorithms to use with Cryptographically Generated Addresses (CGA).
It also provides optional support for interoperability between nodes that do not share any
common signature algorithms.