CGA & Send maintenance                                        T. Cheneau
Internet-Draft                                            M. Maknavicius
Expires: April 15, 2010                                             TMSP
                                                                 S. Shen
                                                                  Huawei
                                                           M. Vanderveen
                                                                Qualcomm
                                                        October 12, 2009


Support for Multiple Signature Algorithms in Cryptographically Generated
                            Addresses (CGAs)
                  draft-cheneau-csi-cga-pk-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.




Cheneau, et al.          Expires April 15, 2010                 [Page 1]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Public Key extension . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Public Key extension format  . . . . . . . . . . . . . . .  4
   3.  CGA Generation Process . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Specific usage with SEND . . . . . . . . . . . . . . . . .  8
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14



























Cheneau, et al.          Expires April 15, 2010                 [Page 2]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


1.  Introduction

   Cryptographically Generated Addresses (CGA) [RFC3972] 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] 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] states that SEND
   "SHOULD" use an RSA public/private key pair, backward compatibility
   must be 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].
   One type of CGA Parameters data structure extension is defined in
   Section 2 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 support new functionnalities for CGA based
   protocols, such as the Signature Algorithm Agility in SEND
   [cheneau-csi-send-sig-agility].


















Cheneau, et al.          Expires April 15, 2010                 [Page 3]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


2.  Public Key extension

   This section describes an extension field that conforms to the
   guidelines of [RFC4581].

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

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                              ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Public Key extension format

   Extension Type

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

   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] ASN.1 structure of the type SubjectPublicKeyInfo,
      defined in the Internet X.509 certificate profile [RFC5280].  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



Cheneau, et al.          Expires April 15, 2010                 [Page 4]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


      [RFC3279].  The RSA key length SHOULD be at least 384 bits.

      Section 3 of document [cheneau-csi-ecc-sig-agility] specifies how
      to use ECC Public Key in CGA and defines the format of the Public
      Key field for the Public Key extension.














































Cheneau, et al.          Expires April 15, 2010                 [Page 5]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


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]; 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, as illustrated in Figure 2.  Thus
   generation and verification of CGA as defined in Section 4 and
   Section 5 of [RFC3972] remain unchanged.

   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] is a
   DER-encoded ASN.1 structure of the type "SubjectPublicKeyInfo", and
   therefore includes a subfield called "AlgorithmIdentifier".


































Cheneau, et al.          Expires April 15, 2010                 [Page 6]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


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


           Figure 2: CGA Parameters structure with multiple keys

   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



Cheneau, et al.          Expires April 15, 2010                 [Page 7]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


   specification.

3.1.  Specific usage with SEND

   [RFC3972] recommends the use of RSA keys in the Public Key field when
   using SEND [RFC3971].  A node compatible with [RFC3972] will only
   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).





































Cheneau, et al.          Expires April 15, 2010                 [Page 8]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


4.  Security Considerations

   The document specifies a CGA extension field format.  No additional
   vulnerabilities are introduced besides those described in section 7
   of [RFC3972].

   However, it should be noted that the resulting security level of a
   multiple-key CGA, that this document enables to use, is only that of
   the weakest key.  Therefore, when RSA is used, the RSA key length
   SHOULD be the minimum length recommended in Section 3 of [RFC3972] or
   the current minimum recommended by leading standards bodies such as
   NIST.  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.

































Cheneau, et al.          Expires April 15, 2010                 [Page 9]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


5.  IANA Considerations

   This document defines one new CGA Extension Type [RFC4581] option,
   which must be assigned by IANA:

      Name: Public Key Extension Type;

      Value: TBA.

      Description: see Section 2.









































Cheneau, et al.          Expires April 15, 2010                [Page 10]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


6.  Acknowledgments

   The authors would like to thank Jean-Michel Combes for his helpful
   comments.















































Cheneau, et al.          Expires April 15, 2010                [Page 11]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


7.  References

7.1.  Normative References

   [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", RFC 5280, May 2008.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, March 2005.

   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC4982]  Bagnulo, M. and J. Arkko, "Support for Multiple Hash
              Algorithms in Cryptographically Generated Addresses
              (CGAs)", RFC 4982, July 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

7.2.  Informative References

   [RFC4581]  Bagnulo, M. and J. Arkko, "Cryptographically Generated
              Addresses (CGA) Extension Field Format", RFC 4581,
              October 2006.

   [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", RFC 3279, April 2002.

   [RFC4866]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
              Optimization for Mobile IPv6", RFC 4866, May 2007.

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
              "Elliptic Curve Cryptography Subject Public Key
              Information", RFC 5480, March 2009.

   [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)", ITU-T
              Recommandation X.690, July 2002.




Cheneau, et al.          Expires April 15, 2010                [Page 12]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


   [cheneau-csi-ecc-sig-agility]
              Cheneau, T., Laurent-Maknavicius, 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-cga-pk-agility-00 (work in progress),
              October 2009.

   [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",
              draft-cheneau-csi-send-sig-agility-00 (work in progress),
              October 2009.





































Cheneau, et al.          Expires April 15, 2010                [Page 13]

Internet-Draft    Signature Algorithm Agility for CGAs      October 2009


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-Maknavicius
   Institut TELECOM, TELECOM SudParis, CNRS SAMOVAR UMR 5157
   9 rue Charles Fourier
   Evry  91011
   France

   Email: maryline.maknavicius@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


















Cheneau, et al.          Expires April 15, 2010                [Page 14]