1 2 3 4Network Working Group S. Josefsson 5Internet-Draft SJD AB 6Intended status: Standards Track N. Williams 7Expires: September 24, 2009 Sun Microsystems 8 March 23, 2009 9 10 11 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family 12 draft-ietf-sasl-gs2-11 13 14Status of this Memo 15 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may contain material 18 from IETF Documents or IETF Contributions published or made publicly 19 available before November 10, 2008. The person(s) controlling the 20 copyright in some of this material may not have granted the IETF 21 Trust the right to allow modifications of such material outside the 22 IETF Standards Process. Without obtaining an adequate license from 23 the person(s) controlling the copyright in such materials, this 24 document may not be modified outside the IETF Standards Process, and 25 derivative works of it may not be created outside the IETF Standards 26 Process, except to format it for publication as an RFC or to 27 translate it into languages other than English. 28 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 33 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 38 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 41 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 44 45 This Internet-Draft will expire on September 24, 2009. 46 47Copyright Notice 48 49 Copyright (c) 2009 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 51 52 53 54 55Josefsson & Williams Expires September 24, 2009 [Page 1] 56 57Internet-Draft SASL GS2-* March 2009 58 59 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents in effect on the date of 62 publication of this document (http://trustee.ietf.org/license-info). 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. 65 66Abstract 67 68 This document describes how to use a Generic Security Service 69 Application Program Interface (GSS-API) mechanism in the the Simple 70 Authentication and Security Layer (SASL) framework. This is done by 71 defining a new SASL mechanism family, called GS2. This mechanism 72 family offers a number of improvements over the previous "SASL/ 73 GSSAPI" mechanism: it is more general, uses fewer messages for the 74 authentication phase in some cases, and supports negotiable use of 75 channel binding. Only GSS-API mechanisms that support channel 76 binding are supported. 77 78 See <http://josefsson.org/sasl-gs2-*/> for more information. 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 111Josefsson & Williams Expires September 24, 2009 [Page 2] 112 113Internet-Draft SASL GS2-* March 2009 114 115 116Table of Contents 117 118 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 119 2. Conventions used in this document . . . . . . . . . . . . . . 5 120 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5 121 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5 122 3.2. Computing mechanism names manually . . . . . . . . . . . . 5 123 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 124 4. SASL Authentication Exchange Message Format . . . . . . . . . 7 125 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7 126 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 127 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 128 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11 129 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 11 130 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 131 10. GSS_Mechanism_SASLname call . . . . . . . . . . . . . . . . . 11 132 10.1. gss_mechanism_saslname . . . . . . . . . . . . . . . . . . 13 133 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13 134 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 15 135 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 15 136 13. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 16 137 13.1. The interoperability problem . . . . . . . . . . . . . . . 16 138 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 16 139 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16 140 14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17 141 14.1. The interoperability problem . . . . . . . . . . . . . . . 17 142 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17 143 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17 144 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 145 16. Security Considerations . . . . . . . . . . . . . . . . . . . 18 146 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 147 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 148 18.1. Normative References . . . . . . . . . . . . . . . . . . . 19 149 18.2. Informative References . . . . . . . . . . . . . . . . . . 20 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Josefsson & Williams Expires September 24, 2009 [Page 3] 168 169Internet-Draft SASL GS2-* March 2009 170 171 1721. Introduction 173 174 Generic Security Service Application Program Interface (GSS-API) 175 [RFC2743] is a framework that provides security services to 176 applications using a variety of authentication "mechanisms". Simple 177 Authentication and Security Layer (SASL) [RFC4422] is a framework to 178 provide authentication and "security layers" for connection based 179 protocols, also using a variety of mechanisms. This document 180 describes how to use a GSS-API mechanism as though it were a SASL 181 mechanism. This facility is called "GS2" -- a moniker that indicates 182 that this is the second GSS-API->SASL mechanism bridge. The original 183 GSS-API->SASL mechanism bridge was specified by [RFC2222], now 184 [RFC4752]; we shall sometimes refer to the original bridge as "GS1" 185 in this document. 186 187 All GSS-API mechanisms are implicitly registered for use within SASL 188 by this specification. The SASL mechanisms defined in this document 189 are known as the "GS2 family of mechanisms". 190 191 The GS1 bridge failed to gain wide deployment for any GSS-API 192 mechanism other than The "Kerberos V GSS-API mechanism" [RFC1964] 193 [RFC4121], and has a number of problems that lead us to desire a new 194 bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 195 did not support channel binding [RFC5056]. These problems and the 196 opportunity to create the next SASL password-based mechanism, SCRAM 197 [I-D.newman-auth-scram], as a GSS-API mechanism used by SASL 198 applications via GS2, provide the motivation for GS2. 199 200 In particular, the current consensus of the SASL community appears to 201 be that SASL "security layers" (i.e., confidentiality and integrity 202 protection of application data after authentication) are too complex 203 and, since SASL applications tend to have an option to run over a 204 Transport Layer Security (TLS) [RFC5246] channel, redundant and best 205 replaced with channel binding. 206 207 GS2 is designed to be as simple as possible. It adds to GSS-API 208 security context token exchanges only the bare minimum to support 209 SASL semantics and negotiation of use of channel binding. 210 Specifically, GS2 adds a small header (2 bytes or 4 bytes plus the 211 length of the client requested SASL authorization ID (authzid)) to 212 the initial context token and to the application channel binding 213 data, and it uses SASL mechanism negotiation to implement channel 214 binding negotiation. All GS2 plaintext is protected via the use of 215 GSS-API channel binding. Additionally, to simplify the 216 implementation of GS2 mechanisms for implementors who will not 217 implement a GSS-API framework, we compress the initial security 218 context token header required by [RFC2743] (see section 3.1). 219 220 221 222 223Josefsson & Williams Expires September 24, 2009 [Page 4] 224 225Internet-Draft SASL GS2-* March 2009 226 227 2282. Conventions used in this document 229 230 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 231 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 232 document are to be interpreted as described in [RFC2119]. 233 234 2353. Mechanism name 236 2373.1. Generating SASL mechanism names from GSS-API OIDs 238 239 There are two SASL mechanism names for any GSS-API mechanism used 240 through this facility. One denotes that the server supports channel 241 binding. The other denotes that it does not. 242 243 The SASL mechanism name for a GSS-API mechanism is that which is 244 provided by that mechanism when it was specified, if one was 245 specified. This name denotes that the server does not support 246 channel binding. Add the suffix "-PLUS" and the resulting name 247 denotes that the server does support channel binding. SASL 248 implementations can use the GSS_Mechanism_Name call (see below) to 249 query for the SASL mechanism name of a GSS-API mechanism. 250 251 For GSS-API mechanisms whose SASL names are not defined together with 252 the GSS-API mechanism or in this document, the SASL mechanism name is 253 concatenation of the string "GS2-" and the Base32 encoding [RFC4648] 254 (with an upper case alphabet) of the first 55 bits of the binary 255 SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER 256 encoding [CCITT.X690.2002], including the tag and length octets, of 257 the GSS-API mechanism's Object Identifier. The Base32 rules on 258 padding characters and characters outside of the base32 alphabet are 259 not relevant to this use of Base32. If any padding or non-alphabet 260 characters are encountered, the name is not a GS2 family mechanism 261 name. This name denotes that the server does not support channel 262 binding. Add the suffix "-PLUS" and the resulting name denotes that 263 the server does support channel binding. 264 2653.2. Computing mechanism names manually 266 267 The hash-derived GS2 SASL mechanism name may be computed manually. 268 This is useful when the set of supported GSS-API mechanisms is known 269 in advance. It also obliterate the need to implement Base32, SHA-1 270 and DER in the SASL mechanism. The computed mechanism name can be 271 used directly in the implementation, and the implementation need not 272 concern itself with that the mechanism is part of a mechanism family. 273 274 275 276 277 278 279Josefsson & Williams Expires September 24, 2009 [Page 5] 280 281Internet-Draft SASL GS2-* March 2009 282 283 2843.3. Examples 285 286 The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The 287 ASN.1 DER encoding of the OID, including the tag and length, is (in 288 hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER 289 encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 290 27 86 61 ad. Convert the first 7 octets to binary, drop the last 291 bit, and re-group them in groups of 5, and convert them back to 292 decimal, which results in these computations: 293 294 hex: 295 1c f8 f4 2b 5a 9f 80 296 297 binary: 298 00011100 11111000 11110100 00101011 01011010 299 10011111 1000000 300 301 binary in groups of 5: 302 00011 10011 11100 01111 01000 01010 11010 11010 303 10011 11110 00000 304 305 decimal of each group: 306 3 19 28 15 8 10 26 26 19 30 0 307 308 base32 encoding: 309 D T 4 P I K 2 2 T 6 A 310 311 The last step translate each decimal value using table 3 in Base32 312 [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI 313 mechanism is "GS2-DT4PIK22T6A". 314 315 The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is 316 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 317 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 318 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to 319 binary, and re-group them in groups of 5, and convert them back to 320 decimal, which results in these computations: 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Josefsson & Williams Expires September 24, 2009 [Page 6] 336 337Internet-Draft SASL GS2-* March 2009 338 339 340 hex: 341 82 d2 73 25 76 6b d6 342 343 binary: 344 10000010 11010010 01110011 00100101 01110110 345 01101011 1101011 346 347 binary in groups of 5: 348 10000 01011 01001 00111 00110 01001 01011 10110 349 01101 01111 01011 350 351 decimal of each group: 352 16 11 9 7 6 9 11 22 13 15 11 353 354 base32 encoding: 355 Q L J H G J L W N P L 356 357 The last step translate each decimal value using table 3 in Base32 358 [RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI 359 mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism 360 supports channel binding) "GS2-QLJHGJLWNPL-PLUS". But instead, we 361 assign the Kerberos V mechanism a non-hash-derived mechanism name: 362 "KerberosV-GS2" and "KerberosV-GS2-PLUS" (see Section 15). 363 364 3654. SASL Authentication Exchange Message Format 366 3674.1. SASL Messages 368 369 During the SASL authentication exchange for GS2, a number of messages 370 following the following format is sent between the client and server. 371 This number is the same as the number of context tokens that the GSS- 372 API mechanism would normally require in order to establish a security 373 context (or to fail to do so). 374 375 Note that when using a GS2 mechanism the SASL client is always a GSS- 376 API initiator and the SASL server is always a GSS-API acceptor. Thus 377 the SASL client calls GSS_Init_sec_context() and the server calls 378 GSS_Accept_sec_context(). 379 380 All the SASL authentication messages exchanged are exactly the same 381 as the security context tokens of the GSS-API mechanism, except for 382 the initial security context token. 383 384 Also, the server SHOULD refrain from sending GSS-API error tokens 385 (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context() 386 along with a major status code other than GSS_S_COMPLETE or 387 GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions. 388 389 390 391Josefsson & Williams Expires September 24, 2009 [Page 7] 392 393Internet-Draft SASL GS2-* March 2009 394 395 396 The initial security context token is modified as follows: 397 o The [RFC2743] section 3.1 initial context token header MUST be 398 removed if present, and its presence is noted (see below). On the 399 server side this header MUST be recomputed and restored prior to 400 passing the token to GSS_Accept_sec_context(). 401 o A GS2 header MUST be prefixed to the resulting initial context 402 token. This header has the form given below in ABNF [RFC5234]. 403 404 UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F 405 ;; As UTF8-1 in RFC 3629 except 406 ;; NUL, "=", and ",". 407 UTF8-2 = <as defined in RFC 3629 (STD 63)> 408 UTF8-3 = <as defined in RFC 3629 (STD 63)> 409 UTF8-4 = <as defined in RFC 3629 (STD 63)> 410 UTF8-char-safe = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4 411 412 saslname = 1*(UTF8-char-safe / "=2C" / "=3D") 413 gs2-authzid = "a=" saslname 414 ;; GS2 has to transport an authzid since 415 ;; the GSS-API has no equivalent 416 gs2-std-mech = "F" 417 ;; "F" means the mechanism is NOT is a 418 ;; standard GSS-API mechanism in that the 419 ;; RFC2743 section 3.1 header was missing 420 gs2-cb-flag = "n" / "y" / "p" 421 ;; GS2 channel binding (CB) flag 422 ;; "n" -> client does not support CB 423 ;; "y" -> client supports CB, thinks the server 424 ;; does not 425 ;; "p" -> client supports and used CB 426 gs2-header = [gs2-std-mech] gs2-cb-flag [gs2-authzid] "," 427 ;; The GS2 header is gs2-header. 428 ;; gs2-std-mech is present if the GSS-API 429 ;; mechanism's initial context token did not 430 ;; have the standard header defined in 431 ;; [RFC2743] section 3.1. 432 433 The GS2 header is also prepended to the application's channel binding 434 data. If the application did not provide channel binding data then 435 the GS2 header is used as though it were application-provided channel 436 binding data. 437 438 The "gs2-authzid" holds the SASL authorization identity. It is 439 encoded using UTF-8 [RFC3629] with three exceptions: 440 o The NUL characters is forbidden as required by section 3.4.1 of 441 [RFC4422]. 442 443 444 445 446 447Josefsson & Williams Expires September 24, 2009 [Page 8] 448 449Internet-Draft SASL GS2-* March 2009 450 451 452 o The server MUST replace any occurance of "," (comma) in the string 453 with "=2C". 454 o The server MUST replace any occurance of "=" (comma) in the string 455 with "=3D". 456 457 If a server sends a string that does not conform to this syntax, the 458 client MUST reject authentication. 459 460 4615. Channel Bindings 462 463 If the server supports channel binding then it must list both forms 464 of the SASL mechanism name for each GSS-API mechanism supported via 465 GS2 (i.e., GSS-API mechanisms that support channel binding). 466 467 If the client supports channel binding and the server does not (i.e., 468 the server did not advertise the -PLUS names) then the client MUST 469 either fail authentication or it MUST set the channel binding flag in 470 the GS2 initial security context token to "y" and MUST NOT include 471 application channel binding data in the GSS-API channel binding input 472 to GSS_Init_sec_context(). 473 474 If the client supports channel binding and the server also does then 475 the client MUST set the channel binding flag in the GS2 initial 476 security context token to "p" and MUST include application channel 477 binding data in the GSS-API channel binding input to 478 GSS_Init_sec_context(). 479 480 If the client does not support channel binding then it MUST set the 481 channel binding flag in the GS2 initial security context token to "n" 482 and MUST NOT include application channel binding data in the GSS-API 483 channel binding input to GSS_Init_sec_context(). 484 485 Upon receipt of the initial authentication message the server checks 486 the channel binding flag in the GS2 header and constructs a channel 487 binding data input for GSS_Accept_sec_context() accordingly. If the 488 client channel binding flag was "n" then the server MUST NOT include 489 application channel binding data in the GSS-API channel binding input 490 to GSS_Accept_sec_context(). If the client channel binding flag was 491 "y" and the server does support channel binding then the server MUST 492 fail authentication. If the client channel binding flag was "p" the 493 server MUST include application channel binding data in the GSS-API 494 channel binding input to GSS_Accept_sec_context(). 495 496 For more discussions of channel bindings, and the syntax of the 497 channel binding data for various security protocols, see [RFC5056]. 498 499 500 501 502 503Josefsson & Williams Expires September 24, 2009 [Page 9] 504 505Internet-Draft SASL GS2-* March 2009 506 507 5086. Examples 509 510 Example #1: a one round-trip GSS-API context token exchange, no 511 channel binding, optional authzid given. 512 513 C: Request authentication exchange 514 S: Empty Challenge 515 C: nauthzid=someuser, <initial context token with standard 516 header removed> 517 S: Send reply context token as is 518 C: Empty message 519 S: Outcome of authentication exchange 520 521 Example #2: a one and one half round-trip GSS-API context token 522 exchange. 523 524 C: Request authentication exchange 525 S: Empty Challenge 526 C: nauthzid=someuser, <initial context token with standard 527 header removed> 528 S: Send reply context token as is 529 C: Send reply context token as is 530 S: Outcome of authentication exchange 531 532 Example #3: a two round-trip GSS-API context token exchange. 533 534 C: Request authentication exchange 535 S: Empty Challenge 536 C: nauthzid=someuser, <initial context token with standard 537 header removed> 538 S: Send reply context token as is 539 C: Send reply context token as is 540 S: Send reply context token as is 541 C: Empty message 542 S: Outcome of authentication exchange 543 544 Example #4: using channel binding. 545 546 C: Request authentication exchange 547 S: Empty Challenge 548 C: yauthzid=someuser, <initial context token with standard 549 header removed> 550 S: Send reply context token as is 551 ... 552 553 GSS-API authentication is always initiated by the client. The SASL 554 framework allows either the client and server to initiate 555 authentication. In GS2 the server will send an initial empty 556 557 558 559Josefsson & Williams Expires September 24, 2009 [Page 10] 560 561Internet-Draft SASL GS2-* March 2009 562 563 564 challenge (zero byte string) if it has not yet received a token from 565 the client. See section 3 of [RFC4422]. 566 567 5687. Authentication Conditions 569 570 Authentication MUST NOT succeed if any one of the following 571 conditions are true: 572 573 o GSS_Init/Accept_sec_context() return anything other than 574 GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. 575 o If the client's GS2 channel binding flag was "y" and the server 576 supports channel binding. 577 o If the client requires use of channel binding and the server did 578 not advertise support for channel binding. 579 o Authorization of client principal (i.e., src_name in 580 GSS_Accept_sec_context()) to requested authzid failed. 581 o If the client is not authorized to the requested authzid or an 582 authzid could not be derived from the client's initiator principal 583 name. 584 585 5868. GSS-API Parameters 587 588 GS2 does not use any GSS-API per-message tokens. Therefore the 589 setting of req_flags related to per-message tokens is irrelevant. 590 591 5929. Naming 593 594 There's no requirement that any particular GSS-API name-types be 595 used. However, typically SASL servers will have host-based acceptor 596 principal names (see [RFC2743] section 4.1) and clients will 597 typically have username initiator principal names (see [RFC2743] 598 section 4.2). 599 600 60110. GSS_Mechanism_SASLname call 602 603 To allow SASL implementations to query for the SASL mechanism name of 604 a GSS-API mechanism, we specify a new GSS-API function for this 605 purpose. 606 607 608 609 610 611 612 613 614 615Josefsson & Williams Expires September 24, 2009 [Page 11] 616 617Internet-Draft SASL GS2-* March 2009 618 619 620 Inputs: 621 622 o desired_mech OBJECT IDENTIFIER 623 624 Outputs: 625 626 o sasl_mech_name OCTET STRING -- SASL name for this mechanism 627 (really, ASCII) 628 629 o mech_name UTF-8 STRING -- name of this mechanism, possibly 630 localized 631 632 o mech_description UTF-8 STRING -- possibly localized 633 description of this mechanism. 634 635 Return major_status codes: 636 637 o GSS_S_COMPLETE indicates successful completion, and that output 638 parameters holds correct information. 639 640 o GSS_S_BAD_MECH indicates that a disred_mech was unsupported by 641 the GSS-API implementation. 642 643 The GSS_Mechanism_SASLname call is used to get the SASL mechanism 644 name for a GSS-API mechanism. It also returns a name and 645 description of the mechanism in a human readable form. 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671Josefsson & Williams Expires September 24, 2009 [Page 12] 672 673Internet-Draft SASL GS2-* March 2009 674 675 67610.1. gss_mechanism_saslname 677 678 The C binding for the GSS_Mechanism_SASLname call is as follows. 679 680 OM_uint32 gss_mechanism_saslname( 681 OM_uint32 *minor_status, 682 const gss_OID desired_mech, 683 gss_buffer_t sasl_mech_name, 684 gss_buffer_t mech_name, 685 gss_buffer_t mech_description, 686 ); 687 688 Purpose: 689 690 Output the SASL mechanism name of a GSS-API mechanism. Also output 691 a name and description of the mechanism in a human readable form. 692 693 Parameters: 694 695 minor_status Integer, modify 696 Mechanism specific status code. 697 698 Function value: GSS status code 699 700 GSS_S_COMPLETE Successful completion 701 702 GSS_S_BAD_MECH The desired_mech OID is unsupported 703 704 70511. GSS_Inquire_mech_for_SASLname call 706 707 To allow SASL clients to more efficiently identify which GSS-API 708 mechanism a particular SASL mechanism name refers to we specify a new 709 GSS-API utility function for this purpose. 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727Josefsson & Williams Expires September 24, 2009 [Page 13] 728 729Internet-Draft SASL GS2-* March 2009 730 731 732 Inputs: 733 734 o sasl_mech_name OCTET STRING -- SASL name of mechanism 735 (really, ASCII) 736 737 Outputs: 738 739 o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, 740 and not "default" specifier 741 742 Return major_status codes: 743 744 o GSS_S_COMPLETE indicates successful completion, and that output 745 parameters holds correct information. 746 747 o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism 748 had the indicated sasl_mech_name. 749 750 The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API 751 mechanism OID associated with a SASL mechanism name. 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783Josefsson & Williams Expires September 24, 2009 [Page 14] 784 785Internet-Draft SASL GS2-* March 2009 786 787 78811.1. gss_inquire_mech_for_saslname 789 790 The C binding for the GSS_Inquire_mech_for_SASLname call is as 791 follows. 792 793 OM_uint32 gss_inquire_mech_for_saslname( 794 OM_uint32 *minor_status, 795 const gss_buffer_t sasl_mech_name, 796 gss_OID *mech_type 797 ); 798 799 Purpose: 800 801 Output GSS-API mechanism OID of mechanism associated with given 802 sasl_mech_name. 803 804 Parameters: 805 806 minor_status Integer, modify 807 Mechanism specific status code. 808 809 Function value: GSS status code 810 811 GSS_S_COMPLETE Successful completion 812 813 GSS_S_BAD_MECH The desired_mech OID is unsupported 814 815 81612. Security Layers 817 818 GS2 does not currently support SASL security layers. Applications 819 that need integrity protection or confidentiality and integrity 820 protection MUST use either channel binding to a secure external 821 channel or a SASL mechanism that does provide security layers. 822 823 NOTE WELL: the GS2 client's first authentication message MUST always 824 start with "F", "n", "y" or "p", otherwise the server MUST fail 825 authentication. This will allow us to add support for security 826 layers in the future if it were to become necessary. Note that 827 adding security layer support to GS2 must not break existing SASL/GS2 828 applications, which can be accomplished by making security layers 829 optional. 830 831 [A sketch of how to add sec layer support... Add a way for the 832 client to: a) make an offer of sec layers and max buffer, b) make an 833 opportunistic selection of sec layer and buffer size, both in the 834 first client authentication message, and starting with a character 835 other than "F", "n", "y" or "p". The server could accept the 836 837 838 839Josefsson & Williams Expires September 24, 2009 [Page 15] 840 841Internet-Draft SASL GS2-* March 2009 842 843 844 opportunistic proposal (reply token prefixed with a byte indicating 845 acceptance) or reject it along with an indication of the server's 846 acceptable sec layers and max buffer size. In the latter case the 847 GSS-API security context token exchange must be abandoned and 848 recommenced, although this would be a detail of the GS2 bridge not 849 exposed to the SASL application. The negotiation would be protected 850 via GSS channel binding, as with the rest of GS2.] 851 852 85313. Interoperability with the SASL "GSSAPI" mechanism 854 855 The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL 856 under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The 857 Kerberos V5 mechanism may also be used with the GS2 family. This 858 causes an interopability problem, which is discussed and resolved 859 below. 860 86113.1. The interoperability problem 862 863 The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos 864 V GSS-API mechanism used as a SASL GS2 mechanism. 865 866 If a client (or server) only support Kerberos V5 under the "GSSAPI" 867 name and the server (or client) only support Kerberos V5 under the 868 GS2 family, the mechanism negotiation will fail. 869 87013.2. Resolving the problem 871 872 If the Kerberos V5 mechanism is supported under GS2 in a server, the 873 server SHOULD also support Kerberos V5 through the "GSSAPI" 874 mechanism, to avoid interoperability problems with older clients. 875 876 Reasons for violating this recommendation may include security 877 considerations regarding the absent features in the GS2 mechanism. 878 The SASL "GSSAPI" mechanism lacks support for channel bindings, which 879 means that using an external secure channel may not be sufficient 880 protection against active attackers (see [RFC5056], [mitm]). 881 88213.3. Additional Recommendations 883 884 If the application requires security layers then it MUST prefer the 885 SASL "GSSAPI" mechanism over "KerberosV-GS2". 886 887 If the application can use channel binding to an external channel 888 then it is RECOMMENDED that it select Kerberos V5 through the GS2 889 mechanism rather than the "GSSAPI" mechanism. 890 891 892 893 894 895Josefsson & Williams Expires September 24, 2009 [Page 16] 896 897Internet-Draft SASL GS2-* March 2009 898 899 90014. Mechanisms that negotiate other mechanisms 901 902 A GSS-API mechanism that negotiate other mechanisms interact badly 903 with the SASL mechanism negotiation. There are two problems. The 904 first is an interoperability problem and the second is a security 905 concern. The problems are described and resolved below. 906 90714.1. The interoperability problem 908 909 If a client implement GSS-API mechanism X, potentially negotiated 910 through a GSS-API mechanism Y, and the server also implement GSS-API 911 mechanism X negotiated through a GSS-API mechanism Z, the 912 authentication negotiation will fail. 913 91414.2. Security problem 915 916 If a client's policy is to first prefer GSSAPI mechanism X, then non- 917 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports 918 mechanisms Y and Z but not X, then if the client attempts to 919 negotiate mechanism X by using a GSS-API mechanism that negotiate 920 other mechanisms (such as SPNEGO), it may end up using mechanism Z 921 when it ideally should have used mechanism Y. For this reason, the 922 use of GSS-API mechanisms that negotiate other mechanisms are 923 disallowed under GS2. 924 92514.3. Resolving the problems 926 927 GSS-API mechanisms that negotiate other mechanisms MUST NOT be used 928 with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT 929 be used as a GS2 mechanism. To make this easier for SASL 930 implementations we assign a symbolic SASL mechanism name to the 931 SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST 932 NOT choose the SPNEGO mechanism under any circumstances. [What about 933 SASL apps that don't do mechanism negotiation? Probably none exist. 934 But if any did then presumably it would OK to use the SPNEGO 935 mechanism, no? -Nico] 936 937 The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() 938 [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such 939 mechanisms. 940 941 94215. IANA Considerations 943 944 The SASL names for the Kerberos V GSS-API mechanism [RFC4121] 945 [RFC1964] used via GS2 SHALL be "KerberosV-GS2" and "KerberosV-GS2- 946 PLUS". 947 948 949 950 951Josefsson & Williams Expires September 24, 2009 [Page 17] 952 953Internet-Draft SASL GS2-* March 2009 954 955 956 The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be 957 "SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL 958 "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are 959 provided as a convienience for SASL library implementors. 960 961 The IANA is advised that SASL mechanism names starting with "GS2-" 962 are reserved for SASL mechanisms which conform to this document. The 963 IANA is directed to place a statement to that effect in the sasl- 964 mechanisms registry. 965 966 The IANA is further advised that SASL mechanisms MUST NOT end in 967 "-PLUS" except as a version of another mechanism name simply suffixed 968 with "-PLUS". 969 970 Subject: Registration of SASL mechanism GS2-* 971 SASL mechanism prefix: GS2- 972 Security considerations: RFC [THIS-DOC] 973 Published specification: RFC [THIS-DOC] 974 Person & email address to contact for further information: 975 Simon Josefsson <simon@josefsson.org> 976 Intended usage: COMMON 977 Owner/Change controller: iesg@ietf.org 978 Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. 979 980 98116. Security Considerations 982 983 Security issues are also discussed throughout this memo. 984 985 The security provided by a GS2 mechanism depends on the security of 986 the GSS-API mechanism. The GS2 mechanism family depends on channel 987 binding support, so GSS-API mechanisms that do not support channel 988 binding cannot be successfully used as SASL mechanisms via the GS2 989 bridge. 990 991 Because GS2 does not support security layers it is strongly 992 RECOMMENDED that channel binding to a secure external channel be 993 used. Successful channel binding eliminates the possibility of man- 994 in-the-middle (MITM) attacks, provided that the external channel and 995 its channel binding data are secure and provided that the GSS-API 996 mechanism used is secure. Authentication failure because of channel 997 binding failure may indicate that an MITM attack was attempted, but 998 note that a real MITM attacker would likely attempt to close the 999 connection to the client or simulate network partition , thus MITM 1000 attack detection is heuristic. 1001 1002 Use of channel binding will also protect the SASL mechanism 1003 negotiation -- if there is no MITM then the external secure channel 1004 1005 1006 1007Josefsson & Williams Expires September 24, 2009 [Page 18] 1008 1009Internet-Draft SASL GS2-* March 2009 1010 1011 1012 will have protected the SASL mechanism negotiation. 1013 1014 The channel binding data MAY be sent (byt the actual GSS-API 1015 mechanism used) without confidentiality protection and knowledge of 1016 it is assumed to provide no advantage to an MITM (who can, in any 1017 case, compute the channel binding data independently). If the 1018 external channel does not provide confidentiality protection and the 1019 GSS-API mechanism does not provide confidentiality protection for the 1020 channel binding data, then passive attackers (eavesdroppers) can 1021 recover the channel binding data. See [RFC5056]. 1022 1023 When constructing the input_name_string for GSS_Import_name() with 1024 the GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT 1025 canonicalize the server's fully qualified domain name using an 1026 insecure or untrusted directory service, such as the Domain Name 1027 System [RFC1034] without DNSSEC [RFC4033]. 1028 1029 GS2 does not directly use any cryptographic algorithms, therefore it 1030 is automatically "algorithm agile", or, as agile as the GSS-API 1031 mechanisms that are available for use in SASL apoplications via GS2. 1032 1033 The security considerations of SASL [RFC4422], the GSS-API [RFC2743], 1034 channel binding [RFC5056], any external channels (such as TLS, 1035 [RFC5246], channel binding types (see the IANA channel binding type 1036 registry), and GSS-API mechanisms (such as the Kerberos V mechanism 1037 [RFC4121] [RFC1964]), may also apply. 1038 1039 104017. Acknowledgements 1041 1042 The history of GS2 can be traced to the "GSSAPI" mechanism originally 1043 specified by RFC2222. This document was derived from 1044 draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with 1045 significant contributions from John G. Myers, although the majority 1046 of this document has been rewritten by the current authors. 1047 1048 Contributions of many members of the SASL mailing list are gratefully 1049 acknowledged. In particular, ideas and feedback from Sam Hartman, 1050 Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document 1051 and the protocol. 1052 1053 105418. References 1055 105618.1. Normative References 1057 1058 [FIPS.180-1.1995] 1059 National Institute of Standards and Technology, "Secure 1060 1061 1062 1063Josefsson & Williams Expires September 24, 2009 [Page 19] 1064 1065Internet-Draft SASL GS2-* March 2009 1066 1067 1068 Hash Standard", FIPS PUB 180-1, April 1995, 1069 <http://www.itl.nist.gov/fipspubs/fip180-1.htm>. 1070 1071 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1072 Requirement Levels", BCP 14, RFC 2119, March 1997. 1073 1074 [RFC2743] Linn, J., "Generic Security Service Application Program 1075 Interface Version 2, Update 1", RFC 2743, January 2000. 1076 1077 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1078 10646", STD 63, RFC 3629, November 2003. 1079 1080 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1081 Security Layer (SASL)", RFC 4422, June 2006. 1082 1083 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1084 Encodings", RFC 4648, October 2006. 1085 1086 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1087 Channels", RFC 5056, November 2007. 1088 1089 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1090 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1091 1092 [CCITT.X690.2002] 1093 International International Telephone and Telegraph 1094 Consultative Committee, "ASN.1 encoding rules: 1095 Specification of basic encoding Rules (BER), Canonical 1096 encoding rules (CER) and Distinguished encoding rules 1097 (DER)", CCITT Recommendation X.690, July 2002. 1098 109918.2. Informative References 1100 1101 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1102 STD 13, RFC 1034, November 1987. 1103 1104 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1105 RFC 1964, June 1996. 1106 1107 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 1108 (SPKM)", RFC 2025, October 1996. 1109 1110 [RFC2222] Myers, J., "Simple Authentication and Security Layer 1111 (SASL)", RFC 2222, October 1997. 1112 1113 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1114 Rose, "DNS Security Introduction and Requirements", 1115 RFC 4033, March 2005. 1116 1117 1118 1119Josefsson & Williams Expires September 24, 2009 [Page 20] 1120 1121Internet-Draft SASL GS2-* March 2009 1122 1123 1124 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 1125 Version 5 Generic Security Service Application Program 1126 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 1127 July 2005. 1128 1129 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 1130 Simple and Protected Generic Security Service Application 1131 Program Interface (GSS-API) Negotiation Mechanism", 1132 RFC 4178, October 2005. 1133 1134 [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple 1135 Authentication and Security Layer (SASL) Mechanism", 1136 RFC 4752, November 2006. 1137 1138 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1139 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1140 1141 [I-D.newman-auth-scram] 1142 Menon-Sen, A., Melnikov, A., and C. Newman, "Salted 1143 Challenge Response (SCRAM) SASL Mechanism", 1144 draft-newman-auth-scram-10 (work in progress), 1145 February 2009. 1146 1147 [I-D.ietf-kitten-extended-mech-inquiry] 1148 Williams, N., "Extended Generic Security Service Mechanism 1149 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-04 1150 (work in progress), March 2008. 1151 1152 [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1153 in Tunneled Authentication", 1154 WWW http://www.saunalahti.fi/~asokan/research/mitm.html. 1155 1156 1157Authors' Addresses 1158 1159 Simon Josefsson 1160 SJD AB 1161 Hagagatan 24 1162 Stockholm 113 47 1163 SE 1164 1165 Email: simon@josefsson.org 1166 URI: http://josefsson.org/ 1167 1168 1169 1170 1171 1172 1173 1174 1175Josefsson & Williams Expires September 24, 2009 [Page 21] 1176 1177Internet-Draft SASL GS2-* March 2009 1178 1179 1180 Nicolas Williams 1181 Sun Microsystems 1182 5300 Riata Trace Ct 1183 Austin, TX 78727 1184 USA 1185 1186 Email: Nicolas.Williams@sun.com 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231Josefsson & Williams Expires September 24, 2009 [Page 22] 1232 1233