< draft-kivinen-ipsecme-oob-pubkey-02.txt   draft-kivinen-ipsecme-oob-pubkey-03.txt >
IP Security Maintenance and Extensions T. Kivinen IP Security Maintenance and Extensions T. Kivinen
(ipsecme) AuthenTec (ipsecme) AuthenTec
Internet-Draft P. Wouters Internet-Draft P. Wouters
Updates: RFC 5996 (if approved) Red Hat Updates: RFC 5996 (if approved) Red Hat
Intended status: Standards Track H. Tschofenig Intended status: Standards Track H. Tschofenig
Expires: April 25, 2013 Nokia Siemens Networks Expires: June 2, 2013 Nokia Siemens Networks
October 22, 2012 November 29, 2012
More Raw Public Keys for IKEv2 More Raw Public Keys for IKEv2
draft-kivinen-ipsecme-oob-pubkey-02.txt draft-kivinen-ipsecme-oob-pubkey-03.txt
Abstract Abstract
The Internet Key Exchange Version 2 (IKEv2) protocol currently only The Internet Key Exchange Version 2 (IKEv2) protocol currently only
supports raw RSA keys. In some environments it is useful to make use 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 of other types of public keys, such as those based on Elliptic Curve
Cryptography. This documents adds support for other types of raw Cryptography. This documents adds support for other types of raw
public keys to IKEv2. public keys to IKEv2 and obsoletes the old raw RSA key format.
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 April 25, 2013. This Internet-Draft will expire on June 2, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 20 skipping to change at page 2, line 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3 3. Certificate Encoding Payload . . . . . . . . . . . . . . . . . 3
4. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4 4. Old Raw RSA Key Certificate Type . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 6 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
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 Internet Key Exchange Version 2 usage with security protocols like Internet Key Exchange Version 2
(IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on (IKEv2) [RFC5996] and Transport Layer Security (TLS) but it relies on
extensions in those protocols to be specified. extensions in those protocols to be specified.
IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a IKEv2 already offers support for PKCS #1 encoded RSA keys, i.e., a
skipping to change at page 4, line 40 skipping to change at page 4, line 40
When the certificate encoding type 'Raw Public Key' is used then the When the certificate encoding type 'Raw Public Key' is used then the
Certificate Data only contains the SubjectPublicKeyInfo part of the Certificate Data only contains the SubjectPublicKeyInfo part of the
PKIX certificate. PKIX certificate.
In the case of the Certificate Request payload the Certification In the case of the Certificate Request payload the Certification
Authority field MUST be empty if the "Raw Public Key" certificate Authority field MUST be empty if the "Raw Public Key" certificate
encoding is used. encoding is used.
4. Old Raw RSA Key Certificate Type 4. Old Raw RSA Key Certificate Type
After this there are two ways of sending Raw RSA public keys in the After this there would be two ways of sending Raw RSA public keys in
IKEv2: The already existing mechanism (Raw RSA Key, encoding value the IKEv2: The original IKEv2 mechanism (Raw RSA Key, encoding value
11), and the new format defined here. The IKEv2 protocol already 11), and the new format defined here. The old Raw RSA Key encoding
supports a method to indicate what certificate encoding formats are has not been widely used. The IKEv2 protocol already supports a
supported, i.e. a peer can send one or multiple Certificate Request method to indicate what certificate encoding formats are supported,
payload with the certificate encoding types it supports. From this i.e. a peer can send one or multiple Certificate Request payload with
list the recipient can see what formats are supported and select one the certificate encoding types it supports. From this list the
which is used to send Certificate back. recipient can see what formats are supported and select one which is
used to send Certificate back.
If the peer has non-RSA raw public key, it has no other option than Implementations conforming to this document MUST use the new format
to use the new format. If it has RSA raw public key, it can either defined here for the raw public keys, regardless of the key type.
use the old format or the new format, and it SHOULD indicate support
for both by sending both certificate encoding types inside
Certificate Request payloads.
If a peer receives both old and new certificate encoding formats in This means that old Raw RSA Key encoding value 11 MUST NOT be used
the Certificate Request payloads, it is RECOMMENDED for for certificate or certificate request payloads.
implementations to prefer 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 Note, that recipients can simply process the old Raw RSA key
the code complexity of those versions, and such implementations might encodings just like any other unsupported or unknown certificate
choose to implement only the new format, which supports all types of encoding type, i.e. skip over it, recipients MUST NOT consider
raw public keys. receiving such payloads as fatal error (if other end sends such
payloads, it is completely possible that the peers do not have common
format for certificate encoding and the authentication will fail
because of that).
5. Security Considerations 5. Security Considerations
An IKEv2 deployment using raw public keys needs to utilize an out-of- An IKEv2 deployment using raw public keys needs to utilize an out-of-
band public key validation procedure to be confident in the band public key validation procedure to be confident in the
authenticity of the keys being used. One such mechanism is to use a authenticity of the keys being used. One such mechanism is to use a
configuration mechanism for provisioning raw public keys into the configuration mechanism for provisioning raw public keys into the
IKEv2 software. A suitable deployment is likely to be found with IKEv2 software. A suitable deployment is likely to be found with
smart objects. Yet another approach is to rely on secure DNS to smart objects. Yet another approach is to rely on secure DNS to
associate public keys to be associated with domain names using the associate public keys to be associated with domain names using the
IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS- IPSECKEY DNS RRtype [RFC4025]. More information can be found in DNS-
Based Authentication of Named Entities (DANE) [RFC6394]. Based Authentication of Named Entities (DANE) [RFC6394].
This document does not change the assumptions made by the IKEv2 This document does not change the assumptions made by the IKEv2
specifications since "Raw RSA Key" support is already available in specifications since "Raw RSA Key" support is already available in
IKEv2. This document only generalizes the raw public key support. IKEv2. This document only generalizes the raw public key support and
obsoletes the old "Raw RSA Key" format.
6. IANA Considerations 6. 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
This document also obsoletes the old value in the same registry, and
the entry for "Raw RSA Key" should be changed to:
11 Obsoleted (was Raw RSA Key)
7. Acknowledgements 7. Acknowledgements
This document copies parts from the similar TLS document This document copies parts from the similar TLS document
([I-D.ietf-tls-oob-pubkey]). ([I-D.ietf-tls-oob-pubkey]).
8. References 8. References
8.1. Normative References 8.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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, May 2008. (CRL) Profile", RFC 5280, May 2008.
[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)", "Internet Key Exchange Protocol Version 2 (IKEv2)",
RFC 5996, September 2010. RFC 5996, September 2010.
8.2. Informative References 8.2. Informative References
[I-D.ietf-tls-oob-pubkey] [I-D.ietf-tls-oob-pubkey]
Wouters, P., Gilmore, J., Weiler, S., Kivinen, T., and H. Wouters, P., Tschofenig, H., Gilmore, J., Weiler, S., and
Tschofenig, "Out-of-Band Public Key Validation for T. Kivinen, "Out-of-Band Public Key Validation for
Transport Layer Security", draft-ietf-tls-oob-pubkey-04 Transport Layer Security (TLS)",
(work in progress), July 2012. draft-ietf-tls-oob-pubkey-06 (work in progress),
October 2012.
[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, February 2003. Version 2.1", RFC 3447, February 2003.
[RFC4025] Richardson, M., "A Method for Storing IPsec Keying [RFC4025] Richardson, M., "A Method for Storing IPsec Keying
Material in DNS", RFC 4025, March 2005. Material in DNS", RFC 4025, March 2005.
[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, January 2007. RFC 4754, January 2007.
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", RFC 5480, March 2009.
[RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based
Authentication of Named Entities (DANE)", RFC 6394, Authentication of Named Entities (DANE)", RFC 6394,
October 2011. October 2011.
[RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for [RSA] R. Rivest, A. Shamir, and L. Adleman, "A Method for
Obtaining Digital Signatures and Public-Key Obtaining Digital Signatures and Public-Key
Cryptosystems", February 1978. Cryptosystems", February 1978.
Appendix A. Examples Appendix A. Examples
skipping to change at page 7, line 29 skipping to change at page 7, line 35
000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7) 000d : OBJECT IDENTIFIER secp256r1 (1.2.840.10045.3.1.7)
0017 : BIT STRING (66 bytes) 0017 : BIT STRING (66 bytes)
00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a 00000000: 0004 cb28 e099 9b9c 7715 fd0a 80d8 e47a
00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066 00000010: 7707 9716 cbbf 917d d72e 9756 6ea1 c066
00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911 00000020: 957c 2b57 c023 5fb7 4897 68d0 58ff 4911
00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172 00000030: c20f dbe7 1e36 99d9 1339 afbb 903e e172
00000040: 55dc 00000040: 55dc
The first byte (00) of the bit string indicates that there is no The first byte (00) of the bit string indicates that there is no
"number of unused bits", and the second byte (04) indicates "number of unused bits", and the second byte (04) indicates
uncompressed form. Those two octets are followed by the values of X uncompressed form ([RFC5480]). Those two octets are followed by the
and Y. values of X and Y.
The final encoded SubjectPublicKeyInfo object is as follows: The final encoded SubjectPublicKeyInfo object is as follows:
00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a 00000000: 3059 3013 0607 2a86 48ce 3d02 0106 082a
00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b 00000010: 8648 ce3d 0301 0703 4200 04cb 28e0 999b
00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91 00000020: 9c77 15fd 0a80 d8e4 7a77 0797 16cb bf91
00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f 00000030: 7dd7 2e97 566e a1c0 6695 7c2b 57c0 235f
00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699 00000040: b748 9768 d058 ff49 11c2 0fdb e71e 3699
00000050: d913 39af bb90 3ee1 7255 dc 00000050: d913 39af bb90 3ee1 7255 dc
 End of changes. 15 change blocks. 
35 lines changed or deleted 45 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/