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

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