ECC public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND)
draft-cheneau-csi-ecc-sig-agility-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts 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 Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on April 15, 2010.

Copyright Notice

Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

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.

Table of Contents

1.  Introduction
2.  Choice of Elliptic Curve
3.  Using ECC in CGA
4.  Using ECC in the Public Key extension field
5.  Signature Type Identifier for ECC
6.  Using ECDSA with Universal Signature Option
7.  Security Considerations
8.  IANA Considerations
9.  References
    9.1.  Normative References
    9.2.  Informative References
Appendix A.  On the number of Public Keys 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.), [cheneau‑csi‑cga‑pk‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs),” October 2009.) and [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.). It should be noted that the two latter documents have impacts on existing specifications [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) and [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” 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 P-256 (aka secp256r1), curve P-384 (aka secp384r1) and curve P-521 (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) 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 [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.  Using ECC in the Public Key extension field

The optional Public Key extension field of the CGA Parameters data structure, defined in [cheneau‑csi‑cga‑pk‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs),” October 2009.), enables a node to generate CGA addresses with more than one Public Key. The encoding of the Public Key inside the Public Key extension field is the same encoding as the one presented in Section 3 (Using ECC in CGA).

5.  Signature Type Identifier for ECC

In the document [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.), 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. This value 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

6.  Using ECDSA with Universal Signature Option

The document [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.) 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-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.).

7.  Security Considerations

This memo defines the usage of the ECC Public Key and Signature Algorithm in CGA and SEND. As recommended in [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.), when a node is using a multiple-key CGA (according to [cheneau‑csi‑cga‑pk‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs),” October 2009.)), the weakest key determines the strength of a multiple-key CGA. Table 1 (Strength equivalence between Elliptic Curve and RSA Public Keys) (from [SP800‑57] (National Institute of Standards and Technology (NIST), “Special Publication 800-57: Recommendation for Key Management - Part 1 (Revised),” March 2007.)), presents a comparison between the length of the RSA keys and their equivalent (security-wise) ECC keys.

8.  IANA Considerations

This document does not request any new IANA allocations.

9.  References

9.1. Normative References

9.2. Informative References

Appendix A.  On the number of Public Keys supported per CGA

Appendix A of document [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.) emphasises the impact of the Public Key size on size of the final message. This Appendix proposes to extend previous document and to add values for ECC. Table 2 (Common sizes for DER-encoded ECC Public Key) provides size for the commonly used DER-encoded 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-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.), 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.

We can also evaluate the cost of the transformation of a legacy CGA to a multiple-key CGA. Using a 1024 RSA Public Key (as described in Appendix A of [cheneau‑csi‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” October 2009.)) and a ECC P-521 key in a CGA Option, the original message, signed with a Universal Signature option generated by RSA and a Universal Signature Option signed by ECDSA, the Router Advertisement message is 768 bytes long. Note this example illustrates the potential burden of (transitional) multiple key CGAs, and also that EC P-521 and 1024-bits RSA keys should not be used together because they do not present the same security level (see Section 7 (Security Considerations)). They are shown here to provide an indication on the sizes of messages in heterogeneous environments.

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 Public Keys supported per CGA) for a comparison with already specified signature algorithms.

Authors' Addresses