doc/specification/draft-ietf-sasl-gssapi-06.txt

   1
   2
   3
   4
   5 SASL                                                         A. Melnikov
   6 Internet-Draft                                                     Isode
   7 Expires: December 11, 2006                                  June 9, 2006
   8
   9
  10                The Kerberos V5 ("GSSAPI") SASL mechanism
  11                        draft-ietf-sasl-gssapi-06
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on December 11, 2006.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2006).
  41
  42 Abstract
  43
  44    The Simple Authentication and Security Layer (SASL, RFC 4422) is a
  45    framework for adding authentication support to connection-based
  46    protocols.  This document describes the method for using the Generic
  47    Security Service Application Program Interface (GSS-API) Kerberos V5
  48    in the SASL.
  49
  50    This document replaces section 7.2 of RFC 2222, the definition of the
  51    "GSSAPI" SASL mechanism.
  52
  53
  54
  55
  56 Melnikov                Expires December 11, 2006               [Page 1]
  57 \f
  58 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
  59
  60
  61 Table of Contents
  62
  63    1.  Conventions Used in this Document  . . . . . . . . . . . . . .  3
  64    2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  65      2.1.  Relationship to Other Documents  . . . . . . . . . . . . .  3
  66    3.  Kerberos V5 GSS-API mechanism  . . . . . . . . . . . . . . . .  3
  67      3.1.  Client side of authentication protocol exchange  . . . . .  3
  68      3.2.  Server side of authentication protocol exchange  . . . . .  4
  69      3.3.  Security layer . . . . . . . . . . . . . . . . . . . . . .  6
  70    4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  6
  71    5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
  72    6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
  73    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  74      7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
  75      7.2.  Informative References . . . . . . . . . . . . . . . . . .  8
  76    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
  77    Intellectual Property and Copyright Statements . . . . . . . . . . 10
  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
 112 Melnikov                Expires December 11, 2006               [Page 2]
 113 \f
 114 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 115
 116
 117 1.  Conventions Used in this Document
 118
 119    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
 120    in this document are to be interpreted as defined in "Key words for
 121    use in RFCs to Indicate Requirement Levels" [KEYWORDS].
 122
 123
 124 2.  Introduction
 125
 126    This specification documents currently deployed Simple Authentication
 127    and Security Layer (SASL [SASL]) mechanism supporting the Kerberos V5
 128    [KERBEROS] Generic Security Service Application Program Interface
 129    ([GSS-API]) mechanism [RFC4121].  The authentication sequence is
 130    described in Section 3.  Note that the described authentication
 131    sequence has known limitations in particular it lacks channel
 132    bindings and the number of round trips required to complete
 133    authentication exchange is not minimal.  SASL WG is working on a
 134    separate document that should address these limitations.
 135
 136 2.1.  Relationship to Other Documents
 137
 138    This document, together with RFC 4422, obsoletes RFC 2222 in its
 139    entirety.  This document replaces Section 7.2 of RFC 2222.  The
 140    remainder is obsoleted as detailed in Section 1.2 of RFC 4422.
 141
 142
 143 3.  Kerberos V5 GSS-API mechanism
 144
 145    The SASL mechanism name for the Kerberos V5 GSS-API mechanism
 146    [RFC4121] is "GSSAPI".  Though known as the SASL GSSAPI mechanism,
 147    the mechanism is specifically tied to Kerberos V5 and GSS-API's
 148    Kerberos V5 mechanism.
 149
 150    The GSSAPI SASL mechanism is a "client goes first" SASL mechanism,
 151    i.e. it starts with the client sending a "response" created as
 152    described in the following section.
 153
 154    The implementation MAY set any GSS-API flags or arguments not
 155    mentioned in this specification as is necessary for the
 156    implementation to enforce its security policy.
 157
 158 3.1.  Client side of authentication protocol exchange
 159
 160    The client calls GSS_Init_sec_context, passing in
 161    input_context_handle of 0 (initially), mech_type of the Kerberos V5
 162    GSS-API mechanism [KRB5GSS], chan_binding of NULL, and targ_name
 163    equal to output_name from GSS_Import_Name called with input_name_type
 164    of GSS_C_NT_HOSTBASED_SERVICE and input_name_string of
 165
 166
 167
 168 Melnikov                Expires December 11, 2006               [Page 3]
 169 \f
 170 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 171
 172
 173    "service@hostname" where "service" is the service name specified in
 174    the protocol's profile, and "hostname" is the fully qualified host
 175    name of the server.  If the client will be requesting a security
 176    layer, it MUST also supply to the GSS_Init_sec_context a
 177    mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an
 178    integ_req_flag of TRUE.  If the client will be requesting a security
 179    layer providing confidentiality protection, it MUST also supply to
 180    the GSS_Init_sec_context a conf_req_flag of TRUE.  The client then
 181    responds with the resulting output_token.  If GSS_Init_sec_context
 182    returns GSS_S_CONTINUE_NEEDED, then the client should expect the
 183    server to issue a token in a subsequent challenge.  The client must
 184    pass the token to another call to GSS_Init_sec_context, repeating the
 185    actions in this paragraph.
 186
 187    When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
 188    the context to ensure that it provides a level of protection
 189    permitted by the client's security policy.  If the context is
 190    acceptable, the client takes the following actions: If the last call
 191    to GSS_Init_sec_context returned an output_token, then the client
 192    responds with the output_token, otherwise the client responds with no
 193    data.  The client should then expect the server to issue a token in a
 194    subsequent challenge.  The client passes this token to GSS_Unwrap and
 195    interprets the first octet of resulting cleartext as a bit-mask
 196    specifying the security layers supported by the server and the second
 197    through fourth octets as the maximum size output_message the server
 198    is able to receive (in network byte order).  If the resulting
 199    cleartext is not 4 octets long, the client fails the negotiation.
 200    The client verifies that the server maximum buffer is 0 if the server
 201    doesn't advertise support for any security layer.  The client then
 202    constructs data, with the first octet containing the bit-mask
 203    specifying the selected security layer, the second through fourth
 204    octets containing in network byte order the maximum size
 205    output_message the client is able to receive (which MUST be 0 if the
 206    client doesn't support any security layer), and the remaining octets
 207    containing the UTF-8 [UTF8] encoded authorization identity.
 208    (Implementation note: the authorization identity is not terminated
 209    with the zero-valued (%x00) octet (e.g., the UTF-8 encoding of the
 210    NUL (U+0000) character)).  The client passes the data to GSS_Wrap
 211    with conf_flag set to FALSE, and responds with the generated
 212    output_message.  The client can then consider the server
 213    authenticated.
 214
 215 3.2.  Server side of authentication protocol exchange
 216
 217    A server MUST NOT advertise support for the "GSSAPI" SASL mechanism
 218    described in this document unless it has acceptor credential for the
 219    Kerberos V GSS-API Mechanism [KRB5GSS].
 220
 221
 222
 223
 224 Melnikov                Expires December 11, 2006               [Page 4]
 225 \f
 226 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 227
 228
 229    The server passes the initial client response to
 230    GSS_Accept_sec_context as input_token, setting input_context_handle
 231    to 0 (initially), chan_binding of NULL, and a suitable
 232    acceptor_cred_handle (see below).  If GSS_Accept_sec_context returns
 233    GSS_S_CONTINUE_NEEDED, the server returns the generated output_token
 234    to the client in challenge and passes the resulting response to
 235    another call to GSS_Accept_sec_context, repeating the actions in this
 236    paragraph.
 237
 238    Servers SHOULD use a credential obtained by calling GSS_Acquire_cred
 239    or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the
 240    Kerberos V5 GSS-API mechanism [KRB5GSS](*).  Servers MAY use
 241    GSS_C_NO_CREDENTIAL as an acceptor credential handle.  Servers MAY
 242    use a credential obtained by calling GSS_Acquire_cred or GSS_Add_cred
 243    for the server's principal name(s) (**) and the Kerberos V5 GSS-API
 244    mechanism [KRB5GSS].
 245
 246    (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of
 247    GSS-API mechanism as an input parameter.  The OID set can be created
 248    by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member.  It can
 249    be freed by calling the GSS_Release_oid_set.
 250
 251    (**) - Use of server's principal names having
 252    GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format,
 253    where "service" is the service name specified in the protocol's
 254    profile, is RECOMMENDED.
 255
 256    Upon successful establishment of the security context (i.e.
 257    GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD
 258    verify that the negotiated GSS-API mechanism is indeed Kerberos V5
 259    [KRB5GSS].  This is done by examining the value of the mech_type
 260    parameter returned from the GSS_Accept_sec_context call.  If the
 261    value differ SASL authentication MUST be aborted.
 262
 263    Upon successful establishment of the security context the server
 264    SHOULD also check using the GSS_Inquire_context that the target_name
 265    used by the client matches either:
 266
 267    -  the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax,
 268       where "service" is the service name specified in the application
 269       protocol's profile,
 270
 271       or that
 272
 273    -  the GSS_KRB5_NT_PRINCIPAL_NAME [KRB5GSS] name syntax for a two-
 274       component principal where the first component matches the service
 275       name specified in the application protocol's profile.
 276
 277
 278
 279
 280 Melnikov                Expires December 11, 2006               [Page 5]
 281 \f
 282 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 283
 284
 285    When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
 286    examines the context to ensure that it provides a level of protection
 287    permitted by the server's security policy.  If the context is
 288    acceptable, the server takes the following actions: If the last call
 289    to GSS_Accept_sec_context returned an output_token, the server
 290    returns it to the client in a challenge and expects a reply from the
 291    client with no data.  Whether or not an output_token was returned
 292    (and after receipt of any response from the client to such an
 293    output_token), the server then constructs 4 octets of data, with the
 294    first octet containing a bit-mask specifying the security layers
 295    supported by the server and the second through fourth octets
 296    containing in network byte order the maximum size output_token the
 297    server is able to receive (which MUST be 0 if the server doesn't
 298    support any security layer).  The server must then pass the plaintext
 299    to GSS_Wrap with conf_flag set to FALSE and issue the generated
 300    output_message to the client in a challenge.  The server must then
 301    pass the resulting response to GSS_Unwrap and interpret the first
 302    octet of resulting cleartext as the bit-mask for the selected
 303    security layer, the second through fourth octets as the maximum size
 304    output_message the client is able to receive (in network byte order),
 305    and the remaining octets as the authorization identity.  The server
 306    verifies that the client has selected a security layer that was
 307    offered, and that the client maximum buffer is 0 if no security layer
 308    was chosen.  The server must verify that the src_name is authorized
 309    to act as the authorization identity.  After these verifications, the
 310    authentication process is complete.
 311
 312 3.3.  Security layer
 313
 314    The security layers and their corresponding bit-masks are as follows:
 315
 316          1 No security layer
 317          2 Integrity protection.
 318            Sender calls GSS_Wrap with conf_flag set to FALSE
 319          4 Confidentiality protection.
 320            Sender calls GSS_Wrap with conf_flag set to TRUE
 321
 322    Other bit-masks may be defined in the future; bits which are not
 323    understood must be negotiated off.
 324
 325    Note that SASL negotiates the maximum size of the output_message to
 326    send.  Implementations can use the GSS_Wrap_size_limit call to
 327    determine the corresponding maximum size input_message.
 328
 329
 330 4.  IANA Considerations
 331
 332    The IANA is directed to modify the existing registration for "GSSAPI"
 333
 334
 335
 336 Melnikov                Expires December 11, 2006               [Page 6]
 337 \f
 338 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 339
 340
 341    as follows:
 342
 343    Family of SASL mechanisms: NO
 344
 345    SASL mechanism name: GSSAPI
 346
 347    Security considerations: See Section 5 of RFC [THIS-DOC]
 348
 349    Published Specification: RFC [THIS-DOC]
 350
 351    Person & email address to contact for further information: Alexey
 352       Melnikov <Alexey.Melnikov@isode.com>
 353
 354    Intended usage: COMMON
 355
 356    Owner/Change controller: iesg@ietf.org
 357
 358    Additional Information: This mechanism is for the Kerberos V5
 359       mechanism of GSS-API.
 360
 361
 362 5.  Security Considerations
 363
 364    Security issues are discussed throughout this memo.
 365
 366    The integrity protection provided by the GSSAPI security layer is
 367    useless to the client unless the client also requests mutual
 368    authentication.  Therefore, a client wishing to benefit from the
 369    integrity protection of a security layer MUST pass to the
 370    GSS_Init_sec_context call a mutual_req_flag of TRUE.
 371
 372    When constructing the input_name_string, the client SHOULD NOT
 373    canonicalize the server's fully qualified domain name using an
 374    insecure or untrusted directory service.
 375
 376    For compatibility with deployed software this document requires that
 377    the chan_binding (channel bindings) parameter to GSS_Init_sec_context
 378    and GSS_Accept_sec_context be NULL, hence disallowing use of GSS-API
 379    support for channel bindings.  GSS-API channel bindings in SASL is
 380    expected to be supported via a new GSS-API family of SASL mechanisms
 381    (to be introduced in a future document).
 382
 383    Additional security considerations are in the [SASL] and [GSS-API]
 384    specifications.  Additional security considerations for the GSS-API
 385    mechanism can be found in [KRB5GSS] and [KERBEROS].
 386
 387
 388
 389
 390
 391
 392 Melnikov                Expires December 11, 2006               [Page 7]
 393 \f
 394 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 395
 396
 397 6.  Acknowledgements
 398
 399    This document replaces section 7.2 of RFC 2222 [RFC2222] by John G.
 400    Myers.  He also contributed significantly to this revision.
 401
 402    Lawrence Greenfield converted text of this draft to the XML format.
 403
 404    Contributions of many members of the SASL mailing list are gratefully
 405    acknowledged, in particular comments from Chris Newman, Nicolas
 406    Williams and Jeffrey Hutzelman.
 407
 408
 409 7.  References
 410
 411 7.1.  Normative References
 412
 413    [GSS-API]  Linn, J., "Generic Security Service Application Program
 414               Interface Version 2, Update 1", RFC 2743, January 2000.
 415
 416    [KERBEROS]
 417               Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 418               Kerberos Network Authentication Service (V5)", RFC 4120,
 419               July 2005.
 420
 421    [KEYWORDS]
 422               Bradner, S., "Key words for use in RFCs to Indicate
 423               Requirement Levels", BCP 14, RFC 2119, March 1997.
 424
 425    [KRB5GSS]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
 426               RFC 1964, June 1996.
 427
 428    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 429               Version 5 Generic Security Service Application Program
 430               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 431               July 2005.
 432
 433    [SASL]     Melnikov, A. and K. Zeilenga, "Simple Authentication and
 434               Security Layer (SASL)", RFC 4422, June 2006.
 435
 436    [UTF8]     Yergeau, F., "UTF-8, a transformation format of ISO
 437               10646", RFC 3629, November 2003.
 438
 439 7.2.  Informative References
 440
 441    [RFC2222]  Myers, J., "Simple Authentication and Security Layer
 442               (SASL)", RFC 2222, October 1997.
 443
 444
 445
 446
 447
 448 Melnikov                Expires December 11, 2006               [Page 8]
 449 \f
 450 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 451
 452
 453 Author's Address
 454
 455    Alexey Melnikov (Ed.)
 456    Isode Limited
 457    5 Castle Business Village
 458    36 Station Road
 459    Hampton, Middlesex  TW12 2BX
 460    UK
 461
 462    Email: Alexey.Melnikov@isode.com
 463    URI:   http://www.melnikov.ca/
 464
 465
 466
 467
 468
 469
 470
 471
 472
 473
 474
 475
 476
 477
 478
 479
 480
 481
 482
 483
 484
 485
 486
 487
 488
 489
 490
 491
 492
 493
 494
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504 Melnikov                Expires December 11, 2006               [Page 9]
 505 \f
 506 Internet-Draft  The Kerberos V5 ("GSSAPI") SASL mechanism      June 2006
 507
 508
 509 Intellectual Property Statement
 510
 511    The IETF takes no position regarding the validity or scope of any
 512    Intellectual Property Rights or other rights that might be claimed to
 513    pertain to the implementation or use of the technology described in
 514    this document or the extent to which any license under such rights
 515    might or might not be available; nor does it represent that it has
 516    made any independent effort to identify any such rights.  Information
 517    on the procedures with respect to rights in RFC documents can be
 518    found in BCP 78 and BCP 79.
 519
 520    Copies of IPR disclosures made to the IETF Secretariat and any
 521    assurances of licenses to be made available, or the result of an
 522    attempt made to obtain a general license or permission for the use of
 523    such proprietary rights by implementers or users of this
 524    specification can be obtained from the IETF on-line IPR repository at
 525    http://www.ietf.org/ipr.
 526
 527    The IETF invites any interested party to bring to its attention any
 528    copyrights, patents or patent applications, or other proprietary
 529    rights that may cover technology that may be required to implement
 530    this standard.  Please address the information to the IETF at
 531    ietf-ipr@ietf.org.
 532
 533
 534 Disclaimer of Validity
 535
 536    This document and the information contained herein are provided on an
 537    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 538    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 539    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 540    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 541    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 542    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 543
 544
 545 Copyright Statement
 546
 547    Copyright (C) The Internet Society (2006).  This document is subject
 548    to the rights, licenses and restrictions contained in BCP 78, and
 549    except as set forth therein, the authors retain all their rights.
 550
 551
 552 Acknowledgment
 553
 554    Funding for the RFC Editor function is currently provided by the
 555    Internet Society.
 556
 557
 558
 559
 560 Melnikov                Expires December 11, 2006              [Page 10]
 561 \f
 562