doc/protocol/draft-mavrogiannopoulos-rfc5081bis-00.txt

   1
   2
   3
   4 Network Working Group                               N. Mavrogiannopoulos
   5 Internet-Draft                                               Independent
   6 Updates: rfc5081                                            January 2008
   7 (if approved)
   8 Intended status: Informational
   9 Expires: July 4, 2008
  10
  11
  12   Using OpenPGP Keys for Transport Layer Security (TLS) Authentication
  13                  draft-mavrogiannopoulos-rfc5081bis-00
  14
  15 Status of This Memo
  16
  17    By submitting this Internet-Draft, each author represents that any
  18    applicable patent or other IPR claims of which he or she is aware
  19    have been or will be disclosed, and any of which he or she becomes
  20    aware will be disclosed, in accordance with Section 6 of BCP 79.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as Internet-
  25    Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt.
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html.
  37
  38    This Internet-Draft will expire on July 4, 2008.
  39
  40 Copyright Notice
  41
  42    Copyright (C) The IETF Trust (2008).
  43
  44 Abstract
  45
  46    This memo proposes extensions to the Transport Layer Security (TLS)
  47    protocol to support the OpenPGP key format.  The extensions discussed
  48    here include a certificate type negotiation mechanism, and the
  49    required modifications to the TLS Handshake Protocol.
  50
  51
  52
  53
  54
  55 Mavrogiannopoulos         Expires July 4, 2008                  [Page 1]
  56 \f
  57 Internet-Draft             Using OpenPGP Keys               January 2008
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  64    3.  Changes to the Handshake Message Contents . . . . . . . . . . . 3
  65      3.1.  Client Hello  . . . . . . . . . . . . . . . . . . . . . . . 3
  66      3.2.  Server Hello  . . . . . . . . . . . . . . . . . . . . . . . 4
  67      3.3.  Server Certificate  . . . . . . . . . . . . . . . . . . . . 4
  68      3.4.  Certificate Request . . . . . . . . . . . . . . . . . . . . 6
  69      3.5.  Client Certificate  . . . . . . . . . . . . . . . . . . . . 6
  70      3.6.  Other Handshake Messages  . . . . . . . . . . . . . . . . . 6
  71    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  72    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
  73    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
  74    7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  75      7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  76      7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Mavrogiannopoulos         Expires July 4, 2008                  [Page 2]
 112 \f
 113 Internet-Draft             Using OpenPGP Keys               January 2008
 114
 115
 116 1.  Introduction
 117
 118    The IETF has two sets of standards for public key certificates, one
 119    set for use of X.509 certificates [PKIX] and one for OpenPGP
 120    certificates [OpenPGP].  At the time of writing, TLS [TLS] standards
 121    are defined to use only X.509 certificates.  This document specifies
 122    a way to negotiate use of OpenPGP certificates for a TLS session, and
 123    specifies how to transport OpenPGP certificates via TLS.  The
 124    proposed extensions are backward compatible with the current TLS
 125    specification, so that existing client and server implementations
 126    that make use of X.509 certificates are not affected.
 127
 128 2.  Terminology
 129
 130    The term "OpenPGP key" is used in this document as in the OpenPGP
 131    specification [OpenPGP].  We use the term "OpenPGP certificate" to
 132    refer to OpenPGP keys that are enabled for authentication.
 133
 134    This document uses the same notation and terminology used in the TLS
 135    Protocol specification [TLS].
 136
 137    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 138    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 139    document are to be interpreted as described in [RFC2119].
 140
 141 3.  Changes to the Handshake Message Contents
 142
 143    This section describes the changes to the TLS handshake message
 144    contents when OpenPGP certificates are to be used for authentication.
 145
 146 3.1.  Client Hello
 147
 148    In order to indicate the support of multiple certificate types,
 149    clients MUST include an extension of type "cert_type" (see Section 5)
 150    to the extended client hello message.  The hello extension mechanism
 151    is described in [TLSEXT].
 152
 153    This extension carries a list of supported certificate types the
 154    client can use, sorted by client preference.  This extension MUST be
 155    omitted if the client only supports X.509 certificates.  The
 156    "extension_data" field of this extension contains a
 157    CertificateTypeExtension structure.
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Mavrogiannopoulos         Expires July 4, 2008                  [Page 3]
 168 \f
 169 Internet-Draft             Using OpenPGP Keys               January 2008
 170
 171
 172       enum { client, server } ClientOrServerExtension;
 173
 174       enum { X.509(0), OpenPGP(1), (255) } CertificateType;
 175
 176       struct {
 177          select(ClientOrServerExtension) {
 178             case client:
 179                CertificateType certificate_types<1..2^8-1>;
 180             case server:
 181                CertificateType certificate_type;
 182          }
 183       } CertificateTypeExtension;
 184
 185    No new cipher suites are required to use OpenPGP certificates.  All
 186    existing cipher suites that support a compatible, with the key, key
 187    exchange method can be used in combination with OpenPGP certificates.
 188
 189 3.2.  Server Hello
 190
 191    If the server receives a client hello that contains the "cert_type"
 192    extension and chooses a cipher suite that requires a certificate,
 193    then two outcomes are possible.  The server MUST either select a
 194    certificate type from the certificate_types field in the extended
 195    client hello or terminate the connection with a fatal alert of type
 196    "unsupported_certificate".
 197
 198    The certificate type selected by the server is encoded in a
 199    CertificateTypeExtension structure, which is included in the extended
 200    server hello message using an extension of type "cert_type".  Servers
 201    that only support X.509 certificates MAY omit including the
 202    "cert_type" extension in the extended server hello.
 203
 204    It is perfectly legal for a server to ignore this message.  In that
 205    case the normal TLS handshake should be used.  Other certificate
 206    types than the default MUST NOT be used.
 207
 208 3.3.  Server Certificate
 209
 210    The contents of the certificate message sent from server to client
 211    and vice versa are determined by the negotiated certificate type and
 212    the selected cipher suite's key exchange algorithm.
 213
 214    If the OpenPGP certificate type is negotiated, then it is required to
 215    present an OpenPGP certificate in the certificate message.  The
 216    certificate must contain a public key that matches the selected key
 217    exchange algorithm, as shown below.
 218
 219
 220
 221
 222
 223 Mavrogiannopoulos         Expires July 4, 2008                  [Page 4]
 224 \f
 225 Internet-Draft             Using OpenPGP Keys               January 2008
 226
 227
 228       Key Exchange Algorithm  OpenPGP Certificate Type
 229
 230       RSA                     RSA public key that can be used for
 231                               encryption.
 232
 233       DHE_DSS                 DSS public key that can be used for
 234                               authentication.
 235
 236       DHE_RSA                 RSA public key that can be used for
 237                               authentication.
 238
 239    An OpenPGP certificate appearing in the certificate message is sent
 240    using the binary OpenPGP format.  The certificate MUST contain all
 241    the elements required by Section 11.1 of [OpenPGP].
 242
 243    The option is also available to send an OpenPGP fingerprint, instead
 244    of sending the entire certificate.  The process of fingerprint
 245    generation is described in Section 12.2 of [OpenPGP].  The peer shall
 246    respond with a "certificate_unobtainable" fatal alert if the
 247    certificate with the given fingerprint cannot be found.  The
 248    "certificate_unobtainable" fatal alert is defined in Section 4 of
 249    [TLSEXT].
 250
 251
 252       enum {
 253            cert_fingerprint (0), cert (1), subkey_cert (2), (255)
 254       } OpenPGPCertDescriptorType;
 255
 256       opaque OpenPGPCertFingerprint<16..20>;
 257
 258       opaque OpenPGPCert<0..2^24-1>;
 259
 260       struct {
 261           opaque OpenPGPKeyID<1..8>;
 262           opaque OpenPGPCert<0..2^24-1>;
 263       } OpenPGPSubKeyCert;
 264
 265       struct {
 266            OpenPGPCertDescriptorType descriptorType;
 267            select (descriptorType) {
 268                 case cert_fingerprint: OpenPGPCertFingerprint;
 269                 case cert: OpenPGPCert;
 270                 case subkey_cert: OpenPGPSubKeyCert;
 271            }
 272       } Certificate;
 273
 274
 275
 276
 277
 278
 279 Mavrogiannopoulos         Expires July 4, 2008                  [Page 5]
 280 \f
 281 Internet-Draft             Using OpenPGP Keys               January 2008
 282
 283
 284 3.4.  Certificate Request
 285
 286    The semantics of this message remain the same as in the TLS
 287    specification.  However, if this message is sent, and the negotiated
 288    certificate type is OpenPGP, the "certificate_authorities" list MUST
 289    be empty.
 290
 291 3.5.  Client Certificate
 292
 293    This message is only sent in response to the certificate request
 294    message.  The client certificate message is sent using the same
 295    formatting as the server certificate message, and it is also required
 296    to present a certificate that matches the negotiated certificate
 297    type.  If OpenPGP certificates have been selected and no certificate
 298    is available from the client, then a certificate structure that
 299    contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
 300    respond with a "handshake_failure" fatal alert if client
 301    authentication is required.
 302
 303 3.6.  Other Handshake Messages
 304
 305    All the other handshake messages are identical to the TLS
 306    specification.
 307
 308 4.  Security Considerations
 309
 310    All security considerations discussed in [TLS], [TLSEXT], and
 311    [OpenPGP] apply to this document.  Considerations about the use of
 312    the web of trust or identity and certificate verification procedure
 313    are outside the scope of this document.  These are considered issues
 314    to be handled by the application layer protocols.
 315
 316    The protocol for certificate type negotiation is identical in
 317    operation to ciphersuite negotiation of the [TLS] specification with
 318    the addition of default values when the extension is omitted.  Since
 319    those omissions have a unique meaning and the same protection is
 320    applied to the values as with ciphersuites, it is believed that the
 321    security properties of this negotiation are the same as with
 322    ciphersuite negotiation.
 323
 324    When using OpenPGP fingerprints instead of the full certificates, the
 325    discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs"
 326    applies, especially when external servers are used to retrieve keys.
 327    However, a major difference is that although the
 328    "client_certificate_url" extension allows identifying certificates
 329    without including the certificate hashes, this is not possible in the
 330    protocol proposed here.  In this protocol, the certificates, when not
 331    sent, are always identified by their fingerprint, which serves as a
 332
 333
 334
 335 Mavrogiannopoulos         Expires July 4, 2008                  [Page 6]
 336 \f
 337 Internet-Draft             Using OpenPGP Keys               January 2008
 338
 339
 340    cryptographic hash of the certificate (see Section 12.2 of
 341    [OpenPGP]).
 342
 343    The information that is available to participating parties and
 344    eavesdroppers (when confidentiality is not available through a
 345    previous handshake) is the number and the types of certificates they
 346    hold, plus the contents of certificates.
 347
 348 5.  IANA Considerations
 349
 350    This document defines a new TLS extension, "cert_type", assigned a
 351    value of 9 from the TLS ExtensionType registry defined in [TLSEXT].
 352    This value is used as the extension number for the extensions in both
 353    the client hello message and the server hello message.  The new
 354    extension type is used for certificate type negotiation.
 355
 356    The "cert_type" extension contains an 8-bit CertificateType field,
 357    for which a new registry, named "TLS Certificate Types", is
 358    established in this document, to be maintained by IANA.  The registry
 359    is segmented in the following way:
 360
 361    1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.
 362
 363    2.  Values from 2 through 223 decimal inclusive are assigned via IETF
 364        Consensus [RFC2434].
 365
 366    3.  Values from 224 decimal through 255 decimal inclusive are
 367        reserved for Private Use [RFC2434].
 368
 369 6.  Acknowledgements
 370
 371    This document was based on earlier work made by Will Price and
 372    Michael Elkins.
 373
 374    The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
 375    Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie
 376    Orman for their suggestions on improving this document.
 377
 378 7.  References
 379
 380 7.1.  Normative References
 381
 382    [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
 383               1.1", RFC 4346, April 2006.
 384
 385    [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
 386               Thayer, "OpenPGP Message Format", RFC 4880, October 2007.
 387
 388
 389
 390
 391 Mavrogiannopoulos         Expires July 4, 2008                  [Page 7]
 392 \f
 393 Internet-Draft             Using OpenPGP Keys               January 2008
 394
 395
 396    [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 397               and T. Wright, "Transport Layer Security (TLS)
 398               Extensions", RFC 4366, April 2006.
 399
 400    [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
 401               IANA Considerations Section in RFCs", RFC 2434,
 402               October 1998.
 403
 404    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 405               Requirement Levels", RFC 2119, March 1997.
 406
 407 7.2.  Informative References
 408
 409    [PKIX]     Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
 410               X.509 Public Key Infrastructure Certificate and
 411               Certificate Revocation List (CRL) Profile", RFC 3280,
 412               April 2002.
 413
 414 Author's Address
 415
 416    Nikos Mavrogiannopoulos
 417    Independent
 418    Arkadias 8
 419    Halandri, Attiki  15234
 420    Greece
 421
 422    EMail: nmav@gnutls.org
 423    URI:   http://www.gnutls.org/
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Mavrogiannopoulos         Expires July 4, 2008                  [Page 8]
 448 \f
 449 Internet-Draft             Using OpenPGP Keys               January 2008
 450
 451
 452 Full Copyright Statement
 453
 454    Copyright (C) The IETF Trust (2008).
 455
 456    This document is subject to the rights, licenses and restrictions
 457    contained in BCP 78, and except as set forth therein, the authors
 458    retain all their rights.
 459
 460    This document and the information contained herein are provided on an
 461    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 462    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 463    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 464    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 465    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 466    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 467
 468 Intellectual Property
 469
 470    The IETF takes no position regarding the validity or scope of any
 471    Intellectual Property Rights or other rights that might be claimed to
 472    pertain to the implementation or use of the technology described in
 473    this document or the extent to which any license under such rights
 474    might or might not be available; nor does it represent that it has
 475    made any independent effort to identify any such rights.  Information
 476    on the procedures with respect to rights in RFC documents can be
 477    found in BCP 78 and BCP 79.
 478
 479    Copies of IPR disclosures made to the IETF Secretariat and any
 480    assurances of licenses to be made available, or the result of an
 481    attempt made to obtain a general license or permission for the use of
 482    such proprietary rights by implementers or users of this
 483    specification can be obtained from the IETF on-line IPR repository at
 484    http://www.ietf.org/ipr.
 485
 486    The IETF invites any interested party to bring to its attention any
 487    copyrights, patents or patent applications, or other proprietary
 488    rights that may cover technology that may be required to implement
 489    this standard.  Please address the information to the IETF at
 490    ietf-ipr@ietf.org.
 491
 492 Acknowledgement
 493
 494    Funding for the RFC Editor function is provided by the IETF
 495    Administrative Support Activity (IASA).
 496
 497
 498
 499
 500
 501
 502
 503 Mavrogiannopoulos         Expires July 4, 2008                  [Page 9]
 504 \f