draft-ietf-tls-oob-pubkey-08.txt   draft-ietf-tls-oob-pubkey-09.txt 
TLS P. Wouters, Ed. TLS P. Wouters, Ed.
Internet-Draft Red Hat Internet-Draft Red Hat
Intended status: Standards Track H. Tschofenig, Ed. Intended status: Standards Track H. Tschofenig, Ed.
Expires: January 17, 2014 Nokia Siemens Networks Expires: January 31, 2014 Nokia Siemens Networks
J. Gilmore J. Gilmore
S. Weiler S. Weiler
SPARTA, Inc. SPARTA, Inc.
T. Kivinen T. Kivinen
AuthenTec AuthenTec
July 16, 2013 July 30, 2013
Out-of-Band Public Key Validation for Transport Layer Security (TLS) Out-of-Band Public Key Validation for Transport Layer Security (TLS)
draft-ietf-tls-oob-pubkey-08.txt draft-ietf-tls-oob-pubkey-09.txt
Abstract Abstract
This document specifies a new certificate type and two TLS This document specifies a new certificate type and two TLS
extensions, one for the client and one for the server, for exchanging extensions, one for the client and one for the server, for exchanging
raw public keys in Transport Layer Security (TLS) and Datagram raw public keys in Transport Layer Security (TLS) and Datagram
Transport Layer Security (DTLS) for use with out-of-band public key Transport Layer Security (DTLS) for use with out-of-band public key
validation. validation.
Status of This Memo Status of This Memo
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 January 17, 2014. This Internet-Draft will expire on January 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. New TLS Extension . . . . . . . . . . . . . . . . . . . . . . 3 3. New TLS Extension . . . . . . . . . . . . . . . . . . . . . . 3
4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 7 4. TLS Handshake Extension . . . . . . . . . . . . . . . . . . . 7
4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . 7
4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 7 4.3. Certificate Request . . . . . . . . . . . . . . . . . . . 7
4.4. Other Handshake Messages . . . . . . . . . . . . . . . . 7 4.4. Other Handshake Messages . . . . . . . . . . . . . . . . 8
4.5. Client authentication . . . . . . . . . . . . . . . . . . 8 4.5. Client authentication . . . . . . . . . . . . . . . . . . 8
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 13 Appendix A. Example Encoding . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Traditionally, TLS client and server public keys are obtained in PKIX Traditionally, TLS client and server public keys are obtained in PKIX
containers in-band using the TLS handshake and validated using trust containers in-band using the TLS handshake and validated using trust
skipping to change at page 4, line 38 skipping to change at page 4, line 38
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING } subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL } parameters ANY DEFINED BY algorithm OPTIONAL }
Figure 2: SubjectPublicKeyInfo ASN.1 Structure. Figure 2: SubjectPublicKeyInfo ASN.1 Structure.
The algorithm identifiers are Object Identifiers (OIDs). RFC 3279 The algorithm identifiers are Object Identifiers (OIDs). RFC 3279
[RFC3279] and [RFC5480] define the following OIDs shown in Figure 3. [RFC3279] and [RFC5480], for example, define the following OIDs shown
in Figure 3. Note that this list is not exhaustive and more OIDs may
be defined in future RFCs. RFC 5480 also defines a number of OIDs.
Key Type | Document | OID Key Type | Document | OID
-----------------------+----------------------------+------------------- -----------------------+----------------------------+-------------------
RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1 RSA | Section 2.3.1 of RFC 3279 | 1.2.840.113549.1.1
.......................|............................|................... .......................|............................|...................
Digital Signature | | Digital Signature | |
Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1 Algorithm (DSS) | Section 2.3.2 of RFC 3279 | 1.2.840.10040.4.1
.......................|............................|................... .......................|............................|...................
Elliptic Curve | | Elliptic Curve | |
Digital Signature | | Digital Signature | |
Algorithm (ECDSA) | Section 2.3.5 of RFC 5480 | 1.2.840.10045.2.1 Algorithm (ECDSA) | Section 2 of RFC 5480 | 1.2.840.10045.2.1
-----------------------+----------------------------+------------------- -----------------------+----------------------------+-------------------
Figure 3: Example Algorithm Object Identifiers. Figure 3: Example Algorithm Object Identifiers.
The message exchange in Figure 4 shows the 'client_certificate_type' The message exchange in Figure 4 shows the 'client_certificate_type'
and 'server_certificate_type' extensions added to the client and and 'server_certificate_type' extensions added to the client and
server hello messages. server hello messages.
client_hello, client_hello,
client_certificate_type client_certificate_type
skipping to change at page 11, line 4 skipping to change at page 11, line 12
procedures for associating the public key with the possession of a procedures for associating the public key with the possession of a
private key also follows standard procedures. private key also follows standard procedures.
The main security challenge is, however, how to associate the public The main security challenge is, however, how to associate the public
key with a specific entity. Without a secure binding between key with a specific entity. Without a secure binding between
identity and key the protocol will be vulnerable to masquerade and identity and key the protocol will be vulnerable to masquerade and
man-in-the-middle attacks. This document assumes that such binding man-in-the-middle attacks. This document assumes that such binding
can be made out-of-band and we list a few examples in Section 1. can be made out-of-band and we list a few examples in Section 1.
DANE [RFC6698] offers one such approach. In order to address these DANE [RFC6698] offers one such approach. In order to address these
vulnerabilities, specifications that make use of the extension MUST vulnerabilities, specifications that make use of the extension MUST
specify how the identity and public key are bound. If public keys specify how the identity and public key are bound. In addition to
are obtained using DANE, these public keys are authenticated via ensuring the binding is done out-of-band an implementation also needs
DNSSEC. Pre-configured keys is another out of band method for to check the status of that binding.
authenticating raw public keys. While pre-configured keys are not
suitable for a generic Web-based e-commerce environment such keys are If public keys are obtained using DANE, these public keys are
a reasonable approach for many smart object deployments where there authenticated via DNSSEC. Pre-configured keys is another out of band
is a close relationship between the software running on the device method for authenticating raw public keys. While pre-configured keys
and the server-side communication endpoint. Regardless of the chosen are not suitable for a generic Web-based e-commerce environment such
mechanism for out-of-band public key validation an assessment of the keys are a reasonable approach for many smart object deployments
most suitable approach has to be made prior to the start of a where there is a close relationship between the software running on
deployment to ensure the security of the system. the device and the server-side communication endpoint. Regardless of
the chosen mechanism for out-of-band public key validation an
assessment of the most suitable approach has to be made prior to the
start of a deployment to ensure the security of the system.
7. IANA Considerations 7. IANA Considerations
IANA is asked to register a new value in the "TLS Certificate Types" IANA is asked to register a new value in the "TLS Certificate Types"
registry of Transport Layer Security (TLS) Extensions registry of Transport Layer Security (TLS) Extensions
[TLS-Certificate-Types-Registry], as follows: [TLS-Certificate-Types-Registry], as follows:
Value: 2 Value: 2
Description: Raw Public Key Description: Raw Public Key
Reference: [[THIS RFC]] Reference: [[THIS RFC]]
skipping to change at page 11, line 47 skipping to change at page 12, line 18
substantially shaped the document and we would like to thank the substantially shaped the document and we would like to thank the
meeting participants for their input. The support for hashes of meeting participants for their input. The support for hashes of
public keys has been moved to [I-D.ietf-tls-cached-info] after the public keys has been moved to [I-D.ietf-tls-cached-info] after the
discussions at the IETF#82 meeting. discussions at the IETF#82 meeting.
We would like to thank the following persons for their review We would like to thank the following persons for their review
comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann, comments: Martin Rex, Bill Frantz, Zach Shelby, Carsten Bormann,
Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba, Cullen Jennings, Rene Struik, Alper Yegin, Jim Schaad, Barry Leiba,
Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John Paul Hoffman, Robert Cragie, Nikos Mavrogiannopoulos, Phil Hunt, John
Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn Bradley, Klaus Hartke, Stefan Jucker, Kovatsch Matthias, Daniel Kahn
Gillmor, Peter Sylvester, and James Manger. Nikos Mavrogiannopoulos Gillmor, Peter Sylvester, Hauke Mehrtens, and James Manger. Nikos
contributed the design for re-using the certificate type registry. Mavrogiannopoulos contributed the design for re-using the certificate
type registry. Barry Leiba contributed guidance for the IANA
Barry Leiba contributed guidance for the IANA consideration text. consideration text. Stefan Jucker, Kovatsch Matthias, and Klaus
Stefan Jucker, Kovatsch Matthias, and Klaus Hartke provided Hartke provided implementation feedback regarding the
implementation feedback regarding the SubjectPublicKeyInfo structure. SubjectPublicKeyInfo structure.
We would like to thank our TLS working group chairs, Eric Rescorla We would like to thank our TLS working group chairs, Eric Rescorla
and Joe Salowey, for their guidance and support. Finally, we would and Joe Salowey, for their guidance and support. Finally, we would
like to thank Sean Turner, who is the responsible security area like to thank Sean Turner, who is the responsible security area
director for this work for his review comments and suggestions. director for this work for his review comments and suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
 End of changes. 10 change blocks. 
25 lines changed or deleted 30 lines changed or added

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