ECC public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND)
Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
9 rue Charles Fourier
Evry
91011
France
tony.cheneau@it-sudparis.eu
Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
9 rue Charles Fourier
Evry
91011
France
maryline.laurent@it-sudparis.eu
Huawei
4, South 4th Street, Zhongguancun
Beijing
100190
P.R. China
sean.s.shen@gmail.com
Qualcomm
mvandervn@gmail.com
Internet
CGA & SEND maintenance
CGA
SEND
ECDSA
This draft describes a mechanism to deploy Elliptic Curve Cryptography (ECC) alongside with
Cryptographically Generated Addresses (CGA) and the Secure Neighbor Discovery (SEND).
This document provides basic skeleton to integrate new signature algorithms in CGA and SEND.
The usage scenarios associated with neighbor discovery have recently been
extended to include environments with mobile or nomadic nodes.
Many of these nodes have limited battery power and computing resources. Therefore, heavy public key signing
algorithms like RSA are not feasible to support on such constrained nodes. Fortunately, more lightweight
yet secure signing algorithms do exist and have been standardized, e.g. Elliptic Curve based algorithms.
It is then a worthwhile goal to extend secure neighbor discovery to support this signing algorithm.
The aim of this memo is to outline options for allowing Elliptic Curve Digital Signature Algorithm for nodes
configured to perform secure neighbor discovery operations. The present document exposes how to use and
deploy Elliptic Curve Cryptography in
and .
It should be noted that the latter document has impacts on existing specification
.
This document follows NIST's recommendation on the usage of various Elliptic Curves as per .
For the sake of simplicity, this document only describes the use of three proposed curves, namely curve P-256
(aka secp256r1), curve P-384 (aka secp384r1) and curve P-521 (aka secp521r1).
The CGA generation and verification processes remain unmodified from the processes described in .
However, we extend section 3 of , as it contains RSA specific text. We add that, when ECDSA
is used, the AlgorithmIdentifier, contained in ASN.1 structure of
type SubjectPublicKeyInfo, must be the (unrestricted) id-ecPublicKey
algorithm identifier, which is OID 1.2.840.10045.2.1,
and the subjectPublicKey MUST be formatted as an ECC Public Key, specified in Section 2.2 of .
Note that the ECC key lengths are determined by the namedCurves parameter stored in ECParameters field of the AlgorithmIdentifier.
In the document , a field named Signature Type Identifier is used by the Supported Signature Algorithm
Option and the Universal Signature Option (that replaces the RSA Signature Option). This field indicates the Signature Algorithm available
on the node to generate or verify the Digital Signature field of the Universal Signature Option.
This document describes new values for three different signature algorithms. These values are extracted from the IANA-defined numbers for the IKEv2 protocol,
i.e. IANA registry named "IKEv2 Authentication Method" and are the following:
Value 9 is ECDSA with SHA-256 on the P-256 curve
Value 10 is ECDSA with SHA-384 on the P-384 curve
Value 11 is ECDSA with SHA-512 on the P-521 curve
The document proposes the Universal Signature Option (extended from the RSA Signature Option of
). This option adds a new Signature Type Identifier field that identifies the signature algorithm used during the generation of the digital signature field.
When the value of the Signature Type Identifier field is 9, 10 or 11, this Digital Signature field is computed and verified using the
ECDSA signature algorithm (as defined on ) and hash function corresponding to the Signature Type Identifier field.
The data on which the signature is performed are described in .
This memo defines the usage of the ECC Public Key and Signature Algorithm in CGA and SEND. (from ), presents a comparison between the length of the RSA keys and their equivalent (security-wise) ECC keys.
RSA key length (bits)
ECC key length (bits)
3072
256
7680
384
15360
512
This document does not request any new IANA allocations.
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]
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 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS TRACK]
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).
Internet Protocol, Version 6 (IPv6) Specification
Cisco Systems, Inc.
170 West Tasman Drive
San Jose
CA
95134-1706
USA
+1 408 527 8213
+1 408 527 8254
deering@cisco.com
Nokia
232 Java Drive
Sunnyvale
CA
94089
USA
+1 408 990 2004
+1 408 743 5677
hinden@iprg.nokia.com
Internet
internet protocol version 6
IPv6
This document specifies version 6 of the Internet Protocol (IPv6),
also sometimes referred to as IP Next Generation or IPng.
IPv6 Neighbor Discovery (ND) Trust Models and Threats
The existing IETF standards specify that IPv6 Neighbor Discovery (ND) and
Address Autoconfiguration mechanisms may be protected with IPsec Authentication Header (AH).
However, the current specifications limit the security solutions to manual keying due to practical problems
faced with automatic key management. This document specifies three different trust models and discusses
the threats pertinent to IPv6 Neighbor Discovery. The purpose of this discussion is to define the requirements
for Securing IPv6 Neighbor Discovery. This memo provides information for the Internet community.
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]
Secure Hash Standard
National Institute of Standards and Technology
Digital Signature Standard
National Institute of Standards and Technology
Special Publication 800-57: Recommendation for Key Management - Part 1 (Revised)
National Institute of Standards and Technology (NIST)
SEC 1: Elliptic Curve Cryptography
Standards for Efficient Cryptography Group
Name of the elliptic curve
Size of the DER-encoded Public Key (bytes)
P-256
88
P-384
120
P-521
158
Name of the elliptic curve
Size of the Digital Signature field (without padding)
P-256
71
P-384
104
P-521
139
Appendix A of document emphasises the impact of the Public Key size and the number of Universal Signature Options
on size of the final message. This Appendix proposes to extend previous document and to add values for ECC.
provides size for the commonly used DER-encoded ECC Public Keys.
presents common sizes for Digital Signature field when using ECDSA.
Reusing the value computed in , we deduce that a Router Advertisement carrying a Prefix Information
Option and a Source Link-Layer Option sent from a CGA formed with a P-256 EC Public and protected by a corresponding
ECDSA signature is 328 bytes long. This can be compared with the same message using a CGA carrying a 1024 bits RSA
whose length is 456 bytes.
When specifying a new type of Signature Algorithm, a new draft may reuse the skeleton of this document by replacing ECC/ECDSA by
the appropriate terminology. In this case, the new draft should include an appendix similar to for a comparison
with already specified signature algorithms.