ECC public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND)
draftcheneaucsieccsigagility02
Abstract
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.
Status of this Memo
This InternetDraft is submitted in full
conformance with the provisions of BCP 78 and BCP 79.
InternetDrafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as InternetDrafts. The list of current
InternetDrafts is at http://datatracker.ietf.org/drafts/current/.
InternetDrafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use InternetDrafts as reference material or to cite
them other than as “work in progress.”
This InternetDraft will expire on December 18, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/licenseinfo) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1.
Introduction
2.
Choice of Elliptic Curve
3.
Using ECC in CGA
4.
Signature Type Identifier for ECC
5.
Using ECDSA with Universal Signature Option
6.
Security Considerations
7.
IANA Considerations
8.
References
8.1.
Normative References
8.2.
Informative References
Appendix A.
On the number of Universal Signature Options supported per CGA
Appendix B.
Note for future work
§
Authors' Addresses
1.
Introduction
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 [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.)
and [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2010.).
It should be noted that the latter document has impacts on existing specification
[RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.).
2.
Choice of Elliptic Curve
This document follows NIST's recommendation on the usage of various Elliptic Curves as per [FIPS‑186‑3] (National Institute of Standards and Technology, “Digital Signature Standard,” June 2009.).
For the sake of simplicity, this document only describes the use of three proposed curves, namely curve P256
(aka secp256r1), curve P384 (aka secp384r1) and curve P521 (aka secp521r1).
3.
Using ECC in CGA
The CGA generation and verification processes remain unmodified from the processes described in [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.).
However, we extend section 3 of [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.), 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) idecPublicKey
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 [RFC5480] (Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, “Elliptic Curve Cryptography Subject Public Key Information,” March 2009.).
Note that the ECC key lengths are determined by the namedCurves parameter stored in ECParameters field of the AlgorithmIdentifier.
4.
Signature Type Identifier for ECC
In the document [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2010.), 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 IANAdefined numbers for the IKEv2 protocol,
i.e. IANA registry named "IKEv2 Authentication Method" and are the following:
 Value 9 is ECDSA with SHA256 on the P256 curve
 Value 10 is ECDSA with SHA384 on the P384 curve
 Value 11 is ECDSA with SHA512 on the P521 curve
5.
Using ECDSA with Universal Signature Option
The document [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2010.) proposes the Universal Signature Option (extended from the RSA Signature Option of
[RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.)). 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 [SEC1] (Standards for Efficient Cryptography Group, “SEC 1: Elliptic Curve Cryptography,” September 2000.)) and hash function corresponding to the Signature Type Identifier field.
The data on which the signature is performed are described in [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2010.).
6.
Security Considerations
This memo defines the usage of the ECC Public Key and Signature Algorithm in CGA and SEND. Table 1 (Strength equivalence between Elliptic Curve and RSA Public Keys) (from [SP800‑57] (National Institute of Standards and Technology (NIST), “Special Publication 80057: Recommendation for Key Management  Part 1 (Revised),” March 2007.)), presents a comparison between the length of the RSA keys and their equivalent (securitywise) ECC keys.
RSA key length (bits)  ECC key length (bits) 
3072 
256 
7680 
384 
15360 
512 
Table 1: Strength equivalence between Elliptic Curve and RSA Public Keys

7.
IANA Considerations
This document does not request any new IANA allocations.
8.
References
8.1. Normative References
[RFC3972] 
Aura, T., “Cryptographically Generated Addresses (CGA),” RFC 3972, March 2005 (TXT). 
[RFC3971] 
Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” RFC 3971, March 2005 (TXT). 
[RFC5480] 
Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, “Elliptic Curve Cryptography Subject Public Key Information,” RFC 5480, March 2009 (TXT). 
[cheneaucsisendsigagility] 
Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” draftcheneaucsisendsigagility02 (work in progress), June 2010 (TXT). 
8.2. Informative References
[RFC2460] 
Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” RFC 2460, December 1998 (TXT, HTML, XML). 
[RFC3756] 
Nikander, P., Kempf, J., and E. Nordmark, “IPv6 Neighbor Discovery (ND) Trust Models and Threats,” RFC 3756, May 2004 (TXT). 
[RFC4861] 
Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” RFC 4861, September 2007 (TXT). 
[FIPS.1802] 
National Institute of Standards and Technology, “Secure Hash Standard,” FIPS PUB 1802, August 2002. 
[FIPS1863] 
National Institute of Standards and Technology, “Digital Signature Standard,” FIPS PUB 1863, June 2009. 
[SP80057] 
National Institute of Standards and Technology (NIST), “Special Publication 80057: Recommendation for Key Management  Part 1 (Revised),” SP SP 80057, March 2007. 
[SEC1] 
Standards for Efficient Cryptography Group, “SEC 1: Elliptic Curve Cryptography,” September 2000. 
Appendix A.
On the number of Universal Signature Options supported per CGA
Name of the elliptic curve  Size of the DERencoded Public Key (bytes) 
P256 
88 
P384 
120 
P521 
158 
Table 2: Common sizes for DERencoded ECC Public Key

Name of the elliptic curve  Size of the Digital Signature field (without padding) 
P256 
71 
P384 
104 
P521 
139 
Table 3: Common sizes of the Digital Signature field when using ECDSA (+ DER encoding)

Appendix A of document [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2010.) 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.
Table 2 (Common sizes for DERencoded ECC Public Key) provides size for the commonly used DERencoded ECC Public Keys.
Table 3 (Common sizes of the Digital Signature field when using ECDSA (+ DER encoding)) presents common sizes for Digital Signature field when using ECDSA.
Reusing the value computed in [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2010.), we deduce that a Router Advertisement carrying a Prefix Information
Option and a Source LinkLayer Option sent from a CGA formed with a P256 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.
Appendix B.
Note for future work
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 Appendix A (On the number of Universal Signature Options supported per CGA) for a comparison
with already specified signature algorithms.
Authors' Addresses