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

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