doc/protocol/draft-ietf-tls-openpgp-keys-06.txt

   1
   2 TLS Working Group                                     N. Mavroyanopoulos
   3 Internet-Draft                                          January 25, 2005
   4 Expires: July 26, 2005
   5
   6                Using OpenPGP keys for TLS authentication
   7                      draft-ietf-tls-openpgp-keys-06
   8
   9 Status of this Memo
  10
  11    This document is an Internet-Draft and is subject to all provisions
  12    of section 3 of RFC 3667.  By submitting this Internet-Draft, each
  13    author represents that any applicable patent or other IPR claims of
  14    which he or she is aware have been or will be disclosed, and any of
  15    which he or she become aware will be disclosed, in accordance with
  16    RFC 3668.
  17
  18    Internet-Drafts are working documents of the Internet Engineering
  19    Task Force (IETF), its areas, and its working groups.  Note that
  20    other groups may also distribute working documents as
  21    Internet-Drafts.
  22
  23    Internet-Drafts are draft documents valid for a maximum of six months
  24    and may be updated, replaced, or obsoleted by other documents at any
  25    time.  It is inappropriate to use Internet-Drafts as reference
  26    material or to cite them other than as "work in progress."
  27
  28    The list of current Internet-Drafts can be accessed at
  29    http://www.ietf.org/ietf/1id-abstracts.txt.
  30
  31    The list of Internet-Draft Shadow Directories can be accessed at
  32    http://www.ietf.org/shadow.html.
  33
  34    This Internet-Draft will expire on July 26, 2005.
  35
  36 Copyright Notice
  37
  38    Copyright (C) The Internet Society (2005).
  39
  40 Abstract
  41
  42    This memo proposes extensions to the TLS protocol to support the
  43    OpenPGP trust model and keys.  The extensions discussed here include
  44    a certificate type negotiation mechanism, and the required
  45    modifications to the TLS Handshake Protocol.
  46
  47
  48
  49
  50 Mavroyanopoulos          Expires July 26, 2005                  [Page 1]
  51 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
  52
  53 Table of Contents
  54
  55    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  56    2.  Extension Type . . . . . . . . . . . . . . . . . . . . . . . .  4
  57    3.  Changes to the Handshake Message Contents  . . . . . . . . . .  5
  58      3.1   Client Hello . . . . . . . . . . . . . . . . . . . . . . .  5
  59      3.2   Server Hello . . . . . . . . . . . . . . . . . . . . . . .  5
  60      3.3   Server Certificate . . . . . . . . . . . . . . . . . . . .  6
  61      3.4   Certificate request  . . . . . . . . . . . . . . . . . . .  7
  62      3.5   Client certificate . . . . . . . . . . . . . . . . . . . .  7
  63      3.6   Server key exchange  . . . . . . . . . . . . . . . . . . .  8
  64      3.7   Certificate verify . . . . . . . . . . . . . . . . . . . .  8
  65      3.8   Finished . . . . . . . . . . . . . . . . . . . . . . . . .  8
  66    4.  Cipher suites  . . . . . . . . . . . . . . . . . . . . . . . .  9
  67    5.  Internationalization Considerations  . . . . . . . . . . . . . 10
  68    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
  69    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  70    7.1   Normative References . . . . . . . . . . . . . . . . . . . . 12
  71    7.2   Informative References . . . . . . . . . . . . . . . . . . . 12
  72        Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
  73    A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
  74        Intellectual Property and Copyright Statements . . . . . . . . 14
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90 Mavroyanopoulos          Expires July 26, 2005                  [Page 2]
  91 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
  92
  93 1.  Introduction
  94
  95    At the time of writing, TLS [1] uses the PKIX [6] infrastructure, to
  96    provide certificate services.  Currently the PKIX protocols are
  97    limited to a hierarchical key management and as a result,
  98    applications which follow different - non hierarchical - trust
  99    models, like the "web of trust" model, could not be benefited by TLS.
 100
 101    OpenPGP keys (sometimes called OpenPGP certificates), provide
 102    security services for electronic communications.  They are widely
 103    deployed, especially in electronic mail applications, provide public
 104    key authentication services, and allow distributed key management.
 105
 106    This document will extend the TLS protocol to support OpenPGP keys
 107    and trust model using the existing TLS cipher suites.  In brief this
 108    would be achieved by adding a negotiation of the certificate type in
 109    addition to the normal handshake negotiations.  Then the required
 110    modifications to the handshake messages, in order to hold OpenPGP
 111    keys as well, will be described.  The the normal handshake procedure
 112    with X.509 certificates will not be altered, to preserve
 113    compatibility with existing TLS servers and clients.
 114
 115    This document uses the same notation used in the TLS Protocol
 116    specification.
 117
 118    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 119    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 120    document are to be interpreted as described in RFC 2119.
 121
 122
 123
 124
 125
 126
 127
 128
 129
 130
 131
 132
 133 Mavroyanopoulos          Expires July 26, 2005                  [Page 3]
 134 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 135
 136 2.  Extension Type
 137
 138    A new value, "cert_type(7)", is added to the enumerated
 139    ExtensionType, defined in TLSEXT [3].  This value is used as the
 140    extension number for the extensions in both the client hello message
 141    and the server hello message.  This new extension type will be used
 142    for certificate type negotiation.
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165 Mavroyanopoulos          Expires July 26, 2005                  [Page 4]
 166 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 167
 168 3.  Changes to the Handshake Message Contents
 169
 170    This section describes the changes to the TLS handshake message
 171    contents when OpenPGP keys are to be used for authentication.
 172
 173 3.1  Client Hello
 174
 175    In order to indicate the support of multiple certificate types
 176    clients will include an extension of type "cert_type" to the extended
 177    client hello message.  The hello extension mechanism is described in
 178    TLSEXT [3].
 179
 180    This extension carries a list of supported certificate types the
 181    client can use, sorted by client preference.  This extension MAY be
 182    omitted if the client only supports X.509 certificates.  The
 183    "extension_data" field of this extension will contain a
 184    CertificateTypeExtension structure.
 185
 186       enum { client, server } ClientOrServerExtension;
 187
 188       enum { X.509(0), OpenPGP(1), (255) } CertificateType;
 189
 190       struct {
 191          select(ClientOrServerExtension) {
 192             case client:
 193                CertificateType certificate_types<1..2^8-1>;
 194             case server:
 195                CertificateType certificate_type;
 196          }
 197       } CertificateTypeExtension;
 198
 199 3.2  Server Hello
 200
 201    Servers that receive an extended client hello containing the
 202    "cert_type" extension, and have chosen a cipher suite that supports
 203    certificates, then they MUST select a certificate type from the
 204    certificate_types field in the extended client hello, or terminate
 205    the connection with a fatal alert of type "unsupported_certificate".
 206
 207    The certificate type selected by the server, is encoded in a
 208    CertificateTypeExtension structure, which is included in the extended
 209    server hello message, using an extension of type "cert_type".
 210    Servers that only support X.509 certificates MAY omit including the
 211    "cert_type" extension in the extended server hello.
 212
 213
 214
 215 Mavroyanopoulos          Expires July 26, 2005                  [Page 5]
 216 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 217
 218 3.3  Server Certificate
 219
 220    The contents of the certificate message sent from server to client
 221    and vice versa are determined by the negotiated certificate type and
 222    the selected cipher suite's key exchange algorithm.
 223
 224    If the OpenPGP certificate type is negotiated then it is required to
 225    present an OpenPGP key in the Certificate message.  The OpenPGP key
 226    must contain a public key that matches the selected key exchange
 227    algorithm, as shown below.
 228
 229       Key Exchange Algorithm  OpenPGP Key Type
 230
 231       RSA                     RSA public key which can be used for
 232                               encryption.
 233
 234       DHE_DSS                 DSS public key.
 235
 236       DHE_RSA                 RSA public key which can be used for
 237                               signing.
 238
 239    An OpenPGP public key appearing in the Certificate message will be
 240    sent using the binary OpenPGP format.  The term public key is used to
 241    describe a composition of OpenPGP packets to form a block of data
 242    which contains all information needed by the peer.  This includes
 243    public key packets, user ID packets and all the fields described in
 244    "Transferable Public Keys" section in OpenPGP [2].
 245
 246    The option is also available to send an OpenPGP fingerprint, instead
 247    of sending the entire key.  The process of fingerprint generation is
 248    described in OpenPGP [2].  The peer shall respond with a
 249    "certificate_unobtainable" fatal alert if the key with the given key
 250    fingerprint cannot be found.  The "certificate_unobtainable" fatal
 251    alert is defined in section 4 of TLSEXT [3].
 252
 253    If the key is not valid, expired, revoked, corrupt, the appropriate
 254    fatal alert message is sent from section A.3 of the TLS
 255    specification.  If a key is valid and neither expired nor revoked, it
 256    is accepted by the protocol.  The key validation procedure is a local
 257    matter outside the scope of this document.
 258
 259
 260
 261
 262
 263 Mavroyanopoulos          Expires July 26, 2005                  [Page 6]
 264 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 265
 266       enum {
 267            key_fingerprint (0), key (1), (255)
 268       } PGPKeyDescriptorType;
 269
 270       opaque PGPKeyFingerprint<16..20>;
 271
 272       opaque PGPKey<0..2^24-1>;
 273
 274       struct {
 275            PGPKeyDescriptorType descriptorType;
 276            select (descriptorType) {
 277                 case key_fingerprint: PGPKeyFingerprint;
 278                 case key: PGPKey;
 279            }
 280       } Certificate;
 281
 282 3.4  Certificate request
 283
 284    The semantics of this message remain the same as in the TLS
 285    specification.  However the structure of this message has been
 286    modified for OpenPGP keys.  The PGPCertificateRequest structure will
 287    only be used if the negotiated certificate type is OpenPGP.
 288
 289       enum {
 290           rsa_sign(1), dss_sign(2), (255)
 291       } ClientCertificateParamsType;
 292
 293       struct {
 294           ClientCertificateParamsType certificate_params_types<1..2^8-1>;
 295       } PGPCertificateRequest;
 296
 297    The certificate_params_types is a list of accepted client certificate
 298    parameter types, sorted in order of the server's preference.
 299
 300 3.5  Client certificate
 301
 302    This message is only sent in response to the certificate request
 303    message.  The client certificate message is sent using the same
 304    formatting as the server certificate message and it is also required
 305    to present a certificate that matches the negotiated certificate
 306    type.  If OpenPGP keys have been selected, and no key is available
 307    from the client, then a Certificate that contains an empty PGPKey
 308    should be sent.  The server may respond with a "handshake_failure"
 309    fatal alert if client authentication is required.  This transaction
 310    follows the TLS specification.
 311
 312
 313 Mavroyanopoulos          Expires July 26, 2005                  [Page 7]
 314 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 315
 316 3.6  Server key exchange
 317
 318    The server key exchange message for OpenPGP keys is identical to the
 319    TLS specification.
 320
 321 3.7  Certificate verify
 322
 323    The certificate verify message for OpenPGP keys is identical to the
 324    TLS specification.
 325
 326 3.8  Finished
 327
 328    The finished message for OpenPGP keys is identical to the description
 329    in the specification.
 330
 331
 332
 333
 334
 335
 336
 337
 338
 339
 340
 341
 342
 343
 344
 345
 346
 347
 348
 349 Mavroyanopoulos          Expires July 26, 2005                  [Page 8]
 350 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 351
 352 4.  Cipher suites
 353
 354    No new cipher suites are required to use OpenPGP keys.  OpenPGP keys
 355    can be combined with existing cipher suites defined in TLS [1],
 356    except the ones marked as "Exportable".  Exportable cipher suites
 357    SHOULD NOT be used with OpenPGP keys.
 358
 359    Some additional cipher suites are defined here in order to support
 360    algorithms which are defined in OpenPGP [2], and are always available
 361    in OpenPGP implementations but are not present in TLS [1].
 362
 363       CipherSuite TLS_DHE_DSS_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x72 };
 364       CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_RMD160  = { 0x00, 0x73 };
 365       CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_RMD160  = { 0x00, 0x74 };
 366       CipherSuite TLS_DHE_RSA_WITH_3DES_EDE_CBC_RMD160 = { 0x00, 0x77 };
 367       CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_RMD160  = { 0x00, 0x78 };
 368       CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_RMD160  = { 0x00, 0x79 };
 369       CipherSuite TLS_RSA_WITH_3DES_EDE_CBC_RMD160     = { 0x00, 0x7C };
 370       CipherSuite TLS_RSA_WITH_AES_128_CBC_RMD160      = { 0x00, 0x7D };
 371       CipherSuite TLS_RSA_WITH_AES_256_CBC_RMD160      = { 0x00, 0x7E };
 372
 373    All of the above cipher suites use either the AES [5] and 3DES block
 374    ciphers in CBC mode.  The choice of hash is the RIPEMD-160 [4]
 375    algorithm.  Implementations are not required to support the above
 376    cipher suites.
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390 Mavroyanopoulos          Expires July 26, 2005                  [Page 9]
 391 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 392
 393 5.  Internationalization Considerations
 394
 395    All the methods defined in this document are represented as machine
 396    readable structures.  As such issues of human internationalization
 397    and localization are not introduced.
 398
 399
 400
 401
 402
 403
 404
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421 Mavroyanopoulos          Expires July 26, 2005                 [Page 10]
 422 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 423
 424 6.  Security Considerations
 425
 426    As with X.509 ASN.1 formatted keys, OpenPGP keys need specialized
 427    parsers.  Care must be taken to make those parsers safe against
 428    maliciously modified keys, that may crash or modify the application's
 429    memory.
 430
 431    Security considerations about the use of the web of trust or the
 432    verification procedure are outside the scope of this document, since
 433    they are considered a local policy matter.
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450
 451
 452
 453
 454
 455 Mavroyanopoulos          Expires July 26, 2005                 [Page 11]
 456 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 457
 458 7.  References
 459
 460 7.1  Normative References
 461
 462    [1]  Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January
 463         1999.
 464
 465    [2]  Callas, J., Donnerhacke, L., Finey, H. and R. Thayer, "OpenPGP
 466         Message Format", RFC 2440, November 1998.
 467
 468    [3]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and T.
 469         Wright, "TLS Extensions", RFC 3546, June 2003.
 470
 471    [4]  Dobbertin, H., Bosselaers, A. and B. Preneel, "RIPEMD-160: A
 472         Strengthened Version of RIPEMD", April 1996.
 473
 474    [5]  Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
 475         Transport Layer Security (TLS)", RFC 3268, June 2002.
 476
 477 7.2  Informative References
 478
 479    [6]  Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509
 480         Public Key Infrastructure Certificate and Certificate Revocation
 481         List (CRL) Profile", RFC 3280, April 2002.
 482
 483    [7]  "Recommendation X.509: The Directory - Authentication
 484         Framework", 1988.
 485
 486 Author's Address
 487
 488    Nikos Mavroyanopoulos
 489    Arkadias 8
 490    Halandri, Attiki  15234
 491    Greece
 492
 493    EMail: nmav@gnutls.org
 494    URI:   http://www.gnutls.org/
 495
 496
 497
 498
 499
 500
 501
 502 Mavroyanopoulos          Expires July 26, 2005                 [Page 12]
 503 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 504
 505 Appendix A.  Acknowledgements
 506
 507    The author wishes to thank Werner Koch, David Taylor and Timo Schulz
 508    for their suggestions on improving this document.
 509
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533 Mavroyanopoulos          Expires July 26, 2005                 [Page 13]
 534 Internet-Draft    Using OpenPGP keys for TLS authentication January 2005
 535
 536 Intellectual Property Statement
 537
 538    The IETF takes no position regarding the validity or scope of any
 539    Intellectual Property Rights or other rights that might be claimed to
 540    pertain to the implementation or use of the technology described in
 541    this document or the extent to which any license under such rights
 542    might or might not be available; nor does it represent that it has
 543    made any independent effort to identify any such rights.  Information
 544    on the procedures with respect to rights in RFC documents can be
 545    found in BCP 78 and BCP 79.
 546
 547    Copies of IPR disclosures made to the IETF Secretariat and any
 548    assurances of licenses to be made available, or the result of an
 549    attempt made to obtain a general license or permission for the use of
 550    such proprietary rights by implementers or users of this
 551    specification can be obtained from the IETF on-line IPR repository at
 552    http://www.ietf.org/ipr.
 553
 554    The IETF invites any interested party to bring to its attention any
 555    copyrights, patents or patent applications, or other proprietary
 556    rights that may cover technology that may be required to implement
 557    this standard.  Please address the information to the IETF at
 558    ietf-ipr@ietf.org.
 559
 560 Disclaimer of Validity
 561
 562    This document and the information contained herein are provided on an
 563    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 564    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 565    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 566    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 567    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 568    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 569
 570 Copyright Statement
 571
 572    Copyright (C) The Internet Society (2005).  This document is subject
 573    to the rights, licenses and restrictions contained in BCP 78, and
 574    except as set forth therein, the authors retain all their rights.
 575
 576 Acknowledgment
 577
 578    Funding for the RFC Editor function is currently provided by the
 579    Internet Society.
 580
 581
 582 Mavroyanopoulos          Expires July 26, 2005                 [Page 14]