Support for Multiple Signature Algorithms in Cryptographically Generated Addresses (CGAs)
draft-cheneau-cga-pk-agility-01

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 December 7, 2009.

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 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.

Table of Contents

1.  Introduction
2.  Public Key extension
    2.1.  Public Key extension format
3.  CGA Generation Process
4.  Security Consideration
5.  IANA Considerations
6.  References
    6.1.  Normative References
    6.2.  Informative References
§  Authors' Addresses

1.  Introduction

Cryptographically Generated Addresses (CGA) [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) 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 [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) 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 [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) states that SEND "SHOULD" use an RSA public/private key pair, backward compatibility is 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 [RFC4581] (Bagnulo, M. and J. Arkko, “Cryptographically Generated Addresses (CGA) Extension Field Format,” October 2006.). One type of CGA Parameters data structure extension is defined in Section 2 (Public Key extension) 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 allow new functionnalities on CGA based protocols, such as the Signature Algorithm Agility in SEND [cheneau‑send‑sig‑agility] (Cheneau, T., Laurent-Maknavicius, M., Shen, S., and M. Vanderveen, “Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol,” June 2009.).

2.  Public Key extension

This section describes an extension field that conforms to the guidelines of [RFC4581] (Bagnulo, M. and J. Arkko, “Cryptographically Generated Addresses (CGA) Extension Field Format,” October 2006.).

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 [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.).

2.1.  Public Key extension format

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Extension Type        |      Extension Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   ~                       Public Key                              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Extension Type

TBA. (16-bit unsigned integer. See Section 5 (IANA Considerations).)

Extension Length

The length of the Public Key field to follow, in octets. 16-bit unsigned integer.

Public Key

This is a variable-length field containing the public key of the sender. The public key MUST be formatted as a DER-encoded [ITU.X690.2002] (International Telecommunication Union, “Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER),” July 2002.) ASN.1 structure of the type SubjectPublicKeyInfo, defined in the Internet X.509 certificate profile [RFC5280] (Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” May 2008.). 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 [RFC3279] (Bassham, L., Polk, W., and R. Housley, “Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” April 2002.). 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 [RFC5480] (Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, “Elliptic Curve Cryptography Subject Public Key Information,” March 2009.). 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).

3.  CGA Generation Process

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 [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.); 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 Figure 2 (CGA Parameters structure with multiple keys).

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 [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) is a DER-encoded ASN.1 structure of the type "SubjectPublicKeyInfo", and therefore includes a subfield called "AlgorithmIdentifier".

  List of keys             CGA Parameters data structure

                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                             |
                       +         Modifier            |
                       |                             |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |                             |
                       +      Subnet Prefix          +
                       |                             |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |Col Count|                   |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+
|               |      |        Public Key           |
~  Public Key 1 ~ ->   ~                             ~
|               |      |     (variable length)       |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      |         Extension           |
|               |      ~       Public Key 2          ~
~  Public Key 2 ~ ->   |     (variable length)       |
|               |      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+      |                             |
                       ~           ...               ~
                       |                             |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|               |      |         Extension           |
~  Public Key N ~ ->   ~       Public Key N          ~
|               |      |     (variable length)       |
+-+-+-+-+-+-+-+-+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |      Extension Fields       |
                       ~                             ~
                       | (optional, variable length) |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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.

Since [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) mandates the use of RSA keys in the Public Key field, a node compatible with [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) 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 Parameters data structure, while the other key(s) SHOULD be placed in the Extension field(s).

4.  Security Consideration

The document specifies a CGA extension field format. No additional vulnerabilities appear besides those described in section 7 of [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.)

However, it should be noted that the resulting security level of a multiple-key CGA, that this document made possible to use, is only that of the weakest key. Therefore, as the document [RFC3972] (Aura, T., “Cryptographically Generated Addresses (CGA),” March 2005.) state, when RSA is used, the RSA key length SHOULD be at least 384 bits. 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.

5.  IANA Considerations

This document defines one new CGA Extension Type [RFC4581] (Bagnulo, M. and J. Arkko, “Cryptographically Generated Addresses (CGA) Extension Field Format,” October 2006.) option, which must be assigned by IANA:

Name: Public Key Extension Type;

Value: TBA.

Description: see Section 2 (Public Key extension).

6.  References

6.1. Normative References

6.2. Informative References

Authors' Addresses