doc/protocol/draft-housley-tls-authz-extns-01.txt

   1
   2
   3
   4
   5 Internet-Draft                                                  M. Brown
   6 March 2006                                             RedPhone Security
   7 Expires: September 2006                                       R. Housley
   8                                                           Vigil Security
   9
  10         Transport Layer Security (TLS) Authorization Extensions
  11                  <draft-housley-tls-authz-extns-01.txt>
  12
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The Internet Society (2006).  All Rights Reserved.
  40
  41 Abstract
  42
  43    This document specifies authorization extensions to the Transport
  44    Layer Security (TLS) Handshake Protocol.  Authorization information
  45    is carried in the client and server hello messages.  The syntax and
  46    semantics of the authorization messages are described in detail.
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56 Brown & Housley                                                 [Page 1]
  57 \f
  58 Internet-Draft                                                March 2006
  59
  60
  61 1. Introduction
  62
  63    Transport Layer Security (TLS) protocol [TLS1.0][TLS1.1] is being
  64    used in an increasing variety of operational environments, including
  65    ones that were not envisioned when the original design criteria for
  66    TLS were determined.  The authorization extensions introduced in this
  67    document are designed to enable TLS to operate in environments where
  68    authorization information needs to be exchanged between the client
  69    and the server before any protected data is exchanged.
  70
  71    This document describes authorization extensions for the TLS
  72    Handshake Protocol in both TLS 1.0 and TLS 1.1.  These extensions
  73    observe the conventions defined for TLS Extensions [TLSEXT] that make
  74    use of the general extension mechanisms for the client hello message
  75    and the server hello message.  The extensions described in this
  76    document allow TLS clients to provide to the TLS server authorization
  77    information, and allow TLS server to provide to the TLS client
  78    authorization information about the TLS server.
  79
  80    The authorization extensions are intended for use with both TLS 1.0
  81    and TLS 1.1.  The extensions are designed to be backwards compatible,
  82    meaning that the authorization information carried in the client
  83    hello message and the server hello message can be ignored by any
  84    implementation that does not support the included authorization
  85    information format.
  86
  87    Clients typically know the context of the TLS session that is being
  88    setup, thus the client can use of the authorization extensions when
  89    needed.  Servers must accept extended client hello messages, even if
  90    the server does not "understand" the all of the listed extensions.
  91    However, the server will not make use of the authorization
  92    information if the authorization extension is not supported or the
  93    authorization information is provided in an unsupported format.
  94
  95 1.1. Conventions
  96
  97    The syntax for the authorization messages is defined using the TLS
  98    Presentation Language, which is specified in Section 4 of [TLS1.0].
  99
 100    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 101    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 102    document are to be interpreted as described in RFC 2119 [STDWORDS].
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112 Brown & Housley                                                 [Page 2]
 113 \f
 114 Internet-Draft                                                March 2006
 115
 116
 117 1.2. Overview
 118
 119    Figure 1 illustrates the placement of the authorization messages in
 120    the full TLS handshake.
 121
 122       Client                                                 Server
 123
 124       ClientHello
 125       (with AuthorizationData)  -------->
 126                                                         ServerHello
 127                                            (with AuthorizationData)
 128                                                        Certificate*
 129                                                  ServerKeyExchange*
 130                                                 CertificateRequest*
 131                                 <--------           ServerHelloDone
 132       Certificate*
 133       ClientKeyExchange
 134       CertificateVerify*
 135       [ChangeCipherSpec]
 136       Finished                  -------->
 137                                                  [ChangeCipherSpec]
 138                                 <--------                  Finished
 139       Application Data          <------->          Application Data
 140
 141        *  Indicates optional or situation-dependent messages that
 142           are not always sent.
 143
 144        [] Indicates that ChangeCipherSpec is an independent TLS
 145           Protocol content type; it is not actually a TLS
 146           Handshake Protocol message.
 147
 148     Figure 1. AuthorizationData carried in ClientHello and ServerHello
 149
 150    The ClientHello message includes the AuthorizationData extension,
 151    which contains the authorization data for the client, and then the
 152    ServerHello message includes the AuthorizationData extension, which
 153    contains the authorization data for the server.  If the server does
 154    not support the AuthorizationData extension, or the server does not
 155    support the authorization information format used by the client, then
 156    the server MUST NOT include the AuthorizationData extension in the
 157    ServerHello message.  The Handshake Protocol continues, but without
 158    the benefit of authorization information.
 159
 160 2. AuthorizationData Extension
 161
 162    The general extension mechanisms enable clients and servers to
 163    negotiate the use of specific extensions.  As specified in [TLSEXT],
 164    the extension format used in the extended client hello message and
 165
 166
 167
 168 Brown & Housley                                                 [Page 3]
 169 \f
 170 Internet-Draft                                                March 2006
 171
 172
 173    extended server hello message is:
 174
 175       struct {
 176          ExtensionType extension_type;
 177          opaque extension_data<0..2^16-1>;
 178       } Extension;
 179
 180    The extension_type identifies a particular extension type, and the
 181    extension_data contains information specific to the particular
 182    extension type.
 183
 184    As specified in [TLSEXT], for all extension types, the extension type
 185    MUST NOT appear in the extended server hello message unless the same
 186    extension type appeared in the corresponding client hello message.
 187    Clients MUST abort the handshake if they receive an extension type in
 188    the extended server hello message that they did not request in the
 189    associated extended client hello message.
 190
 191    When multiple extensions of different types are present in the
 192    extended client hello message or the extended server hello message,
 193    the extensions can appear in any order, but there MUST NOT be more
 194    than one extension of the same type.
 195
 196    This document specifies the use of one new extension type:
 197    authz_data.
 198
 199    This specification adds one new type to ExtensionType:
 200
 201       enum {
 202         authz_data(TBD), (65535)
 203       } ExtensionType;
 204
 205    The authorization extension is relevant when a session is initiated,
 206    regardless of the use of a full handshake or use of session
 207    resumption.  Clients MUST explicitly present AuthorizationData in
 208    every client hello message for which authorization information is
 209    desired.  Upon receipt of a client hello message that requests
 210    session resumption but which contains no acceptable
 211    AuthorizationData, the TLS server MAY resume the session but it MUST
 212    NOT grant authorization to the session being resumed based on any
 213    prior session authorization.
 214
 215    These requirements allow a series of resumed sessions to have
 216    different authorizations from one another.  More importantly, the
 217    authorization information is always provided by the client in case
 218    the server no longer honors the session resumption at the requested
 219    authorization level.  Repeated inclusion of the authorization
 220    information allows the Handshake Protocol to proceed the same way for
 221
 222
 223
 224 Brown & Housley                                                 [Page 4]
 225 \f
 226 Internet-Draft                                                March 2006
 227
 228
 229    both resume and session origination.
 230
 231 2.1. The authz_data Extension Type
 232
 233    Clients MUST include the authz_data extension type in the extended
 234    client hello message to send authorization data to the server.  The
 235    extension_data field contains the authorization data.  Section 2.2
 236    specifies the authorization data formats that are supported.
 237
 238    Servers that receive an extended client hello message containing the
 239    authz_data extension MUST respond with the authz_data extension in
 240    the extended server hello message if the server is willing to make
 241    use of the received authorization data in the provided format.  If
 242    the server has any authorization information to send to the client,
 243    then the server MUST include the information in the authz_data
 244    extension type in the extended server hello message.
 245
 246    The AuthorizationData structure is described in Section 2.3.
 247
 248 2.2. AuthzDataFormat Type
 249
 250    The AuthzDataFormat type is used in the authz_data extension.  It
 251    indicates the format of the authorization information that will be
 252    transferred.  The AuthzDataFormat type definition is:
 253
 254       enum {
 255          x509_attr_cert(0), saml_assertion(1), x509_attr_cert_url(2),
 256          saml_assertion_url(3), (255)
 257       } AuthzDataFormat;
 258
 259    When the x509_attr_cert value is present, the authorization data is
 260    an X.509 Attribute Certificate (AC) that conforms to the profile in
 261    RFC 3281 [ATTRCERT].
 262
 263    When the saml_assertion value is present, the authorization data is
 264    an assertion composed using the Security Assertion Markup Language
 265    (SAML) [SAML].
 266
 267    When the x509_attr_cert_url value is present, the authorization data
 268    is an X.509 AC that conforms to the profile in RFC 3281 [ATTRCERT];
 269    however, the AC is fetched with the supplied URL.  A one-way hash
 270    value is provided to ensure that the intended AC is obtained.
 271
 272    When the saml_assertion_url value is present, the authorization data
 273    is a SAML Assertion; however, the SAML Assertion is fetched with the
 274    supplied URL.  A one-way hash value is provided to ensure that the
 275    intended SAML Assertion is obtained.
 276
 277
 278
 279
 280 Brown & Housley                                                 [Page 5]
 281 \f
 282 Internet-Draft                                                March 2006
 283
 284
 285    Additional formats can be registered in the future using the
 286    procedures in section 3.
 287
 288 2.3. AuthorizationData Type
 289
 290    The AuthorizationData type is carried in the extension_data field for
 291    the authz_data extension.  When it appears in the extended client
 292    hello message, it carries authorization information for the TLS
 293    client.  When it appears in the extended server hello message, it
 294    carries authorization information for the TLS server.
 295
 296       struct {
 297          AuthorizationDataEntry authz_data_list<1..2^16-1>;
 298       } AuthorizationData;
 299
 300       struct {
 301          AuthzDataFormat authz_format;
 302          select (authz_format) {
 303             case x509_attr_cert:     X509AttrCert;
 304             case saml_assertion:     SAMLAssertion;
 305             case x509_attr_cert_url: URLandHash;
 306             case saml_assertion_url: URLandHash;
 307          } authz_data_entry;
 308       } AuthorizationDataEntry;
 309
 310       opaque X509AttrCert<1..2^16-1>;
 311
 312       opaque SAMLAssertion<1..2^16-1>;
 313
 314       struct {
 315          opaque url<1..2^16-1>;
 316          HashType hash_type;
 317          select (hash_type) {
 318             case sha1:   SHA1Hash;
 319             case sha256: SHA256Hash;
 320          } hash;
 321       } URLandHash;
 322
 323       enum {
 324          sha1(0), sha256(1), (255)
 325       } HashType;
 326
 327       opaque SHA1Hash[20];
 328
 329       opaque SHA1Hash[32];
 330
 331    When X509AttrCert is used, the field contains an ASN.1 DER-encoded
 332    X.509 Attribute Certificate (AC) that follows the profile in RFC 3281
 333
 334
 335
 336 Brown & Housley                                                 [Page 6]
 337 \f
 338 Internet-Draft                                                March 2006
 339
 340
 341    [ATTRCERT].  An AC is a structure similar to a public key certificate
 342    (PKC); the main difference being that the AC contains no public key.
 343    An AC may contain attributes that specify group membership, role,
 344    security clearance, or other authorization information associated
 345    with the AC holder.
 346
 347    When SAMLAssertion is used, the field contains XML constructs with a
 348    nested structure defined in [SAML].  SAML is an XML-based framework
 349    for exchanging security information.  This security information is
 350    expressed in the form of assertions about subjects, where a subject
 351    is either human or computer with an identity.  In this context, the
 352    assertions are most likely to convey authorization decisions about
 353    whether subjects are allowed to access certain resources.  Assertions
 354    are issued by SAML authorities, namely, authentication authorities,
 355    attribute authorities, and policy decision points.
 356
 357    Since X509AttrCert and SAMLAssertion can lead to a significant
 358    increase in the size of the hello messages, alternatives provide a
 359    URL to obtain the ASN.1 DER-encoded X.509 AC or SAML Assertion.  To
 360    ensure that the intended object is obtained, a one-way hash value of
 361    the object is also included.  Integrity of this one-way hash value is
 362    provided by the TLS Finished message.
 363
 364    Implementations that support either x509_attr_cert_url or
 365    saml_assertion_url MUST support URLs that employ the http scheme.
 366    Other schemes may also be supported; however, to avoid circular
 367    dependencies, supported schemes SHOULD NOT themselves make use of
 368    TLS, such as the https scheme.
 369
 370    Implementations that support either x509_attr_cert_url or
 371    saml_assertion_url MUST support both SHA-1 [SHA1] and SHA-256 [SHA2]
 372    as one-way hash functions.  Other one-way hash functions may also be
 373    supported.  Additional one-way hash functions can be registered in
 374    the future using the procedures in section 3.
 375
 376 3. IANA Considerations
 377
 378    IANA has assigned one TLS Extension Types: authz_data(TBD).
 379
 380    IANA has established a registry for TLS Authorization Data Formats.
 381    The first two entries in the registry are x509_attr_cert(0) and
 382    saml_assertion(1).  TLS Authorization Data Format identifiers with
 383    values in the inclusive range 0-63 (decimal) are assigned via RFC
 384    2434 [IANA] Standards Action.  Values from the inclusive range 64-223
 385    (decimal) are assigned via RFC 2434 Specification Required.  Values
 386    from the inclusive range 224-255 (decimal) are reserved for RFC 2434
 387    Private Use.
 388
 389
 390
 391
 392 Brown & Housley                                                 [Page 7]
 393 \f
 394 Internet-Draft                                                March 2006
 395
 396
 397    IANA has established a registry for TLS Hash Types.  The first two
 398    entries in the registry are sha1(0) and sha256(1).  TLS Hash Type
 399    identifiers with values in the inclusive range 0-158 (decimal) are
 400    assigned via RFC 2434 [IANA] Standards Action.  Values from the
 401    inclusive range 159-223 (decimal) are assigned via RFC 2434
 402    Specification Required.  Values from the inclusive range 224-255
 403    (decimal) are reserved for RFC 2434 Private Use.
 404
 405 4. Security Considerations
 406
 407    A TLS server can support more than one application, and each
 408    application may include several features, each of which requires
 409    separate authorization checks.  This is the reason that more than one
 410    piece of authorization information can be provided.
 411
 412    A TLS server that requires different authorization information for
 413    different applications or different application features may find
 414    that a client has provided sufficient authorization information to
 415    grant access to a subset of these offerings.  In this situation the
 416    TLS Handshake Protocol will complete successfully; however, the
 417    server must ensure that the client will only be able to use the
 418    appropriate applications and application features.  That is, the TLS
 419    server must deny access to the applications and application features
 420    for which authorization has not been confirmed.
 421
 422    In many cases, the authorization information is itself sensitive.
 423    The double handshake technique can be used to provide protection for
 424    the authorization information.  Figure 2 illustrates the double
 425    handshake, where the initial handshake does not include any
 426    authorization information, but it does result in protected
 427    communications.  Then, a second handshake that includes the
 428    authorization information is performed using the protected
 429    communications.  In Figure 2, the number on the right side indicates
 430    the amount of protection for the TLS message on that line.  A zero
 431    (0) indicates that there is no communication protection; a one (1)
 432    indicates that protection is provided by the first TLS session; and a
 433    two (2) indicates that protection is provided by both TLS sessions.
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448 Brown & Housley                                                 [Page 8]
 449 \f
 450 Internet-Draft                                                March 2006
 451
 452
 453       Client                                                 Server
 454
 455       ClientHello                                                    |0
 456       (no AuthorizationData)    -------->                            |0
 457                                                         ServerHello  |0
 458                                              (no AuthorizationData)  |0
 459                                                        Certificate*  |0
 460                                                  ServerKeyExchange*  |0
 461                                                 CertificateRequest*  |0
 462                                 <--------           ServerHelloDone  |0
 463       Certificate*                                                   |0
 464       ClientKeyExchange                                              |0
 465       CertificateVerify*                                             |0
 466       [ChangeCipherSpec]                                             |0
 467       Finished                  -------->                            |1
 468                                                  [ChangeCipherSpec]  |0
 469                                 <--------                  Finished  |1
 470       ClientHello                                                    |1
 471       (with AuthorizationData)  -------->                            |1
 472                                                         ServerHello  |1
 473                                            (with AuthorizationData)  |1
 474                                                        Certificate*  |1
 475                                                  ServerKeyExchange*  |1
 476                                                 CertificateRequest*  |1
 477                                 <--------           ServerHelloDone  |1
 478       Certificate*                                                   |1
 479       ClientKeyExchange                                              |1
 480       CertificateVerify*                                             |1
 481       [ChangeCipherSpec]                                             |1
 482       Finished                  -------->                            |2
 483                                                  [ChangeCipherSpec]  |1
 484                                 <--------                  Finished  |2
 485       Application Data          <------->          Application Data  |2
 486
 487      Figure 2. Protection of Authorization Data (Two Full Handshakes)
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504 Brown & Housley                                                 [Page 9]
 505 \f
 506 Internet-Draft                                                March 2006
 507
 508
 509    Public key operations can be minimized by making the second handshake
 510    a resumption.  This is much more efficient in term of computation and
 511    message exchanges.  Figure 3 illustrates this more efficient double
 512    handshake.
 513
 514
 515       Client                                                 Server
 516
 517       ClientHello                                                    |0
 518       (no AuthorizationData)    -------->                            |0
 519                                                         ServerHello  |0
 520                                              (no AuthorizationData)  |0
 521                                                        Certificate*  |0
 522                                                  ServerKeyExchange*  |0
 523                                                 CertificateRequest*  |0
 524                                 <--------           ServerHelloDone  |0
 525       Certificate*                                                   |0
 526       ClientKeyExchange                                              |0
 527       CertificateVerify*                                             |0
 528       [ChangeCipherSpec]                                             |0
 529       Finished                  -------->                            |1
 530                                                  [ChangeCipherSpec]  |0
 531                                 <--------                  Finished  |1
 532       ClientHello                                                    |1
 533       (with AuthorizationData)  -------->                            |1
 534                                                         ServerHello  |1
 535                                            (with AuthorizationData)  |1
 536                                                  [ChangeCipherSpec]  |1
 537                                 <--------                  Finished  |2
 538       [ChangeCipherSpec]                                             |1
 539       Finished                  -------->                            |2
 540       Application Data          <------->          Application Data  |2
 541
 542           Figure 3. Protection of Authorization Data (Resumption)
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559
 560 Brown & Housley                                                [Page 10]
 561 \f
 562 Internet-Draft                                                March 2006
 563
 564
 565 5. Normative References
 566
 567    [ATTRCERT]   Farrell, S., and R. Housley, "An Internet Attribute
 568                 Certificate Profile for Authorization", RFC 3281,
 569                 April 2002.
 570
 571    [IANA]       Narten, T., and H. Alvestrand, "Guidelines for Writing
 572                 an IANA Considerations Section in RFCs", RFC 3434,
 573                 October 1998.
 574
 575    [TLS1.0]     Dierks, T., and C. Allen, "The TLS Protocol, Version 1.0",
 576                 RFC 2246, January 1999.
 577
 578    [TLS1.1]     Dierks, T., and E. Rescorla, "The Transport Layer Security
 579                 (TLS) Protocol, Version 1.1", RFC 4346, February 2006.
 580
 581    [TLSEXT]     Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 582                 and T. Wright, "Transport Layer Security (TLS) Extensions",
 583                 RFC 3546, June 2003.
 584
 585    [SAML]       Organization for the Advancement of Structured Information
 586                 Standards, "Security Assertion Markup Language (SAML),
 587                 version 1.1", September 2003.  [Version 2.0 is out for
 588                 public comment; it will replace this reference if approved.]
 589
 590    [SHA1]       National Institute of Standards and Technology (NIST),
 591                 FIPS PUB 180-1, Secure Hash Standard, 17 April 1995.
 592
 593    [SHA2]       National Institute of Standards and Technology (NIST),
 594                 FIPS PUB 180-2: Secure Hash Standard, 1 August 2002.
 595
 596    [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
 597                 Requirement Levels", BCP 14, RFC 2119, March 1997.
 598
 599
 600
 601
 602
 603
 604
 605
 606
 607
 608
 609
 610
 611
 612
 613
 614
 615
 616 Brown & Housley                                                [Page 11]
 617 \f
 618 Internet-Draft                                                March 2006
 619
 620
 621 Author's Address
 622
 623    Mark Brown
 624    RedPhone Security
 625    2019 Palace Avenue
 626    Saint Paul, MN 55105
 627    USA
 628    mark <at> redphonesecurity <dot> com
 629
 630    Russell Housley
 631    Vigil Security, LLC
 632    918 Spring Knoll Drive
 633    Herndon, VA 20170
 634    USA
 635    housley <at> vigilsec <dot> com
 636
 637 Full Copyright Statement
 638
 639    Copyright (C) The Internet Society (2006). This document is subject
 640    to the rights, licenses and restrictions contained in BCP 78, and
 641    except as set forth therein, the authors retain all their rights.
 642
 643    This document and translations of it may be copied and furnished to
 644    others, and derivative works that comment on or otherwise explain it
 645    or assist in its implementation may be prepared, copied, published
 646    and distributed, in whole or in part, without restriction of any
 647    kind, provided that the above copyright notice and this paragraph are
 648    included on all such copies and derivative works. However, this
 649    document itself may not be modified in any way, such as by removing
 650    the copyright notice or references to the Internet Society or other
 651    Internet organizations, except as needed for the purpose of
 652    developing Internet standards in which case the procedures for
 653    copyrights defined in the Internet Standards process must be
 654    followed, or as required to translate it into languages other than
 655    English.
 656
 657    This document and the information contained herein are provided on an
 658    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 659    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 660    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 661    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 662    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 663    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 664
 665
 666
 667
 668
 669
 670
 671
 672 Brown & Housley                                                [Page 12]