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.euHuawei4, South 4th Street, ZhongguancunBeijing100190P.R. Chinasean.s.shen@gmail.com
Qualcomm
mvandervn@gmail.com
Internet
CGA & Send maintenanceCGAextensionECDSA This document defines an extension field for the CGA Parameters 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 to provide a binding of an internet address (IPv6) to a public key. A node who claims to own
a particular IPv6 address, can prove so in the messages (e.g. ICMP) it sends by using
a digital signature for authentication and integrity protection. Since the IPv6 address was generated from
the public key, verification of the respective signature is tantamount to verification of ownership of the claimed IPv6 address. 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 Parameters data structure.
Due to the expected variations in cryptographic ability of IPv6 nodes,
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 must be preserved herein.
A logical place for extending the CGA Parameters 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 Parameters 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 support new functionnalities for 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.
Section 3 of document specifies how to use ECC Public Key in CGA and defines the format of the Public Key field for the Public Key extension.
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,
as illustrated in .
Thus generation and verification of CGA as defined in Section 4 and Section 5 of remain unchanged.
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".
Note that an implementation should choose the number of simultaneous Public Key Extension 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.
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.
recommends the use of RSA keys in the Public Key field when using SEND . A node compatible with
will only 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 Parameters 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
are introduced besides those described in section 7 of . However, it should be noted that the resulting security level of a multiple-key CGA, that this document enables to use, is only that of the weakest key.
Therefore, when RSA is used, the RSA key length SHOULD be the minimum length recommended in Section 3 of or the current minimum recommended by leading standards bodies such as NIST.
In this document, we state 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 .
The authors would like to thank Jean-Michel Combes for his helpful comments.Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS TRACK]Cryptographically Generated Addresses (CGA)This document describes a method for binding a public signature key to an IPv6 address in the Secure Neighbor Discovery (SEND) protocol. Cryptographically Generated Addresses (CGA) are IPv6 addresses for which the interface identifier is generated by computing a cryptographic one-way hash function from a public key and auxiliary parameters. The binding between the public key and the address can be verified by re-computing the hash value and by comparing the hash with the interface identifier. Messages sent from an IPv6 address can be protected by attaching the public key and auxiliary parameters and by signing the message with the corresponding private key. The protection works without a certification authority or any security infrastructure. [STANDARDS TRACK]SEcure Neighbor Discovery (SEND)IPv6 nodes use the Neighbor Discovery Protocol (NDP) to discover other nodes on the link, to determine their link-layer addresses to find routers, and to maintain reachability information about the paths to active neighbors. If not secured, NDP is vulnerable to various attacks. This document specifies security mechanisms for NDP. Unlike those in the original NDP specifications, these mechanisms do not use IPsec. [STANDARDS TRACK]Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs)This document analyzes the implications of recent attacks on commonly used hash functions on Cryptographically Generated Addresses (CGAs) and updates the CGA specification to support multiple hash algorithms. [STANDARDS TRACK]Neighbor Discovery for IP version 6 (IPv6)This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS TRACK]Cryptographically Generated Addresses (CGA) Extension Field FormatThis document defines a Type-Length-Value format for Cryptographically Generated Address (CGA) Extensions. This document updates RFC 3972. [STANDARDS TRACK]Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS TRACK]Enhanced Route Optimization for Mobile IPv6This document specifies an enhanced version of Mobile IPv6 route optimization, providing lower handoff delays, increased security, and reduced signaling overhead. [STANDARDS TRACK]Elliptic Curve Cryptography Subject Public Key InformationThis 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 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS TRACK]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Â public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND)This draft describes a mechanism to deploy Elliptic Curve Cryptography (ECC) alongside with Cryptographically Generated Addresses (CGA) and the Secure Neighbor Discovery.
This document provides basic skeleton for other Signature Algorithms to be integrated in CGA and SEND.
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.