TOC 
CGA & SEND maintenanceT. Cheneau
Internet-DraftM. Laurent
Updates: RFC3971TMSP
(if approved)S. Shen
Expires: May 26, 2010Huawei
 M. Vanderveen
 Qualcomm
 November 22, 2009


Signature Algorithm Agility in the Secure Neighbor Discovery (SEND) Protocol
draft-cheneau-csi-send-sig-agility-01

Abstract

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

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 May 26, 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 (http://trustee.ietf.org/license-info) 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 BSD License.



Table of Contents

1.  Introduction
2.  Overview
    2.1.  Compatibility with existing specifications
        2.1.1.  Classification of SEND nodes
        2.1.2.  Principal Scenarios
    2.2.  Agility Requirements
    2.3.  Mechanism for Agility Support of CGA and SEND
3.  Supported Signature Algorithm Option
    3.1.  Neighbor Cache interactions
    3.2.  Processing Rules for Senders
    3.3.  Processing Rules for Receivers
4.  SEND Universal Signature Option
    4.1.  Processing Rules for Senders
    4.2.  Processing Rules for Receivers
5.  Basic negotiation
    5.1.  Overview
    5.2.  Sending Unsolicited Messages
6.  Authorization Delegation Discovery
7.  Security Considerations
8.  IANA Considerations
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
Appendix A.  On the number of Universal Signature Options supported per CGA
§  Authors' Addresses




 TOC 

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 signing and corresponding hashing algorithm agility. Besides accommodating power-constrained nodes, signing and hashing algorithm agility is also desired as a safety measure over time, to offer alternatives when cryptanalysis of one type of algorithm makes significant progress.

The aim of this memo is to outline options for allowing public key signing algorithm and hashing algorithm agility for nodes configured to perform secure neighbor discovery operations. The extent to which these options impact 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.) is also addressed.



 TOC 

2.  Overview



 TOC 

2.1.  Compatibility with existing specifications

The current SEND protocol specification, [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.), mandates the use of the RSA signature algorithm. Since the time of its writing, different signature algorithms have been shown to be secure and have been adopted by other protocols in an effort to reduce key length, signature generation and verification time, and increase security level. This shift in signature algorithm adoption particularly benefits lightweight devices, which are power and memory-limited but in need of secure signing algorithms support. For these reasons, we feel that the restriction on the signature algorithm for SEND is no longer warranted.



 TOC 

2.1.1.  Classification of SEND nodes

At the time of this writing, there are no known large-scale or even small-scale deployment of [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.)-compatible devices. However, in the interest of caution, we assume that there exist nodes that support only the RSA algorithm and that are configured to perform secure neighbor discovery. Such nodes may not be updated in the near term or for the foreseeable future. On the other hand, it appears that there will be deployments of nodes that support only Elliptic Curve Cryptography as their public key algorithm, i.e. ECDSA as a signature algorithm, rather than traditional RSA.

To ensure that all possible network/link configurations are considered when designing a signature agility solution, we categorize nodes (hosts and routers) according to their support for different signature algorithms, as follows:

Type H1 host:

A host that only supports one type of signature algorithm and has a CGA generated with the public key of this algorithm.
Examples of this type of hosts: an old host that does not support signature agility, i.e. only supports RSA signature algorithm; or, a host that only supports ECDSA signature.
Type H2 host:

A host that supports multiple signature algorithms and has a CGA generated with only one key selected from among its supported algorithms.
Examples of this type of hosts: (1) a host that supports RSA and ECDSA signature algorithms, but only has a CGA derived with an RSA public key; (2) a host that supports RSA and ECDSA signature algorithms, but only has a CGA derived with an ECC public key.
Type H3 host:

A host that supports multiple signature algorithms and has a CGA generated with multiple keys of different supported algorithms.
Such CGA addresses have been studied during the writing of this document and have been proved to be hard to secure.
Type H4 host:

A host that supports multiple signature algorithms and has multiple CGAs, each of which is associated with a single key of one supported algorithm.
A node MUST select and settle on one CGA when building a trust relationship with another device via SeND (more below). In such cases, a destination node may be reached at a CGA associated with a signature algorithm that the originating node cannot verify. The destination node will need to securely redirect the originating node to one of its other CGA(s) (presumably with a common signature algorithm). The need for a method to secure the binding between the two CGAs of the destination node is still an open problem, that is considered out of scope.
Based on this reasoning, consideration of H4 type nodes is left for future work.

Routers are more likely to possess the resources necessary to support multiple signature and hashing algorithms. It is also more feasible that routers employ certificates. However, for a basic signature agility solution, we do not mandate that routers support multiple signature and hashing algorithms.

Possible router devices with different signature algorithm support ability are:

Type R1 router:

A router that only supports one type of signature algorithm and has a CGA and Certificate with a public key of this algorithm.
Such routers are expected to be commonplace, as compliance with [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) suffices for them.
Type R2 router:

A router that supports multiple types of signature algorithms and has one CGA and Certificate with a public key of one of the algorithm types.
This type of router can sign and verify signatures of the type of certificate it owns, and additionally, it can verify signatures of other algorithm types.
Type R3 router:

A router that supports multiple types of signature algorithms and has one CGA composed of multiple Publics Keys and multiple certificates containing each a Public Key.
Similar considerations as for H3 host type apply here: CGA addresses based on multiple Public Keys are hard to secure and should not be used.
Type R4 router:

A router that supports multiple types of signature algorithms and has multiple CGAs and Certificates with public key of several different algorithm types.
This type of router can sign and verify signatures of multiple types. Such routers may not be attractive to build and deploy due to increased requirements on its resources. Moreover using multiple CGAs (with no bindings) may make that routers appear as having multiple identities.

Note that all types of router presented above can be configured to use SEND over multiple interfaces or to have multiple addresses on the same interface. In this case, the router will use separate CGAs. Such configuration is treated in this draft as if the different addresses refer to separate entities.



 TOC 

2.1.2.  Principal Scenarios

Based on the discussion above, a SEND agility solution should at least properly deal with the communication between devices of type H1, H2, R1, R2 and R4.

An H1 or R1 node interacting with an H2 or R2 node: i.e., a node supporting only RSA (for example, an old non-agility node which only supports RFC3971) and a node supporting both RSA and ECDSA (or other new algorithms). These two nodes may be able to perform secure neighbor discovery.

An H1 or R1 node interacting with another H1 or R1 node, but their algorithms differ: e.g., a node supporting only RSA (for example, an old non-agility node which only supports RFC3971) and a node supporting only ECDSA (or other new algorithms). In this case, implementations supporting SEND signature agility solution may likely realize the incompatibility, while older implementations may not.

An H2, or R2 node interacting with another H2 or R2 node: when the two nodes support at least verification of the signature algorithm used by its correspondent for signature generation (tightly bound to the Public Key type used to generate the CGA address), they can perform secure neighbor discovery.



 TOC 

2.2.  Agility Requirements

We hold the following to be requirements on a signing algorithm agility solution for SEND:



 TOC 

2.3.  Mechanism for Agility Support of CGA and SEND

This document proposes an update to [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) to allow two SEND nodes to choose an appropriate signature algorithm. This solution encompasses the following:

We define the aforementioned options format and provide processing rules for both senders and receivers of SEND messages employing the new options, as well as example negotiation message flows.

Note that the ECC support for SEND is described in document [cheneau‑csi‑ecc‑sig‑agility] (Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “ECC public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND),” November 2009.).



 TOC 

3.  Supported Signature Algorithm Option

The Supported Signature Algorithm (SSA) NDP option contains a list of signing and hashing algorithm pairs that the sender node supports. The format of this option is described in Figure 1 (Supported Signature Algorithm option):



 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |           Reserved            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sig. Alg. 1   | Sig. Alg. 2   |  Sig. Alg 3.  | Sig. Alg 4.   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                          ...                                  |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     ...      | Sig. Alg. N  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 1: Supported Signature Algorithm option 

Type

NDP option type, TBA. See Section 8 (IANA Considerations).
Length

The length of the option (including the Type, Length fields), in octets. 8-bit unsigned integer, the values lower than 2 are invalid.
Reserved

Reserved for future use. This 16-bit field MUST be set to zero by the sender, and MUST be ignored by the receiver.
Signature Algorithm

A one-octet long field indicating a signature algorithm and the corresponding hash algorithm that this node supports; this support implies at least ability to verify signatures of this Signature Algorithm algorithm.

If the first leftmost bit, bit 0, is set to 0, it indicates that the emitter is able to perform signature checks only (i.e. no signature generation with this type of signature algorithm). If this bit is set to 1, it indicates that the emitter has a public key of this type and can generate signatures. Bit 1 and 2 are reserved. Bit 3 to 7 are named Signature Type Identifier subfield and encode an identifier for the signature algorithm and corresponding hash algorithm. Default values for the Signature Type Identifier subfield defined in this document are taken in part from the IANA-defined numbers for the IKEv2 protocol, i.e. IANA registry named "IKEv2 Authentication Method": The Signature/hash Algorithm combinations SHOULD be included in order of preference.
A SSA option MAY be built to respect a Local Policy. However, the SSA option MUST not indicate Signature Algorithm(s) that the emitting node's CGA does not support and MUST contain at least one Signature Algorithm with the first bit on (i.e. this Signature Algorithm is available for signature generation).



 TOC 

3.1.  Neighbor Cache interactions

Neighbor Cache MUST have the ability to store Supported Signature Algorithm information for each entry (i.e. IPv6 address). Supported Signature Algorithm information for an entry MAY be empty (e.g. entry created by a RFC 3971 node or an unverifiable message).



 TOC 

3.2.  Processing Rules for Senders

If a node has been configured to use SEND, then all Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, Router Advertisement, and Redirect messages it sends MUST contain the Supported Signature Algorithm option. This option MUST contain in the Signature Algorithm field(s) all the signature algorithms it is willing to use in signature generation and verification.



 TOC 

3.3.  Processing Rules for Receivers

Upon receiving a SEND packet with a Supported Signature Algorithm Option, a receiver performs the following operations:



 TOC 

4.  SEND Universal Signature Option

We propose replacing the RSA Signature Option by a new algorithm-independent signature option. The "Universal Signature Option" is an updated version of the RSA Signature Option, that allows a node to specify which Signature Algorithm it is using. To achieve this, we use the 16-bit reserved field of the RSA Signature Option, and define a new 5-bit Signature Type Identifier field that details the type of algorithms used to generate the Digital Signature.



    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |        Reserved     |  Sig ID |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                          Key Hash                             |
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                       Digital Signature                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                           Padding                             .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Figure 2: Universal Signature Option format 

Type

Same value as in [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.): 12.
Length

The length of the option (including the Type, Length, Reserved, Signature Type Identifier, Key Hash, Digital Signature, and Padding fields) in units of 8 octets.
Reserved

A 11-bit field reserved for future use. The value MUST be set to zero by the sender and MUST be ignored by the receiver.
Signature Type Identifier

Signature Type Identifier is a 5-bit field. It corresponds to the Signature Type Identifier subfield (bits 3 to 7 of the Signature Algorithm field) in the Supported Signature Algorithm option . It indicates the type of signature contained in the Digital Signature field.
Key Hash

A 128-bit field containing the most significant (leftmost) 128 bits of a hash of the public key used for constructing the signature. It is computed using the same hash function as used in generating digital signature (indicated in Signature Type Identifier). The hash value is computed over the presentation used in the Public Key field of the CGA Parameters data structure carried in the CGA option. Its purpose is to associate the signature with a particular key known by the receiver. Such a key can either be stored in the certificate cache of the receiver or be received in the CGA option in the same message.
Digital Signature

A variable-length field containing a signature constructed by using the sender's private key associated to the public key. The signature type is determined from the value of the Signature Type Identifier field. This field starts after the Key Hash field. The length of the Digital Signature field is determined by the length of the Universal Signature option minus the length of the other fields (including the variable length Pad field).
Padding
This variable-length field contains padding, as many bytes long as remain after the end of the signature.

A Neighbor Solicitation/Advertisement, Router Solicitation/Advertisement and Redirect message MAY contain more than one Universal Signature Option, as long as it does not exceed the MTU. This is particularly useful for routers operating in heterogeneous networks, where hosts have a disjoint set of supported signature algorithms. For information on how to compute the message size, see Appendix A (On the number of Universal Signature Options supported per CGA).



 TOC 

4.1.  Processing Rules for Senders

When sending a SEND message spontaneously, an emitter node CAN choose a signature algorithm of its preference (defined by its local policy) among the corresponding Signature Algorithm available for the Public Key carried in the CGA option. Using this signature algorithm, the node computes the Digital Signature and fills the Signature Type Identifier field with appropriate value.

If the node has been configured to use SEND, then all Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages MUST contain at least one Universal Signature option. Router Solicitation messages not sent with the unspecified source address MUST contain the Universal Signature option.

A node sending a message with one or more Universal Signature option(s) MUST construct the message as follows:



 TOC 

4.2.  Processing Rules for Receivers

Neighbor Solicitation, Neighbor Advertisement, Router Advertisement, and Redirect messages without any Universal Signature option or with an unverifiable Universal Signature option MUST be treated as unsecured (i.e., processed in the same way as NDP messages sent by a non-SEND node). See Section 8 of [RFC3971] (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.).

Router Solicitation messages without any Universal Signature option MUST also be treated as unsecured, unless the source address of the message is the unspecified address.

Redirect, Neighbor Solicitation, Neighbor Advertisement, Router Solicitation, and Router Advertisement messages containing one or more Universal Signature option MUST be checked as follows:

Messages that do not pass all the above tests MUST be silently discarded if the host has been configured to accept only secured ND messages. The messages MAY be accepted if the host has been configured to accept both secured and unsecured messages but MUST be treated as unsecured messages. The receiver MAY also otherwise silently discard packets (e.g., as a response to an apparent CPU exhausting DoS attack).



 TOC 

5.  Basic negotiation



 TOC 

5.1.  Overview

This section describes different configurations of SEND-enabled nodes with varying signing capabilities and their interaction during the negotiation phase.

Case 1: when both nodes support the same two Signature Algorithms, they can pick the Signature Algorithm they prefer for signing and are able to verify each others signature. Figure 3 (Basic negotiation - Case 1) is an example of such a message flow.



Node A                                    Node B

NS
{CGA option,
RSA/SHA-1 Signature option.
Supported-Signature-Algo option
(RSA/SHA-1 sign & verif, RSA/SHA-256 sign & verif)}
                     -------->
                                NA
                                {CGA option,
                                RSA/SHA-256 Signature option
                                Supported-Signature-Algo option
                                (RSA/SHA-256 sign & verif,
                                 RSA/SHA-1 sign & verif)}
                     <--------

IPv6 traffic         <------->  IPv6 traffic
 Figure 3: Basic negotiation - Case 1 

Case 2: two nodes sharing at least one common Signing Algorithm must be able to securely communicate. Figure 4 (Basic negotiation - Case 2) is an example of such a message flow.



Node A                                      Node B

NS
{CGA option,
RSA/SHA-1 Signature option.
Supported-Signature-Algo option
(RSA/SHA-1 sign & verif, RSA/SHA-256 sign & verif)}
                       -------->
                                   NA
                                   {CGA option,
                                   RSA/SHA-256 Signature option
                                   Supported-Signature-Algo option
                                   (RSA/SHA-256 sign & verif)}
                       <--------
                                   (At this point, Node B could not
                                   authenticate Node A's Neighbor
                                   Solicitation)

                       --------> (unidirectionnal) IPv6 traffic

                                   NS
                                   {CGA option,
                                   RSA/SHA-256 Signature option
                                   Supported-Signature-Algo option
                                   (RSA/SHA-256 sign & verif)}
                       <--------
NA
{CGA option,
RSA/SHA-256 Signature option.
Supported-Signature-Algo option
(RSA/SHA-1 sign & verif, RSA/SHA-256 sign & verif)}
                       -------->

IPv6 traffic           <------->  IPv6 traffic
 Figure 4: Basic negotiation - Case 2 

Case 3: when two nodes have a disjoint set of Signature Algorithm support for signing, but the two nodes are able to verify each others, a full negotiation is possible. Figure 5 (Basic negotiation - Case 3) is an example of such a message flow.



Node A                                    Node B

NS
{CGA option,
RSA/SHA-1 Signature option.
Supported-Signature-Algo option
(RSA/SHA-1 sign & verif, ECC/SHA-256 verif only)}
                      -------->
                               NA
                               {CGA option,
                               ECC/SHA-256 Signature option
                               Supported-Signature-Algo option
                               (ECC/SHA-256 sign & verif,
                                RSA/SHA-1 verif only)}
                     <--------

IPv6 traffic         <------->  IPv6 traffic
 Figure 5: Basic negotiation - Case 3 

Case 4: when two nodes have a disjoint set of Signature Algorithm support for signing, but one node is able to verify, a partial negotiation is possible. Figure 6 (Basic negotiation - Case 4) is an example of such a message flow.



Node A                                    Node B

NS
{CGA option,
RSA/SHA-1 Signature option.
Supported-Signature-Algo option
(RSA/SHA-1 sign & verif)}
                     -------->
                                NA
                                {CGA option,
                                ECC/SHA-256 Signature option
                                Supported-Signature-Algo option
                                (ECC/SHA-256 sign & verif,
                                 RSA/SHA-1 verif only)}
                    <--------

          (...depending on local policies...)
IPv6 traffic        <------->  IPv6 traffic
 Figure 6: Basic negotiation - Case 4 

Upon receiving the Neighbor Solicitation message, node B determines, through the Supported Signature Algorithm option, that node A will not be able to verify any of its signature algorithm. However, based on their local policy, node B may answer and node A might decide to trust the unsecure Neighbor Discovery (thus being vulnerable), see Section 4.2 (Processing Rules for Receivers).



 TOC 

5.2.  Sending Unsolicited Messages

When sending unsolicited message, a node MAY have to rely on the entries of its Neighbor Cache. The Neighbor Cache will provide hints concerning the Signature Algorithm supported by the neighbors. Neighbor Cache can assist the node in the Signature Algorithm selection process when:

Note that the information on the neighbors with which a communication has occurred recently or is ongoing are in the Neighbor Cache and are maintained up to date through the Neighbor Unreachability Detection procedure.



 TOC 

6.  Authorization Delegation Discovery

This document advises that the Certificate Path MAY only contain certificates signed with a same signature algorithm. That is, if a node support this specific signature type, he will be able to verify all the certificates composing the Certificate Path. However, when only one Certificate Path composed of certificate signed by different signature algorithm is available, a node is expected to be able to process certificates signed with Signature Algorithm advertised by its Supported Signature Algorith option. Thus, a router can verify when responding to a Certificate Path Solicitation message if the Certificate Path is verifiable by the requester.

TBD



 TOC 

7.  Security Considerations

Section 4 (SEND Universal Signature Option) presents a new Universal Signature Option. A recommended use of this option is to allow signatures of equivalent security level (i.e. Public Keys with equivalent key lengths) for a same node.

Usage of SHA-1 for signature is strongly NOT RECOMMENDED, and when available should be preferred by the usage of SHA-256. SHA-1 security has been proved to be flawed in the light of recent attacks [Recent_SHA‑1_Attack] (McDonald, C., Haukes, P., and J. Pieprzyk, “SHA-1 collisions now 2^52,” May 2009.) [NIST‑st] (National Institute of Standards and Technology, “NIST Comments on Cryptanalytic Attacks on SHA-1,” .).

The Universal Signature Option is vulnerable to downgrade attacks. That is, given that a node can employ multiple signature types (by varying the hash function), an attacker may choose to use a flawed one. To mitigate this issue, nodes are allowed, on a local policy, to refuse to check certain types of signature (i.e. those which are know to be flawed) and will treat the associated messages as unsecured. When trying to completely mitigate downgrade attacks, an administrator MAY deploy SEND-secured nodes only authorizing a single signature algorithm scheme. This comes at a price of a reduced interoperability.



 TOC 

8.  IANA Considerations

Section 3 (Supported Signature Algorithm Option) defines a Signature Type Identifier subfield containing new values corresponding to different Signature Algorithm. This document requests creation of a new registry to the IANA.



 TOC 

9.  Acknowledgments

The authors gratefully acknowledge the contributions of Marcelo Bagnulo, Gabriel Montenegro, Greg Daley, Dave Thaler, Stephen Kent, Jari Arko, and Francis Dupont for their helpful feedback.



 TOC 

10.  References



 TOC 

10.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).
[RFC4982] Bagnulo, M. and J. Arkko, “Support for Multiple Hash Algorithms in Cryptographically Generated Addresses (CGAs),” RFC 4982, July 2007 (TXT).


 TOC 

10.2. Informative References

[cheneau-csi-ecc-sig-agility] Cheneau, T., Laurent, M., Shen, S., and M. Vanderveen, “ECC public key and signature support in Cryptographically Generated Addresses (CGA) and in the Secure Neighbor Discovery (SEND),” draft-cheneau-csi-ecc-sig-agility-01 (work in progress), November 2009 (TXT).
[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).
[NIST-st] National Institute of Standards and Technology, “NIST Comments on Cryptanalytic Attacks on SHA-1.”
[PKCS1] RSA Laboratories, “RSA Encryption Standard, Version 2.1,” PKCS 1, November 2002.
[FIPS.180-2] National Institute of Standards and Technology, “Secure Hash Standard,” FIPS PUB 180-2, August 2002.
[SEC1] Standards for Efficient Cryptography Group, “SEC 1: Elliptic Curve Cryptography,” September 2000.
[Recent_SHA-1_Attack] McDonald, C., Haukes, P., and J. Pieprzyk, “SHA-1 collisions now 2^52,” May 2009.


 TOC 

Appendix A.  On the number of Universal Signature Options supported per CGA



RSA key length (bits)Public exponentSize of the DER-encoded Public Key (bytes)
384 3 or 17 76
384 65537 78
512 3 or 17 92
512 65537 94
1024 3 or 17 160
1024 65537 162
2048 3 or 17 292
2048 65537 294
3072 3 or 17 420
3072 65537 422
7680 3 or 17 996
7680 65537 998
15360 3 or 17 1956
15360 65537 1958

 Table 1: Common sizes for DER-encoded RSA Public Key 



RSA Key Length (in bits)Size of the Digital Signature field without padding
384 48
512 64
1024 128
2048 256
3072 384
7680 960
15360 1920

 Table 2: Common sizes of the Digital Signature field when using RSA 

When using multiple Universal Signature Options, one may reach before each Neighbor the Maximum Transfer Unit (which must be at least 1280 octets according to [RFC2460] (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.)). This section aims to approximate this limit.

Numerous factors (presence and number of option, size of public key, etc) influence the size of the Neighbor Discovery message. For example, when sending a SEND-secured Router Advertisement message:

A Router Advertisement message, carrying a Prefix Information Option and a Source Link-Layer Option, without Nonce, with one 1024-bits long RSA Public Key and a Public Exponent of 3 in the CGA Option is 456 bytes long.



 TOC 

Authors' Addresses

  Tony Cheneau
  Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
  9 rue Charles Fourier
  Evry 91011
  France
Email:  tony.cheneau@it-sudparis.eu
  
  Maryline Laurent
  Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
  9 rue Charles Fourier
  Evry 91011
  France
Email:  maryline.laurent@it-sudparis.eu
  
  Sean Shen
  Huawei
  4, South 4th Street, Zhongguancun
  Beijing 100190
  P.R. China
Email:  sean.s.shen@gmail.com
  
  Michaela Vanderveen
  Qualcomm
Email:  mvandervn@gmail.com