Skip to main content

More Raw Public Keys for IKEv2
draft-kivinen-ipsecme-oob-pubkey-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7670.
Expired & archived
Authors Tero Kivinen , Paul Wouters , Hannes Tschofenig
Last updated 2012-09-06 (Latest revision 2012-03-05)
Replaced by draft-ietf-ipsecme-oob-pubkey
RFC stream (None)
Formats
Reviews
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7670 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kivinen-ipsecme-oob-pubkey-00
IP Security Maintenance and Extensions                        T. Kivinen
(ipsecme)                                                      AuthenTec
Internet-Draft                                                P. Wouters
Intended status: Informational                                   Red Hat
Expires: September 6, 2012                                 H. Tschofenig
                                                  Nokia Siemens Networks
                                                           March 5, 2012

                     More Raw Public Keys for IKEv2
                draft-kivinen-ipsecme-oob-pubkey-00.txt

Abstract

   The Internet Key Exchange Version 2 (IKEv2) protocol currently only
   supports raw RSA keys.  In some environments it is useful to make use
   of other types of public keys, such as those based on Elliptic Curve
   Cryptography.  This documents adds support for other types of raw
   public keys to IKEv2.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on September 6, 2012.

Copyright Notice

   Copyright (c) 2012 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

Kivinen, et al.         Expires September 6, 2012               [Page 1]
Internet-Draft       More Raw Public Keys for IKEv2           March 2012

   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  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Certificate Encoding Payload  . . . . . . . . . . . . . . . . . 3
   3.  Old Raw RSA Key Certificate Type  . . . . . . . . . . . . . . . 4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6

Kivinen, et al.         Expires September 6, 2012               [Page 2]
Internet-Draft       More Raw Public Keys for IKEv2           March 2012

1.  Introduction

   Secure DNS allows public keys to be associated with domain names for
   usage with security protocols like Internet Key Exchange Version 2
   (IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on
   extensions in those protocols to be specified.

   IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a
   DER- encoded RSAPublicKey structure (see [RSA] and [RFC3447]).  Other
   raw public keys types are, however, not supported.

   The TLS Out-of-Band Public Key Validation specification
   ([I-D.ietf-tls-oob-pubkey]) adds generic support for raw public keys
   to TLS by re-using the SubjectPublicKeyInfo format from the X.509
   Public Key Infrastructure Certificate profile [RFC5280].

   This document is similar than the TLS Out-of-Band Public Key
   Validation specification, and applies the concept to IKEv2 to support
   all public key formats defined by PKIX.  This approach also allows
   future public key extensions to be supported without the need to
   introduce further enhancements to IKEv2.

   To support new types of public keys in IKEv2 the following changes
   are needed:

   o  A new Certificate Encoding format needs to be defined for carrying
      the SubjectPublicKeyInfo structure.  Section 2 specifies this new
      encoding format.
   o  A new Certificate Encoding type needs to be allocated from the
      IANA registry.  Section 5 contains this request to IANA.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.  Certificate Encoding Payload

   Section 3.6 of RFC 5996 defines the Certificate payload format as
   shown in Figure 1.

Kivinen, et al.         Expires September 6, 2012               [Page 3]
Internet-Draft       More Raw Public Keys for IKEv2           March 2012

                        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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Payload  |C|  RESERVED   |         Payload Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Cert Encoding |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   ~                       Certificate Data                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 1: Certificate Payload Format

   o  Certificate Encoding (1 octet) - This field indicates the type of
      certificate or certificate-related information contained in the
      Certificate Data field.

      Certificate Encoding                 Value
      ----------------------------------------------------
      Raw Public Key                       TBD

   o  Certificate Data (variable length) - Actual encoding of the
      certificate data.  The type of certificate is indicated by the
      Certificate Encoding field.

   When the certificate encoding type 'Raw Public Key' is used then the
   Certificate Data only contains the SubjectPublicKeyInfo part of the
   PKIX certificate.

   In the case of the Certificate Request payload the Certification
   Authority field MUST be empty if the "Raw Public Key" certificate
   encoding is used.

3.  Old Raw RSA Key Certificate Type

   After this there are two ways of sending Raw RSA public keys in the
   IKEv2: The already existing mechanisms, and the new format defined
   here.  The IKEv2 protocol already supports a method to indicate which
   certificate encoding formats are supported, i.e. a peer can send one
   or multiple Certificate Request payload with the certificate encoding
   types it supports.  From this list the recipient can see which
   formats are supported and select one which is used to send
   Certificate back.

   If the peer has raw non-RSA public key, it has no other option than
   to use the new format.  If it has raw RSA public key, it can either
   use the old format or the new format, and it SHOULD indicate support

Kivinen, et al.         Expires September 6, 2012               [Page 4]
Internet-Draft       More Raw Public Keys for IKEv2           March 2012

   for both by sending both certificate encoding types inside
   Certificate Request payloads.

   If a peer receives both old and new certificate endocing formats in
   the Certificate Request payloads, it is RECOMMENDED for new
   implementations to prefer this new format defined in this document,
   so the old Raw RSA public key format could possibly be phased out in
   the future.

   To better support minimal implementations, it would be best to limit
   the code complexity of those versions, and in such implementations it
   might be better to implement only the new format as it supports all
   types of raw public keys.

4.  Security Considerations

   An IKEv2 deployment using raw public keys needs to utilize an out-of-
   band public key validation procedure to be confident in the
   authenticity of the keys being used.  One such mechanism is to use a
   configuration mechanism for provisioning raw public keys into the
   IKEv2 software.  A suitable deployment is likely to be found with
   smart objects.  Yet another approach is to rely on secure DNS to
   associate public keys to be associated with domain names.  More
   information can be found in DNS-Based Authentication of Named
   Entitites (DANE) [RFC6394].

   This document does not change the assumptions made by the IKEv2
   specifications since "Raw RSA Key" support is already available in
   IKEv2.  This document only generalizes the raw public key support.

5.  IANA Considerations

   This document allocates a new value from the IKEv2 Certificate
   Encodings registry:

   TBD      Raw Public Key

6.  Acknowledgements

   This document copies parts from the similar TLS document
   ([I-D.ietf-tls-oob-pubkey]).

7.  References

Kivinen, et al.         Expires September 6, 2012               [Page 5]
Internet-Draft       More Raw Public Keys for IKEv2           March 2012

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

7.2.  Informative References

   [I-D.ietf-tls-oob-pubkey]
              Tschofenig, H., Gilmore, J., Wouters, P., Weiler, S., and
              T. Kivinen, "TLS Out-of-Band Public Key Validation",
              draft-ietf-tls-oob-pubkey-01 (work in progress),
              January 2012.

   [RFC3447]  Jonsson, J. and B. Kaliski, "Public-Key Cryptography
              Standards (PKCS) #1: RSA Cryptography Specifications
              Version 2.1", RFC 3447, February 2003.

   [RFC6394]  Barnes, R., "Use Cases and Requirements for DNS-Based
              Authentication of Named Entities (DANE)", RFC 6394,
              October 2011.

   [RSA]      R. Rivest, A. Shamir, and L. Adleman, "A Method for
              Obtaining Digital Signatures and Public-Key
              Cryptosystems", February 1978.

Authors' Addresses

   Tero Kivinen
   AuthenTec
   Eerikinkatu 28
   HELSINKI  FI-00180
   FI

   Email: kivinen@iki.fi

Kivinen, et al.         Expires September 6, 2012               [Page 6]
Internet-Draft       More Raw Public Keys for IKEv2           March 2012

   Paul Wouters
   Red Hat

   Email: pwouters@redhat.com

   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at

Kivinen, et al.         Expires September 6, 2012               [Page 7]