< draft-kivinen-ipsecme-oob-pubkey-12.txt   draft-kivinen-ipsecme-oob-pubkey-13.txt >
Network Working Group T. Kivinen Network Working Group T. Kivinen
Internet-Draft INSIDE Secure Internet-Draft INSIDE Secure
Updates: 7296 (if approved) P. Wouters Updates: 7296 (if approved) P. Wouters
Intended status: Standards Track Red Hat Intended status: Standards Track Red Hat
Expires: March 25, 2016 H. Tschofenig Expires: April 08, 2016 H. Tschofenig
September 22, 2015
October 06, 2015
More Raw Public Keys for IKEv2 More Raw Public Keys for IKEv2
draft-kivinen-ipsecme-oob-pubkey-12.txt draft-kivinen-ipsecme-oob-pubkey-13.txt
Abstract Abstract
The Internet Key Exchange Version 2 (IKEv2) protocol only supports The Internet Key Exchange Version 2 (IKEv2) protocol only supports
RSA for raw public keys. In constrained environments it is useful to RSA for raw public keys. In constrained environments it is useful to
make use of other types of public keys, such as those based on make use of other types of public keys, such as those based on
Elliptic Curve Cryptography. This documents adds support for other Elliptic Curve Cryptography. This documents adds support for other
types of raw public keys to IKEv2. types of raw public keys to IKEv2.
This document updates RFC 7296
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 25, 2016. This Internet-Draft will expire on April 08, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 17 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Certificate Encoding Payload . . . . . . . . . . . . . . . . 3 3. Certificate Encoding Payload . . . . . . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 7
A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . 7 A.1. ECDSA Example . . . . . . . . . . . . . . . . . . . . . . 7
A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . 8 A.2. RSA Example . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document replaces an algorithm-specific version of raw public This document replaces an algorithm-specific version of raw public
keys of Internet Key Exchange Version 2 (IKEv2) [RFC7296] with a keys of Internet Key Exchange Version 2 (IKEv2) [RFC7296] with a
generic version of raw public keys that is algorithm agnostic. generic version of raw public keys that is algorithm agnostic.
skipping to change at page 2, line 40 skipping to change at page 2, line 43
DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other DER-encoded RSAPublicKey structure (see [RSA] and [RFC3447]). Other
raw public key types are, however, not supported. In [RFC7296] this raw public key types are, however, not supported. In [RFC7296] this
feature was removed, and this document adds support for raw public feature was removed, and this document adds support for raw public
keys back to IKEv2 in a more generic way. keys back to IKEv2 in a more generic way.
Secure DNS allows public keys to be associated with domain names for Secure DNS allows public keys to be associated with domain names for
usage with security protocols like IKEv2 and Transport Layer Security usage with security protocols like IKEv2 and Transport Layer Security
(TLS) [RFC5246] but it relies on extensions in those protocols to be (TLS) [RFC5246] but it relies on extensions in those protocols to be
specified. specified.
The TLS Out-of-Band Public Key Validation specification ([RFC7250]) The Raw Public Keys in Transport Layer Security specification
adds generic support for raw public keys to TLS by re-using the ([RFC7250]) adds generic support for raw public keys to TLS by re-
SubjectPublicKeyInfo format from the X.509 Public Key Infrastructure using the SubjectPublicKeyInfo format from the X.509 Public Key
Certificate profile [RFC5280]. Infrastructure Certificate profile [RFC5280].
This document is similar to the TLS Out-of-Band Public Key Validation This document is similar to the Raw Public Keys in Transport Layer
specification, and applies the concept to IKEv2 to support all public Security specification and applies the concept to IKEv2 to support
key formats defined by PKIX. This approach also allows future public all public key formats defined by PKIX. This approach also allows
key extensions to be supported without the need to introduce further future public key extensions to be supported without the need to
enhancements to IKEv2. introduce further enhancements to IKEv2.
To support new types of public keys in IKEv2 the following changes To support new types of public keys in IKEv2 the following changes
are needed: are needed:
o A new Certificate Encoding format needs to be defined for carrying o A new Certificate Encoding format needs to be defined for carrying
the SubjectPublicKeyInfo structure. Section 3 specifies this new the SubjectPublicKeyInfo structure. Section 3 specifies this new
encoding format. encoding format.
o A new Certificate Encoding type needs to be allocated from the o A new Certificate Encoding type needs to be allocated from the
IANA registry. Section 5 contains this request to IANA. IANA registry. Section 5 contains this request to IANA.
The base IKEv2 include support for RSA and DSA signatures, but the The base IKEv2 specification includes support for RSA and DSA
Signature Authentication in IKEv2 [RFC7427] extended IKEv2 so that signatures, but the Signature Authentication in IKEv2 [RFC7427]
signature methods over any types of keys can be used. extended IKEv2 so that signature methods over any key type can be
Implementations using raw public keys SHOULD use the Digital used. Implementations using raw public keys SHOULD use the Digital
Signature method described in the RFC7427. Signature method described in the RFC7427.
When using raw public keys, the authenticated identity is not usually When using raw public keys, the authenticated identity is not usually
the identity from the ID payload, but instead the public key itself the identity from the ID payload, but instead the public key itself
is used as identity for the other end. This means that ID payload is used as identity for the other end. This means that ID payload
contents might not be useful for authentication purposes. It might contents might not be useful for authentication purposes. It might
still be used for policy decisions, for example to simplify the still be used for policy decisions, for example to simplify the
policy lookup etc. policy lookup etc. Alternatively, the ID_NULL type [RFC7619] can be
used to indicate that the ID payload is not relevant to this
authentication.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Certificate Encoding Payload 3. Certificate Encoding Payload
Section 3.6 of RFC 7296 defines the Certificate payload format as Section 3.6 of RFC 7296 defines the Certificate payload format as
skipping to change at page 4, line 9 skipping to change at page 4, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Certificate Payload Format. Figure 1: Certificate Payload Format.
To support raw public keys, the field values are as follows: To support raw public keys, the field values are as follows:
o Certificate Encoding (1 octet) - This field indicates the type of o Certificate Encoding (1 octet) - This field indicates the type of
certificate or certificate-related information contained in the certificate or certificate-related information contained in the
Certificate Data field. Certificate Data field.
Certificate Encoding Value Certificate Encoding Value
---------------------------------------------------- ----------------------------------------------------
Raw Public Key TBD Raw Public Key TBD
o Certificate Data (variable length) - Actual encoding of the o Certificate Data (variable length) - Actual encoding of the
certificate data. certificate data.
In order to provide a simple and standard way to indicate the key In order to provide a simple and standard way to indicate the key
type when the encoding type is 'Raw Public Key', the type when the encoding type is 'Raw Public Key', the
SubjectPublicKeyInfo structure of the PKIX certificate is used. This SubjectPublicKeyInfo structure of the PKIX certificate is used. This
is a very simple encoding, as most of the ASN.1 part can be included is a very simple encoding, as most of the ASN.1 part can be included
literally, and recognized by block comparison. See [RFC7250] literally, and recognized by block comparison. See [RFC7250]
Appendix A for a detailed breakdown. In addition, Appendix A has Appendix A for a detailed breakdown. In addition, Appendix A has
skipping to change at page 5, line 7 skipping to change at page 5, line 14
into the IKEv2 software. "Smart object" deployments are likely to into the IKEv2 software. "Smart object" deployments are likely to
use such preconfigured public keys. use such preconfigured public keys.
Another approach is to rely on secure DNS to associate public keys Another approach is to rely on secure DNS to associate public keys
with domain names using the IPSECKEY DNS RRtype [RFC4025]. More with domain names using the IPSECKEY DNS RRtype [RFC4025]. More
information can be found in DNS-Based Authentication of Named information can be found in DNS-Based Authentication of Named
Entities (DANE) [RFC6394]. Entities (DANE) [RFC6394].
This document does not change the security assumptions made by the This document does not change the security assumptions made by the
IKEv2 specification since "Raw RSA Key" support was already available IKEv2 specification since "Raw RSA Key" support was already available
in IKEv2. This document only generalizes raw public key support. in IKEv2 in [RFC5996]. This document only generalizes raw public key
support.
5. IANA Considerations 5. IANA Considerations
This document allocates a new value from the IKEv2 Certificate This document allocates a new value from the IKEv2 Certificate
Encodings registry: Encodings registry:
TBD Raw Public Key TBD Raw Public Key
6. Acknowledgements 6. Acknowledgements
This document reproduces some parts of the similar TLS document This document reproduces some parts of the similar TLS document
([RFC7250]). ([RFC7250]).
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, May 2008.
<http://www.rfc-editor.org/info/rfc5280>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, October 2014.
2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in [RFC7427] Kivinen, T. and J. Snyder, "Signature Authentication in
the Internet Key Exchange Version 2 (IKEv2)", RFC 7427, the Internet Key Exchange Version 2 (IKEv2)", RFC 7427,
DOI 10.17487/RFC7427, January 2015, DOI 10.17487/RFC7427, January 2015,
<http://www.rfc-editor.org/info/rfc7427>. <http://www.rfc-editor.org/info/rfc7427>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<http://www.rfc-editor.org/info/rfc7619>.
7.2. Informative References 7.2. Informative References
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>. 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March Material in DNS", RFC 4025, DOI 10.17487/RFC4025, March
2005, <http://www.rfc-editor.org/info/rfc4025>. 2005, <http://www.rfc-editor.org/info/rfc4025>.
skipping to change at page 6, line 22 skipping to change at page 6, line 34
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>. <http://www.rfc-editor.org/info/rfc4055>.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)", the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, DOI 10.17487/RFC4754, January 2007, RFC 4754, DOI 10.17487/RFC4754, January 2007,
<http://www.rfc-editor.org/info/rfc4754>. <http://www.rfc-editor.org/info/rfc4754>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/ (TLS) Protocol Version 1.2", RFC 5246, August 2008.
RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key "Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, DOI 10.17487/RFC5480, March 2009, Information", RFC 5480, DOI 10.17487/RFC5480, March 2009,
<http://www.rfc-editor.org/info/rfc5480>. <http://www.rfc-editor.org/info/rfc5480>.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, DOI 10.17487/RFC5996, September 2010, 5996, DOI 10.17487/RFC5996, September 2010,
<http://www.rfc-editor.org/info/rfc5996>. <http://www.rfc-editor.org/info/rfc5996>.
skipping to change at page 6, line 47 skipping to change at page 7, line 8
Authentication of Named Entities (DANE)", RFC 6394, DOI Authentication of Named Entities (DANE)", RFC 6394, DOI
10.17487/RFC6394, October 2011, 10.17487/RFC6394, October 2011,
<http://www.rfc-editor.org/info/rfc6394>. <http://www.rfc-editor.org/info/rfc6394>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <http://www.rfc-editor.org/info/rfc7250>. June 2014, <http://www.rfc-editor.org/info/rfc7250>.
[RSA] R. Rivest, , A. Shamir, , and L. Adleman, "A Method for [RSA] R. Rivest, ., A. Shamir, ., and . L. Adleman, "A Method
Obtaining Digital Signatures and Public-Key for Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978. Cryptosystems", February 1978.
Appendix A. Examples Appendix A. Examples
This appendix provides examples of the actual payloads sent on the This appendix provides examples of the actual payloads sent on the
wire. wire.
A.1. ECDSA Example A.1. ECDSA Example
This first example uses the 256-bit ECDSA private/public key pair This first example uses the 256-bit ECDSA private/public key pair
 End of changes. 17 change blocks. 
35 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/