idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5081]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC5081, but the abstract doesn't seem to directly say this. It does mention RFC5081 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 16, 2010) is 4964 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-tls-rfc4366-bis-10 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5081 (Obsoleted by RFC 6091) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Mavrogiannopoulos 3 Internet-Draft KUL 4 Obsoletes: 5081 (if approved) D. Gillmor 5 Intended status: Informational Independent 6 Expires: March 20, 2011 September 16, 2010 8 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 9 draft-mavrogiannopoulos-rfc5081bis-08 11 Abstract 13 This memo proposes extensions to the Transport Layer Security (TLS) 14 protocol to support the OpenPGP key format. The extensions discussed 15 here include a certificate type negotiation mechanism, and the 16 required modifications to the TLS Handshake Protocol. This memo 17 replaces the Experimental [RFC5081]. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 20, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 56 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 59 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 60 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 6 61 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 7 62 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 64 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 67 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 68 Appendix A. Changes from RFC 5081 . . . . . . . . . . . . . . . . 9 70 1. Introduction 72 The IETF has two sets of standards for public key certificates, one 73 set for use of X.509 certificates [RFC5280] and one for OpenPGP 74 certificates [RFC4880]. At the time of writing, TLS [RFC5246] 75 standards are defined to use X.509 certificates. This document 76 specifies a way to negotiate use of OpenPGP certificates for a TLS 77 session, and specifies how to transport OpenPGP certificates via TLS. 78 The proposed extensions are backward compatible with the current TLS 79 specification, so that existing client and server implementations 80 that make use of X.509 certificates are not affected. 82 The major changes from [RFC5081] are summarized in Appendix A. 84 2. Terminology 86 The term "OpenPGP key" is used in this document as in the OpenPGP 87 specification [RFC4880]. We use the term "OpenPGP certificate" to 88 refer to OpenPGP keys that are enabled for authentication. 90 This document uses the same notation and terminology used in the TLS 91 Protocol specification [RFC5246]. 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 3. Changes to the Handshake Message Contents 99 This section describes the changes to the TLS handshake message 100 contents when OpenPGP certificates are to be used for authentication. 102 3.1. Client Hello 104 In order to indicate the support of multiple certificate types, 105 clients MUST include an extension of type "cert_type" to the extended 106 client hello message. The "cert_type" TLS extension is assigned the 107 value of 9 from the TLS ExtensionType registry. This value is used 108 as the extension number for the extensions in both the client hello 109 message and the server hello message. The hello extension mechanism 110 is described in [RFC5246]. 112 This extension carries a list of supported certificate types the 113 client can use, sorted by client preference. This extension MUST be 114 omitted if the client only supports X.509 certificates. The 115 "extension_data" field of this extension contains a 116 CertificateTypeExtension structure. Note that the 117 CertificateTypeExtension structure is being used both by the client 118 and the server, although specified once in this document, a practice 119 common in the TLS protocol specification [RFC5246]. 121 enum { client, server } ClientOrServerExtension; 123 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 125 struct { 126 select(ClientOrServerExtension) { 127 case client: 128 CertificateType certificate_types<1..2^8-1>; 129 case server: 130 CertificateType certificate_type; 131 } 132 } CertificateTypeExtension; 134 No new cipher suites are required to use OpenPGP certificates. All 135 existing cipher suites that support a key exchange method compatible 136 with the key in the certificate can be used in combination with 137 OpenPGP certificates. 139 3.2. Server Hello 141 If the server receives a client hello that contains the "cert_type" 142 extension and chooses a cipher suite that requires a certificate, 143 then two outcomes are possible. The server MUST either select a 144 certificate type from the certificate_types field in the extended 145 client hello or terminate the session with a fatal alert of type 146 "unsupported_certificate". 148 The certificate type selected by the server is encoded in a 149 CertificateTypeExtension structure, which is included in the extended 150 server hello message using an extension of type "cert_type". Servers 151 that only support X.509 certificates MAY omit including the 152 "cert_type" extension in the extended server hello. 154 3.3. Server Certificate 156 The contents of the certificate message sent from server to client 157 and vice versa are determined by the negotiated certificate type and 158 the selected cipher suite's key exchange algorithm. 160 If the OpenPGP certificate type is negotiated, then it is required to 161 present an OpenPGP certificate in the certificate message. The 162 certificate must contain a public key that matches the selected key 163 exchange algorithm, as shown below. 165 Key Exchange Algorithm OpenPGP Certificate Type 167 RSA RSA public key that can be used for 168 encryption. 170 DHE_DSS DSA public key that can be used for 171 authentication. 173 DHE_RSA RSA public key that can be used for 174 authentication. 176 An OpenPGP certificate appearing in the certificate message is sent 177 using the binary OpenPGP format. The certificate MUST contain all 178 the elements required by Section 11.1 of [RFC4880]. 180 OpenPGP certificates to be transferred are placed in the Certificate 181 structure and tagged with the OpenPGPCertDescriptorType 182 "subkey_cert". Since those certificates might contain several 183 subkeys the subkey ID to be used for this session is explicitely 184 specified in the OpenPGPKeyID field. The key ID must be specified 185 even if the certificate has only a primary key. The peer once 186 receiving this type has to either use the specified subkey or 187 terminate the session with a fatal alert of 188 "unsupported_certificate". 190 The option is also available to send an OpenPGP fingerprint, instead 191 of sending the entire certificate, by using the 192 "subkey_cert_fingerprint" tag. This tag uses the 193 OpenPGPSubKeyFingerprint structure and requires the primary key 194 fingerprint to be specified, as well as the subkey ID to be used for 195 this session. The peer shall respond with a 196 "certificate_unobtainable" fatal alert if the certificate with the 197 given fingerprint cannot be found. The "certificate_unobtainable" 198 fatal alert is defined in Section 5 of [I-D.ietf-tls-rfc4366-bis]. 200 Implementations of this protocol MUST ensure that the sizes, of key 201 IDs and fingerprints, in the OpenPGPSubKeyCert and 202 OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover 203 it is RECOMMENDED that the keys to be used with this protocol have 204 the authentication flag (0x20) set. 206 The process of fingerprint generation is described in Section 12.2 of 207 [RFC4880]. 209 The enumerated types "cert_fingerprint" and "cert" of 210 OpenPGPCertDescriptorType that were defined in [RFC5081] are not used 211 and are marked as obsolete by this document. The "empty_cert" type 212 has replaced "cert" and is a backwards compatible way to specify an 213 empty certificate; cert_fingerprint" MUST NOT be used with this 214 updated specification, and hence that old alternative has been 215 removed from the Certificate struct description. 217 enum { 218 empty_cert(1), 219 subkey_cert(2), 220 subkey_cert_fingerprint(3), 221 (255) 222 } OpenPGPCertDescriptorType; 224 uint24 OpenPGPEmptyCert = 0; 226 struct { 227 opaque OpenPGPKeyID<8..255>; 228 opaque OpenPGPCert<0..2^24-1>; 229 } OpenPGPSubKeyCert; 231 struct { 232 opaque OpenPGPKeyID<8..255>; 233 opaque OpenPGPCertFingerprint<20..255>; 234 } OpenPGPSubKeyFingerprint; 236 struct { 237 OpenPGPCertDescriptorType descriptorType; 238 select (descriptorType) { 239 case empty_cert: OpenPGPEmptyCert; 240 case subkey_cert: OpenPGPSubKeyCert; 241 case subkey_cert_fingerprint: 242 OpenPGPSubKeyCertFingerprint; 243 } 244 } Certificate; 246 3.4. Certificate Request 248 The semantics of this message remain the same as in the TLS 249 specification. However, if this message is sent, and the negotiated 250 certificate type is OpenPGP, the "certificate_authorities" list MUST 251 be empty. 253 3.5. Client Certificate 255 This message is only sent in response to the certificate request 256 message. The client certificate message is sent using the same 257 formatting as the server certificate message, and it is also required 258 to present a certificate that matches the negotiated certificate 259 type. If OpenPGP certificates have been selected and no certificate 260 is available from the client, then a certificate structure of type 261 "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. 262 The server SHOULD respond with a "handshake_failure" fatal alert if 263 client authentication is required. 265 3.6. Other Handshake Messages 267 All the other handshake messages are identical to the TLS 268 specification. 270 4. Security Considerations 272 All security considerations discussed in [RFC5246], 273 [I-D.ietf-tls-rfc4366-bis], and [RFC4880] apply to this document. 274 Considerations about the use of the web of trust or identity and 275 certificate verification procedure are outside the scope of this 276 document. These are considered issues to be handled by the 277 application layer protocols. 279 The protocol for certificate type negotiation is identical in 280 operation to ciphersuite negotiation of the [RFC5246] specification 281 with the addition of default values when the extension is omitted. 282 Since those omissions have a unique meaning and the same protection 283 is applied to the values as with ciphersuites, it is believed that 284 the security properties of this negotiation are the same as with 285 ciphersuite negotiation. 287 When using OpenPGP fingerprints instead of the full certificates, the 288 discussion in Section 6.3 of [I-D.ietf-tls-rfc4366-bis] for "Client 289 Certificate URLs" applies, especially when external servers are used 290 to retrieve keys. However, a major difference is that although the 291 "client_certificate_url" extension allows identifying certificates 292 without including the certificate hashes, this is not possible in the 293 protocol proposed here. In this protocol, the certificates, when not 294 sent, are always identified by their fingerprint, which serves as a 295 cryptographic hash of the certificate (see Section 12.2 of 296 [RFC4880]). 298 The information that is available to participating parties and 299 eavesdroppers (when confidentiality is not available through a 300 previous handshake) is the number and the types of certificates they 301 hold, plus the contents of certificates. 303 5. IANA Considerations 305 This document uses a registry and the "cert_type" extension 306 originally defined in [RFC5081]. Existing IANA references should be 307 updated to point to this document. 309 In addition the "TLS Certificate Types" registry established by 310 [RFC5081] has to be updated in the following way: 312 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 314 2. Values from 2 through 223 decimal inclusive are assigned via "RFC 315 Required" [RFC5226]. 317 3. Values from 224 decimal through 255 decimal inclusive are 318 reserved for Private Use [RFC5226]. 320 6. Acknowledgements 322 The authors wish to thank Alfred Hoenes and Ted Hardie for their 323 suggestions on improving this document. 325 7. References 327 7.1. Normative References 329 [RFC2119] Bradner, S., "Key words for use in RFCs 330 to Indicate Requirement Levels", BCP 14, 331 RFC 2119, March 1997. 333 [I-D.ietf-tls-rfc4366-bis] 3rd, D., "Transport Layer Security (TLS) 334 Extensions: Extension Definitions", 335 draft-ietf-tls-rfc4366-bis-10 (work in 336 progress), July 2010. 338 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., 339 Shaw, D., and R. Thayer, "OpenPGP Message 340 Format", RFC 4880, November 2007. 342 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines 343 for Writing an IANA Considerations 344 Section in RFCs", BCP 26, RFC 5226, 345 May 2008. 347 [RFC5246] Dierks, T. and E. Rescorla, "The 348 Transport Layer Security (TLS) Protocol 349 Version 1.2", RFC 5246, August 2008. 351 7.2. Informative References 353 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP 354 Keys for Transport Layer Security (TLS) 355 Authentication", RFC 5081, November 2007. 357 [RFC5280] Cooper, D., Santesson, S., Farrell, S., 358 Boeyen, S., Housley, R., and W. Polk, 359 "Internet X.509 Public Key Infrastructure 360 Certificate and Certificate Revocation 361 List (CRL) Profile", RFC 5280, May 2008. 363 Appendix A. Changes from RFC 5081 365 This document incorporates a major change in the "Server Certificate" 366 and "Client Certificate" TLS messages, that will make implementations 367 following this protocol incompatible with ones following [RFC5081]. 368 This change requires the subkey IDs used for TLS authentication to 369 marked explicitely in the handshake procedure. This was decided in 370 order to place no limitation on the OpenPGP certificates' contents 371 that can be used with with this protocol. 373 [RFC5081] required that an OpenPGP key or subkey was marked with the 374 authentication flag and thus would have failed if this flag was not 375 set, or this flag was set in more than one subkeys. The protocol in 376 this memo has no such limitation. 378 Authors' Addresses 380 Nikos Mavrogiannopoulos 381 ESAT/COSIC Katholieke Universiteit Leuven 382 Kasteelpark Arenberg 10, bus 2446 383 Leuven-Heverlee, B-3001 384 Belgium 386 EMail: nikos.mavrogiannopoulos@esat.kuleuven.be 388 Daniel Kahn Gillmor 389 Independent 390 119 Herkimer St 391 Brooklyn, NY 11216-2801 392 US 394 EMail: dkg@fifthhorseman.net