idnits 2.17.1 draft-mavrogiannopoulos-rfc5081bis-05.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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. 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 (July 23, 2010) is 5019 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4366 (Obsoleted by RFC 5246, RFC 6066) ** 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: rfc5081 D. Gillmor 5 (if approved) Independent 6 Intended status: Informational July 23, 2010 7 Expires: January 24, 2011 9 Using OpenPGP Keys for Transport Layer Security (TLS) Authentication 10 draft-mavrogiannopoulos-rfc5081bis-05 12 Abstract 14 This memo proposes extensions to the Transport Layer Security (TLS) 15 protocol to support the OpenPGP key format. The extensions discussed 16 here include a certificate type negotiation mechanism, and the 17 required modifications to the TLS Handshake Protocol. This memo 18 replaces the Experimental [RFC5081]. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 24, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Changes to the Handshake Message Contents . . . . . . . . . . . 3 57 3.1. Client Hello . . . . . . . . . . . . . . . . . . . . . . . 3 58 3.2. Server Hello . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.3. Server Certificate . . . . . . . . . . . . . . . . . . . . 4 60 3.4. Certificate Request . . . . . . . . . . . . . . . . . . . . 6 61 3.5. Client Certificate . . . . . . . . . . . . . . . . . . . . 7 62 3.6. Other Handshake Messages . . . . . . . . . . . . . . . . . 7 63 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 66 Appendix A. Changes from RFC 5081 . . . . . . . . . . . . . . . . 8 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 The IETF has two sets of standards for public key certificates, one 74 set for use of X.509 certificates [RFC5280] and one for OpenPGP 75 certificates [RFC4880]. At the time of writing, TLS [RFC5246] 76 standards are defined to use X.509 certificates. This document 77 specifies a way to negotiate use of OpenPGP certificates for a TLS 78 session, and specifies how to transport OpenPGP certificates via TLS. 79 The proposed extensions are backward compatible with the current TLS 80 specification, so that existing client and server implementations 81 that make use of X.509 certificates are not affected. 83 The major changes from [RFC5081] are summarized in Appendix A. 85 2. Terminology 87 The term "OpenPGP key" is used in this document as in the OpenPGP 88 specification [RFC4880]. We use the term "OpenPGP certificate" to 89 refer to OpenPGP keys that are enabled for authentication. 91 This document uses the same notation and terminology used in the TLS 92 Protocol specification [RFC5246]. 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. Changes to the Handshake Message Contents 100 This section describes the changes to the TLS handshake message 101 contents when OpenPGP certificates are to be used for authentication. 103 3.1. Client Hello 105 In order to indicate the support of multiple certificate types, 106 clients MUST include an extension of type "cert_type" to the extended 107 client hello message. The "cert_type" TLS extension is assigned the 108 value of 9 from the TLS ExtensionType registry. This value is used 109 as the extension number for the extensions in both the client hello 110 message and the server hello message. The hello extension mechanism 111 is described in [RFC4366]. 113 This extension carries a list of supported certificate types the 114 client can use, sorted by client preference. This extension MUST be 115 omitted if the client only supports X.509 certificates. The 116 "extension_data" field of this extension contains a 117 CertificateTypeExtension structure. Note that the 118 CertificateTypeExtension structure is being used both by the client 119 and the server, although specified once in this document, a practice 120 common in the TLS protocol specification [RFC5246]. 122 enum { client, server } ClientOrServerExtension; 124 enum { X.509(0), OpenPGP(1), (255) } CertificateType; 126 struct { 127 select(ClientOrServerExtension) { 128 case client: 129 CertificateType certificate_types<1..2^8-1>; 130 case server: 131 CertificateType certificate_type; 132 } 133 } CertificateTypeExtension; 135 No new cipher suites are required to use OpenPGP certificates. All 136 existing cipher suites that support a key exchange method compatible 137 with the key in the certificate can be used in combination with 138 OpenPGP certificates. 140 3.2. Server Hello 142 If the server receives a client hello that contains the "cert_type" 143 extension and chooses a cipher suite that requires a certificate, 144 then two outcomes are possible. The server MUST either select a 145 certificate type from the certificate_types field in the extended 146 client hello or terminate the session with a fatal alert of type 147 "unsupported_certificate". 149 The certificate type selected by the server is encoded in a 150 CertificateTypeExtension structure, which is included in the extended 151 server hello message using an extension of type "cert_type". Servers 152 that only support X.509 certificates MAY omit including the 153 "cert_type" extension in the extended server hello. 155 It is perfectly legal for a server to ignore this message. In that 156 case the normal TLS handshake should be used and, other certificate 157 types than the default MUST NOT be used. 159 3.3. Server Certificate 161 The contents of the certificate message sent from server to client 162 and vice versa are determined by the negotiated certificate type and 163 the selected cipher suite's key exchange algorithm. 165 If the OpenPGP certificate type is negotiated, then it is required to 166 present an OpenPGP certificate in the certificate message. The 167 certificate must contain a public key that matches the selected key 168 exchange algorithm, as shown below. 170 Key Exchange Algorithm OpenPGP Certificate Type 172 RSA RSA public key that can be used for 173 encryption. 175 DHE_DSS DSA public key that can be used for 176 authentication. 178 DHE_RSA RSA public key that can be used for 179 authentication. 181 An OpenPGP certificate appearing in the certificate message is sent 182 using the binary OpenPGP format. The certificate MUST contain all 183 the elements required by Section 11.1 of [RFC4880]. 185 OpenPGP certificates to be transferred are placed in the Certificate 186 structure and tagged with the OpenPGPCertDescriptorType 187 "subkey_cert". Since those certificates might contain several 188 subkeys the subkey ID to be used for this session is explicitely 189 specified in the OpenPGPKeyID field. The key ID must be specified 190 even if the certificate has only a primary key. The peer once 191 receiving this type has to either use the specified subkey or 192 terminate the session with a fatal alert of 193 "unsupported_certificate". 195 The option is also available to send an OpenPGP fingerprint, instead 196 of sending the entire certificate, by using the 197 "subkey_cert_fingerprint" tag. This tag uses the 198 OpenPGPSubKeyFingerprint structure and requires the primary key 199 fingerprint to be specified, as well as the subkey ID to be used for 200 this session. The peer shall respond with a 201 "certificate_unobtainable" fatal alert if the certificate with the 202 given fingerprint cannot be found. The "certificate_unobtainable" 203 fatal alert is defined in Section 4 of [RFC4366]. 205 Implementations of this protocol MUST ensure that the sizes, of key 206 IDs and fingerprints, in the OpenPGPSubKeyCert and 207 OpenPGPSubKeyFingerprint structures comply with [RFC4880]. Moreover 208 it is RECOMMENDED that the keys to be used with this protocol have 209 the authentication flag (0x20) set. 211 The process of fingerprint generation is described in Section 12.2 of 212 [RFC4880]. 214 The enumerated types "cert_fingerprint" and "cert" of 215 OpenPGPCertDescriptorType that were defined in [RFC5081] are not used 216 and are marked as obsolete by this document. The "empty_cert" type 217 has replaced "cert" and is a backwards compatible way to specify an 218 empty certificate; cert_fingerprint" MUST NOT be used with this 219 updated specification, and hence that old alternative has been 220 removed from the Certificate struct description. 222 enum { 223 empty_cert(1), 224 subkey_cert(2), 225 subkey_cert_fingerprint(3), 226 (255) 227 } OpenPGPCertDescriptorType; 229 uint24 OpenPGPEmptyCert = 0; 231 struct { 232 opaque OpenPGPKeyID<8..255>; 233 opaque OpenPGPCert<0..2^24-1>; 234 } OpenPGPSubKeyCert; 236 struct { 237 opaque OpenPGPKeyID<8..255>; 238 opaque OpenPGPCertFingerprint<20..255>; 239 } OpenPGPSubKeyFingerprint; 241 struct { 242 OpenPGPCertDescriptorType descriptorType; 243 select (descriptorType) { 244 case empty_cert: OpenPGPEmptyCert; 245 case subkey_cert: OpenPGPSubKeyCert; 246 case subkey_cert_fingerprint: 247 OpenPGPSubKeyCertFingerprint; 248 } 249 } Certificate; 251 3.4. Certificate Request 253 The semantics of this message remain the same as in the TLS 254 specification. However, if this message is sent, and the negotiated 255 certificate type is OpenPGP, the "certificate_authorities" list MUST 256 be empty. 258 3.5. Client Certificate 260 This message is only sent in response to the certificate request 261 message. The client certificate message is sent using the same 262 formatting as the server certificate message, and it is also required 263 to present a certificate that matches the negotiated certificate 264 type. If OpenPGP certificates have been selected and no certificate 265 is available from the client, then a certificate structure of type 266 "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. 267 The server SHOULD respond with a "handshake_failure" fatal alert if 268 client authentication is required. 270 3.6. Other Handshake Messages 272 All the other handshake messages are identical to the TLS 273 specification. 275 4. Security Considerations 277 All security considerations discussed in [RFC5246], [RFC4366], and 278 [RFC4880] apply to this document. Considerations about the use of 279 the web of trust or identity and certificate verification procedure 280 are outside the scope of this document. These are considered issues 281 to be handled by the application layer protocols. 283 The protocol for certificate type negotiation is identical in 284 operation to ciphersuite negotiation of the [RFC5246] specification 285 with the addition of default values when the extension is omitted. 286 Since those omissions have a unique meaning and the same protection 287 is applied to the values as with ciphersuites, it is believed that 288 the security properties of this negotiation are the same as with 289 ciphersuite negotiation. 291 When using OpenPGP fingerprints instead of the full certificates, the 292 discussion in Section 6.3 of [RFC4366] for "Client Certificate URLs" 293 applies, especially when external servers are used to retrieve keys. 294 However, a major difference is that although the 295 "client_certificate_url" extension allows identifying certificates 296 without including the certificate hashes, this is not possible in the 297 protocol proposed here. In this protocol, the certificates, when not 298 sent, are always identified by their fingerprint, which serves as a 299 cryptographic hash of the certificate (see Section 12.2 of 300 [RFC4880]). 302 The information that is available to participating parties and 303 eavesdroppers (when confidentiality is not available through a 304 previous handshake) is the number and the types of certificates they 305 hold, plus the contents of certificates. 307 5. IANA Considerations 309 This document uses a registry originally defined in [RFC5081]. 310 Existing IANA references should be updated to point to this document. 312 In addition the "TLS Certificate Types" registry established by 313 [RFC5081] has to be updated in the following way: 315 1. Values 0 (X.509) and 1 (OpenPGP) are defined in this document. 317 2. Values from 2 through 223 decimal inclusive are assigned via "RFC 318 Required" [RFC5226]. 320 3. Values from 224 decimal through 255 decimal inclusive are 321 reserved for Private Use [RFC5226]. 323 6. Acknowledgements 325 The authors wish to thank Alfred Hoenes for their suggestions on 326 improving this document. 328 Appendix A. Changes from RFC 5081 330 This document incorporates a major and incompatible change in the 331 "Server Certificate" and "Client Certificate" TLS messages. This 332 change requires the subkey IDs used for TLS authentication to marked 333 explicitely in the handshake procedure. This was decided in order to 334 place no limitation on the OpenPGP certificates' contents that can be 335 used with with this protocol. 337 [RFC5081] required that an OpenPGP key or subkey was marked with the 338 authentication flag and thus would have failed if this flag was not 339 set, or this flag was set in more than one subkeys. The protocol in 340 this memo has no such limitation. 342 7. References 344 7.1. Normative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., 350 and T. Wright, "Transport Layer Security (TLS) 351 Extensions", RFC 4366, April 2006. 353 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 354 Thayer, "OpenPGP Message Format", RFC 4880, November 2007. 356 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 357 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 358 May 2008. 360 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 361 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 363 7.2. Informative References 365 [RFC5081] Mavrogiannopoulos, N., "Using OpenPGP Keys for Transport 366 Layer Security (TLS) Authentication", RFC 5081, 367 November 2007. 369 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 370 Housley, R., and W. Polk, "Internet X.509 Public Key 371 Infrastructure Certificate and Certificate Revocation List 372 (CRL) Profile", RFC 5280, May 2008. 374 Authors' Addresses 376 Nikos Mavrogiannopoulos 377 ESAT/COSIC Katholieke Universiteit Leuven 378 Kasteelpark Arenberg 10, bus 2446 379 Leuven-Heverlee, B-3001 380 Belgium 382 EMail: nikos.mavrogiannopoulos@esat.kuleuven.be 384 Daniel Kahn Gillmor 385 Independent 386 119 Herkimer St 387 Brooklyn, NY 11216-2801 388 US 390 EMail: dkg@fifthhorseman.net