idnits 2.17.1 draft-ietf-sasl-gs2-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 9, 2010) is 5214 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'THIS-DOC' is mentioned on line 823, but not defined -- Obsolete informational reference (is this intentional?): RFC 2222 (Obsoleted by RFC 4422, RFC 4752) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-11) exists of draft-ietf-sasl-scram-10 == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-07 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft SJD AB 4 Intended status: Standards Track N. Williams 5 Expires: July 13, 2010 Sun Microsystems 6 January 9, 2010 8 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family 9 draft-ietf-sasl-gs2-20 11 Abstract 13 This document describes how to use a Generic Security Service 14 Application Program Interface (GSS-API) mechanism in the the Simple 15 Authentication and Security Layer (SASL) framework. This is done by 16 defining a new SASL mechanism family, called GS2. This mechanism 17 family offers a number of improvements over the previous "SASL/ 18 GSSAPI" mechanism: it is more general, uses fewer messages for the 19 authentication phase in some cases, and supports negotiable use of 20 channel binding. Only GSS-API mechanisms that support channel 21 binding are supported. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on July 13, 2010. 46 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Conventions used in this document . . . . . . . . . . . . . . 4 77 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 4 79 3.2. Computing mechanism names manually . . . . . . . . . . . . 5 80 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 6 82 4. SASL Authentication Exchange Message Format . . . . . . . . . 6 83 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 84 5.1. Content of GSS-CHANNEL-BINDINGS structure . . . . . . . . 10 85 5.2. Default Channel Binding . . . . . . . . . . . . . . . . . 10 86 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 12 88 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 13 89 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 90 10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 14 91 10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 15 92 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 15 93 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 17 94 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 17 95 13. Interoperability with the SASL GSSAPI mechanism . . . . . . . 17 96 13.1. The interoperability problem . . . . . . . . . . . . . . . 17 97 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 18 98 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 18 99 14. GSS-API Mechanisms that negotiate other mechanisms . . . . . . 18 100 14.1. The interoperability problem . . . . . . . . . . . . . . . 18 101 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 18 102 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 19 103 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 104 16. Security Considerations . . . . . . . . . . . . . . . . . . . 20 105 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 106 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 18.1. Normative References . . . . . . . . . . . . . . . . . . . 21 108 18.2. Informative References . . . . . . . . . . . . . . . . . . 22 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 111 1. Introduction 113 Generic Security Service Application Program Interface (GSS-API) 114 [RFC2743] is a framework that provides security services to 115 applications using a variety of authentication mechanisms. Simple 116 Authentication and Security Layer (SASL) [RFC4422] is a framework to 117 provide authentication and security layers for connection based 118 protocols, also using a variety of mechanisms. This document 119 describes how to use a GSS-API mechanism as though it were a SASL 120 mechanism. This facility is called GS2 -- a moniker that indicates 121 that this is the second GSS-API->SASL mechanism bridge. The original 122 GSS-API->SASL mechanism bridge was specified by [RFC2222], now 123 [RFC4752]; we shall sometimes refer to the original bridge as GS1 in 124 this document. 126 All GSS-API mechanisms are implicitly registered for use within SASL 127 by this specification. The SASL mechanisms defined in this document 128 are known as the GS2 family of mechanisms. 130 The GS1 bridge failed to gain wide deployment for any GSS-API 131 mechanism other than "The Kerberos V5 GSS-API mechanism" [RFC1964] 132 [RFC4121], and has a number of problems that led us to desire a new 133 bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 134 did not support channel binding [RFC5056]. These problems and the 135 opportunity to create the next SASL password-based mechanism, Salted 136 Challenge Response (SCRAM) SASL and GSS-API Mechanism 137 [I-D.ietf-sasl-scram], as a GSS-API mechanism used by SASL 138 applications via GS2, provide the motivation for GS2. 140 In particular, the current consensus of the SASL community appears to 141 be that SASL "security layers" (i.e., confidentiality and integrity 142 protection of application data after authentication) are too complex 143 and redundant because SASL applications tend to have an option to run 144 over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL 145 security layers is best replaced with channel binding to a TLS 146 channel. 148 GS2 is designed to be as simple as possible. It adds to GSS-API 149 security context token exchanges only the bare minimum to support 150 SASL semantics and negotiation of use of channel binding. 151 Specifically, GS2 adds a small header (a few bytes plus the length of 152 the client requested SASL authorization identity) to the initial GSS- 153 API context token and to the application channel binding data. GS2 154 uses SASL mechanism negotiation to implement channel binding 155 negotiation. All GS2 plaintext is protected via the use of GSS-API 156 channel binding. Additionally, to simplify the implementation of GS2 157 mechanisms for implementors who will not implement a GSS-API 158 framework, we compress the initial security context token header 159 required by [RFC2743] (see section 3.1). 161 2. Conventions used in this document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 The document uses many terms and function names defined in [RFC2743] 168 as updated by [RFC5554]. 170 3. Mechanism name 172 There are two SASL mechanism names for any GSS-API mechanism used 173 through this facility. One denotes that the server supports channel 174 binding. The other denotes that it does not. 176 The SASL mechanism name for a GSS-API mechanism is that which is 177 provided by that mechanism when it was specified, if one was 178 specified. This name denotes that the server does not support 179 channel binding. Add the suffix "-PLUS" and the resulting name 180 denotes that the server does support channel binding. SASL 181 implementations can use the GSS_Inquire_SASLname_for_mech call (see 182 below) to query for the SASL mechanism name of a GSS-API mechanism. 184 If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 185 implementation needs some other mechanism to map mechanism OIDs to 186 SASL names internally. In this case, the implementation can only 187 support the mechanisms for which it knows the SASL name. If the 188 GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation 189 cannot map the OID to a SASL mechanism name using some other means, 190 it cannot use the particular GSS-API mechanism since it does not know 191 its SASL mechanism name. 193 3.1. Generating SASL mechanism names from GSS-API OIDs 195 For GSS-API mechanisms whose SASL names are not defined together with 196 the GSS-API mechanism or in this document, the SASL mechanism name is 197 concatenation of the string "GS2-" and the Base32 encoding [RFC4648] 198 (with an upper case alphabet) of the first 55 bits of the binary 199 SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER 200 encoding [CCITT.X690.2002], including the tag and length octets, of 201 the GSS-API mechanism's Object Identifier. The Base32 rules on 202 padding characters and characters outside of the Base32 alphabet are 203 not relevant to this use of Base32. If any padding or non-alphabet 204 characters are encountered, the name is not a GS2 family mechanism 205 name. This name denotes that the server does not support channel 206 binding. Add the suffix "-PLUS" and the resulting name denotes that 207 the server does support channel binding. 209 A GS2 mechanism that has a non-OID-derived SASL mechanism name is 210 said to have a "user friendly SASL mechanism name". 212 3.2. Computing mechanism names manually 214 The hash-derived GS2 SASL mechanism name may be computed manually. 215 This is useful when the set of supported GSS-API mechanisms is known 216 in advance. This eliminates the need to implement Base32, SHA-1 and 217 DER in the SASL mechanism. The computed mechanism name can be used 218 directly in the implementation, and the implementation need not be 219 concerned if the mechanism is part of a mechanism family. 221 3.3. Examples 223 The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The 224 ASN.1 DER encoding of the OID, including the tag and length, is (in 225 hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER 226 encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 227 27 86 61 ad. Convert the first 7 octets to binary, drop the last 228 bit, and re-group them in groups of 5, and convert them back to 229 decimal, which results in these computations: 231 hex: 232 1c f8 f4 2b 5a 9f 80 234 binary: 235 00011100 11111000 11110100 00101011 01011010 236 10011111 1000000 238 binary in groups of 5: 239 00011 10011 11100 01111 01000 01010 11010 11010 240 10011 11110 00000 242 decimal of each group: 243 3 19 28 15 8 10 26 26 19 30 0 245 base32 encoding: 246 D T 4 P I K 2 2 T 6 A 248 The last step translates each decimal value using table 3 in Base32 249 [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI 250 mechanism is "GS2-DT4PIK22T6A". 252 The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is 253 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 254 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 255 93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop 256 the last bit, and re-group them in groups of 5, and convert them back 257 to decimal, which results in these computations: 259 hex: 260 82 d2 73 25 76 6b d6 262 binary: 263 10000010 11010010 01110011 00100101 01110110 264 01101011 1101011 266 binary in groups of 5: 267 10000 01011 01001 00111 00110 01001 01011 10110 268 01101 01111 01011 270 decimal of each group: 271 16 11 9 7 6 9 11 22 13 15 11 273 base32 encoding: 274 Q L J H G J L W N P L 276 The last step translates each decimal value using table 3 in Base32 277 [RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI 278 mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism 279 supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next 280 section assigns the Kerberos V5 mechanism a non-hash-derived 281 mechanism name. 283 3.4. Grandfathered mechanism names 285 Some older GSS-API mechanisms were not specified with a SASL GS2 286 mechanism name. Using a shorter name can be useful nonetheless. We 287 specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5 288 mechanism, to be used as if the original specification documented it. 289 See Section 15. 291 4. SASL Authentication Exchange Message Format 293 During the SASL authentication exchange for GS2, a number of messages 294 following the following format is sent between the client and server. 295 On success, this number is the same as the number of context tokens 296 that the GSS-API mechanism would normally require in order to 297 establish a security context. On failures, the exchange can be 298 terminated early by any party. 300 When using a GS2 mechanism the SASL client is always a GSS-API 301 initiator and the SASL server is always a GSS-API acceptor. The 302 client calls GSS_Init_sec_context and the server calls 303 GSS_Accept_sec_context. 305 All the SASL authentication messages exchanged are exactly the same 306 as the security context tokens of the GSS-API mechanism, except for 307 the initial security context token. 309 The client and server MAY send GSS-API error tokens (tokens output by 310 GSS_Init_sec_context() or GSS_Accept_sec_context() when the major 311 status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED). 312 As this indicates an error condition, after sending the token, the 313 sending side should fail the authentication. 315 The initial security context token is modified as follows: 316 o The initial context token header (see section 3.1 of [RFC2743]) 317 MUST be removed if present. If the header is not present, the 318 client MUST send a "gs2-nonstd-flag" flag (see below). On the 319 server side this header MUST be recomputed and restored prior to 320 passing the token to GSS_Accept_sec_context, except when the "gs2- 321 nonstd-flag" is sent. 322 o A GS2 header MUST be prefixed to the resulting initial context 323 token. This header has the form "gs2-header" given below in ABNF 324 [RFC5234]. 326 The figure below describes the permissible attributes, their use, and 327 the format of their values. All attribute names are single US-ASCII 328 letters and are case-sensitive. 330 UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F 331 ;; As UTF8-1 in RFC 3629 except 332 ;; NUL, "=", and ",". 333 UTF8-2 = 334 UTF8-3 = 335 UTF8-4 = 336 UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4 338 saslname = 1*(UTF8-char-safe / "=2C" / "=3D") 339 gs2-authzid = "a=" saslname 340 ;; GS2 has to transport an authzid since 341 ;; the GSS-API has no equivalent 342 gs2-nonstd-flag = "F" 343 ;; "F" means the mechanism is not a 344 ;; standard GSS-API mechanism in that the 345 ;; RFC2743 section 3.1 header was missing 346 cb-name = 1*(ALPHA / DIGIT / "." / "-") 347 ;; See RFC 5056 section 7 348 gs2-cb-flag = ("p=" cb-name) / "n" / "y" 349 ;; GS2 channel binding (CB) flag 350 ;; "p" -> client supports and used CB 351 ;; "n" -> client does not support CB 352 ;; "y" -> client supports CB, thinks the server 353 ;; does not 354 gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] "," 355 ;; The GS2 header is gs2-header. 357 When the "gs2-nonstd-flag" flag is present, the client did not find/ 358 remove a token header ([RFC2743] section 3.1) from the initial token 359 returned by GSS_Init_sec_context. This signals to the server that it 360 MUST NOT re-add the data that is normally removed by the client. 362 The "gs2-cb-flag" signals the channel binding mode. One of "p", "n", 363 or "y" is used. A "p" means the client supports and used a channel 364 binding, and the name of the channel binding type is indicated. A 365 "n" means that the client does not support channel binding. A "y" 366 means the client supports channel binding, but believes the server 367 does not support it, so it did not use a channel binding. See the 368 next section for more details. 370 The "gs2-authzid" holds the SASL authorization identity. It is 371 encoded using UTF-8 [RFC3629] with three exceptions: 372 o The NUL character is forbidden as required by section 3.4.1 of 373 [RFC4422]. 374 o The server MUST replace any "," (comma) in the string with "=2C". 375 o The server MUST replace any "=" (equals) in the string with "=3D". 376 Upon receipt of this value the server verifies its correctness 377 according to the used SASL protocol profile. Failed verification 378 results in a failed authentication exchange. 380 5. Channel Bindings 382 GS2 supports channel binding to external secure channels, such as 383 TLS. Clients and servers may or may not support channel binding, 384 therefore the use of channel binding is negotiable. GS2 does not 385 provide security layers, however, therefore it is imperative that GS2 386 provide integrity protection for the negotiation of channel binding. 388 Use of channel binding is negotiated as follows: 389 o Servers SHOULD advertise both non-PLUS and the PLUS-variant of 390 each GS2 mechanism name. If the server cannot support channel 391 binding, it MAY advertise only the non-PLUS variant. If the 392 server would never succeed authentication of the non-PLUS variant 393 due to policy reasons, it MAY advertise only the PLUS-variant. 394 o If the client negotiates mechanisms then clients MUST select the 395 PLUS-variant if offered by the server. Otherwise (the client does 396 not negotiate mechanisms), if the client has no prior knowledge 397 about mechanisms supported by the server and wasn't explicitly 398 configured to use a particular variant of the GS2 mechanism, then 399 it MUST select only non-PLUS version of the GS2 mechanism. 400 o If the client does not support channel binding then it MUST use a 401 "n" gs2-cb-flag. 402 o If the client supports channel binding and the server does not 403 appear to (i.e., the client did not see the -PLUS name) then the 404 client MUST either fail authentication or it MUST chose the non- 405 PLUS mechanism name and use a "y" gs2-cb-flag. 406 o If the client supports channel binding and the server appears to 407 support it (i.e., the client see the -PLUS name), or if the client 408 wishes to use channel binding but the client does not negotiate 409 mechanisms, then the client MUST use a "p" gs2-cb-flag to indicate 410 the channel binding type it is using. 411 o The client generate the chan_bindings input parameter for 412 GSS_Init_sec_context as described below. 413 o Upon receipt of the initial authentication message the server 414 checks the gs2-cb-flag in the GS2 header and constructs a 415 chan_bindings parameter for GSS_Accept_sec_context as described 416 below. If the client channel binding flag was "y" and the server 417 did advertise support for channel bindings then the server MUST 418 fail authentication. If the client channel binding flag was "p" 419 and the server does not support the indicated channel binding type 420 then the server MUST fail authentication. 422 FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION 423 ---- ----------------- ----------------- ----------- 425 n no support N/A If server disallows 426 non-channel-bound 427 authentication, then 428 fail 430 y Yes, not required No Authentication may 431 succeed; CB not used 433 y Yes, not required Yes Authentication must fail 435 p Yes Yes Authentication may 436 succeed, with CB used 438 p Yes No Authentication will fail 440 N/A Yes, required No Client does not even try 442 For more discussions of channel bindings, and the syntax of the 443 channel binding data for various security protocols, see [RFC5056]. 445 5.1. Content of GSS-CHANNEL-BINDINGS structure 447 The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a 448 chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS 449 structure [RFC5554]. 451 The initiator-address-type and acceptor-address-type fields of the 452 GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator- 453 address and acceptor-address fields MUST be the empty string. 455 The application-data field MUST be set to the gs2-header concatenated 456 with, when a gs2-cb-flag of "p" is used, the application's channel 457 binding data. 459 5.2. Default Channel Binding 461 A default channel binding type agreement process for all SASL 462 application protocols that do not provide their own channel binding 463 type agreement is provided as follows. 465 'tls-unique' is the default channel binding type for any application 466 that doesn't specify one. 468 Servers MUST implement the "tls-unique" [tls-unique] 469 [I-D.altman-tls-channel-bindings] channel binding type, if they 470 implement any channel binding. Clients SHOULD implement the "tls- 471 unique" channel binding type, if they implement any channel binding. 472 Clients and servers SHOULD choose the highest-layer/innermost end-to- 473 end TLS channel as the channel to bind to. 475 Servers MUST choose the channel binding type indicated by the client, 476 or fail authentication if they don't support it. 478 6. Examples 480 Example #1: a one round-trip GSS-API context token exchange, no 481 channel binding, optional authzid given. 483 C: Request authentication exchange 484 S: Empty Challenge 485 C: n,a=someuser, 487 S: Send reply context token as is 488 C: Empty message 489 S: Outcome of authentication exchange 491 Example #2: a one and one half round-trip GSS-API context token 492 exchange, no channel binding. 494 C: Request authentication exchange 495 S: Empty Challenge 496 C: n,, 498 S: Send reply context token as is 499 C: Send reply context token as is 500 S: Outcome of authentication exchange 502 Example #3: a two round-trip GSS-API context token exchange, no 503 channel binding, no standard token header. 505 C: Request authentication exchange 506 S: Empty Challenge 507 C: F,n,, 509 S: Send reply context token as is 510 C: Send reply context token as is 511 S: Send reply context token as is 512 C: Empty message 513 S: Outcome of authentication exchange 515 Example #4: using channel binding, optional authzid given. 517 C: Request authentication exchange 518 S: Empty Challenge 519 C: p=tls-unique,a=someuser, 521 S: Send reply context token as is 522 ... 524 Example #5: using channel binding. 526 C: Request authentication exchange 527 S: Empty Challenge 528 C: p=tls-unique,, 530 S: Send reply context token as is 531 ... 533 Example #6: using non-standard channel binding (requires out-of-band 534 negotiation). 536 C: Request authentication exchange 537 S: Empty Challenge 538 C: p=tls-server-end-point,, 540 S: Send reply context token as is 541 ... 543 Example #7: client supports channel bindings but server does not, 544 optional authzid given. 546 C: Request authentication exchange 547 S: Empty Challenge 548 C: y,a=someuser, 550 S: Send reply context token as is 551 ... 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 challenge (zero byte string) if it has not yet received a token from 557 the client. See section 3 of [RFC4422]. 559 7. Authentication Conditions 561 Authentication MUST NOT succeed if any one of the following 562 conditions are true: 564 o GSS_Init/Accept_sec_context return anything other than 565 GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. 566 o If the client's initial GS2 header does not match the ABNF. 567 o In particular, if the initial character of the client message is 568 anything except "F", "p", "n", or "y". 569 o If the client's GS2 channel binding flag was "y" and the server 570 supports channel bindings. 571 o If the client's GS2 channel binding flag was "p" and the server 572 does not support the indicated channel binding. 573 o If the client requires use of channel binding and the server did 574 not advertise support for channel binding. 575 o Authorization of client principal (i.e., src_name in 576 GSS_Accept_sec_context) to requested authzid failed. 577 o If the client is not authorized to the requested authzid or an 578 authzid could not be derived from the client's initiator principal 579 name. 581 8. GSS-API Parameters 583 GS2 does not use any GSS-API per-message tokens. Therefore the per- 584 message token ret_flags from GSS_Init_sec_context() and 585 GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT 586 set the per-message req_flags. 588 The mutual_req_flag MUST be set. If channel binding is used then the 589 client MUST check that the corresponding ret_flag is set when the 590 context is fully establish, else authentication MUST fail. 592 Use or non-use of deleg_req_flag and anon_req_flag is an 593 implementation-specific detail. SASL and GS2 implementors are 594 encouraged to provide programming interfaces by which clients may 595 choose to delegate credentials and by which servers may receive them. 596 SASL and GS2 implementors are encouraged to provide programming 597 interfaces which provide a good mapping of GSS-API naming options. 599 9. Naming 601 There's no requirement that any particular GSS-API name-types be 602 used. However, typically SASL servers will have host-based acceptor 603 principal names (see [RFC2743] section 4.1) and clients will 604 typically have username initiator principal names (see [RFC2743] 605 section 4.2). When a host-based acceptor principal name is used 606 ("service@hostname"), "service" is the service name specified in the 607 protocol's profile, and "hostname" is the fully qualified host name 608 of the server. 610 10. GSS_Inquire_SASLname_for_mech call 612 We specify a new GSS-API utility function to allow SASL 613 implementations to more efficiently identify the GSS-API mechanism 614 that a particular SASL mechanism name refers to. 616 Inputs: 618 o desired_mech OBJECT IDENTIFIER 620 Outputs: 622 o sasl_mech_name UTF-8 STRING -- SASL name for this 623 mechanism; caller must release with 624 GSS_Release_buffer() 626 o mech_name UTF-8 STRING -- name of this mechanism, possibly 627 localized; caller must release with GSS_Release_buffer() 629 o mech_description UTF-8 STRING -- possibly localized 630 description of this mechanism; caller must release with 631 GSS_Release_buffer() 633 Return major_status codes: 635 o GSS_S_COMPLETE indicates successful completion, and that 636 output parameters holds correct information. 638 o GSS_S_BAD_MECH indicates that a desired_mech was unsupported 639 by the GSS-API implementation. 641 The GSS_Inquire_SASLname_for_mech call is used to get the SASL 642 mechanism name for a GSS-API mechanism. It also returns a name 643 and description of the mechanism in user friendly form. 645 The output variable sasl_mech_name will hold the IANA registered 646 mechanism name for the GSS-API mechanism, or if none is 647 registered, a mechanism name computed from the OID as described 648 in section 3.1 of this document. 650 10.1. gss_inquire_saslname_for_mech 652 The C binding for the GSS_Inquire_SASLname_for_mech call is as 653 follows. 655 OM_uint32 gss_inquire_saslname_for_mech( 656 OM_uint32 *minor_status, 657 const gss_OID desired_mech, 658 gss_buffer_t sasl_mech_name, 659 gss_buffer_t mech_name, 660 gss_buffer_t mech_description 661 ); 663 Purpose: 665 Output the SASL mechanism name of a GSS-API mechanism. 666 It also returns a name and description of the mechanism in a 667 user friendly form. 669 Parameters: 671 minor_status Integer, modify 672 Mechanism specific status code. 674 Function value: GSS status code 676 GSS_S_COMPLETE Successful completion 678 GSS_S_BAD_MECH The desired_mech OID is unsupported 680 11. GSS_Inquire_mech_for_SASLname call 682 To allow SASL clients to more efficiently identify which GSS-API 683 mechanism a particular SASL mechanism name refers to we specify a new 684 GSS-API utility function for this purpose. 686 Inputs: 688 o sasl_mech_name UTF-8 STRING -- SASL name of mechanism 690 Outputs: 692 o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, 693 and not "default" specifier 695 Return major_status codes: 697 o GSS_S_COMPLETE indicates successful completion, and that output 698 parameters holds correct information. 700 o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism 701 had the indicated sasl_mech_name. 703 The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API 704 mechanism OID associated with a SASL mechanism name. 706 11.1. gss_inquire_mech_for_saslname 708 The C binding for the GSS_Inquire_mech_for_SASLname call is as 709 follows. 711 OM_uint32 gss_inquire_mech_for_saslname( 712 OM_uint32 *minor_status, 713 const gss_buffer_t sasl_mech_name, 714 gss_OID *mech_type 715 ); 717 Purpose: 719 Output GSS-API mechanism OID of mechanism associated with given 720 sasl_mech_name. 722 Parameters: 724 minor_status Integer, modify 725 Mechanism specific status code. 727 Function value: GSS status code 729 GSS_S_COMPLETE Successful completion 731 GSS_S_BAD_MECH The desired_mech OID is unsupported 733 12. Security Layers 735 GS2 does not support SASL security layers. Applications that need 736 integrity or confidentiality protection can use either channel 737 binding to a secure external channel or another SASL mechanism that 738 does provide security layers. 740 13. Interoperability with the SASL GSSAPI mechanism 742 The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL 743 under the name GSSAPI, see GSSAPI mechanism [RFC4752]. The Kerberos 744 V5 mechanism may also be used with the GS2 family. This causes an 745 interoperability problem, which is discussed and resolved below. 747 13.1. The interoperability problem 749 The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos 750 V GSS-API mechanism used as a SASL GS2 mechanism. 752 If a client (or server) only support Kerberos V5 under the "GSSAPI" 753 name and the server (or client) only support Kerberos V5 under the 754 GS2 family, the mechanism negotiation will fail. 756 13.2. Resolving the problem 758 If the Kerberos V5 mechanism is supported under GS2 in a server, the 759 server SHOULD also support Kerberos V5 through the "GSSAPI" 760 mechanism, to avoid interoperability problems with older clients. 762 Reasons for violating this recommendation may include security 763 considerations regarding the absent features in the GS2 mechanism. 764 The SASL "GSSAPI" mechanism lacks support for channel bindings, which 765 means that using an external secure channel may not be sufficient 766 protection against active attackers (see [RFC5056], [mitm]). 768 13.3. Additional Recommendations 770 If the application requires SASL security layers then it MUST use the 771 SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2-KRB5- 772 PLUS". 774 If the application can use channel binding to an external channel 775 then it is RECOMMENDED that it select Kerberos V5 through the GS2 776 mechanism rather than the "GSSAPI" mechanism. 778 14. GSS-API Mechanisms that negotiate other mechanisms 780 A GSS-API mechanism that negotiates other mechanisms will interact 781 badly with the SASL mechanism negotiation. There are two problems. 782 The first is an interoperability problem and the second is a security 783 concern. The problems are described and resolved below. 785 14.1. The interoperability problem 787 If a client implements GSS-API mechanism X, potentially negotiated 788 through a GSS-API mechanism Y, and the server also implements GSS-API 789 mechanism X negotiated through a GSS-API mechanism Z, the 790 authentication negotiation will fail. 792 14.2. Security problem 794 If a client's policy is to first prefer GSSAPI mechanism X, then non- 795 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports 796 mechanisms Y and Z but not X, then if the client attempts to 797 negotiate mechanism X by using a GSS-API mechanism that negotiates 798 other mechanisms (such as SPNEGO [RFC4178]), it may end up using 799 mechanism Z when it ideally should have used mechanism Y. For this 800 reason, the use of GSS-API mechanisms that negotiate other mechanisms 801 is disallowed under GS2. 803 14.3. Resolving the problems 805 GSS-API mechanisms that negotiate other mechanisms MUST NOT be used 806 with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT 807 be used as a GS2 mechanism. To make this easier for SASL 808 implementations we assign a symbolic SASL mechanism name to the 809 SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST 810 NOT choose the SPNEGO mechanism under any circumstances. 812 The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech 813 [RFC5587] can be used to identify such mechanisms. 815 15. IANA Considerations 817 The IANA is advised to register a SASL mechanism family as per 818 [RFC4422] using the following information. 820 Subject: Registration of SASL mechanism family GS2-* 821 SASL mechanism prefix: GS2- 822 Security considerations: RFC [THIS-DOC] 823 Published specification: RFC [THIS-DOC] 824 Person & email address to contact for further information: 825 Simon Josefsson 826 Intended usage: COMMON 827 Owner/Change controller: iesg@ietf.org 828 Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. 830 The IANA is advised that SASL mechanism names starting with "GS2-" 831 are reserved for SASL mechanisms which conform to this document. The 832 IANA is directed to place a statement to that effect in the sasl- 833 mechanisms registry. 835 The IANA is further advised that GS2 SASL mechanism names MUST NOT 836 end in "-PLUS" except as a version of another mechanism name simply 837 suffixed with "-PLUS". 839 The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121] 840 [RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS". 842 The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be 843 "SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL 844 "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are 845 provided as a convenience for SASL library implementors. 847 16. Security Considerations 849 Security issues are also discussed throughout this memo. 851 The security provided by a GS2 mechanism depends on the security of 852 the GSS-API mechanism. The GS2 mechanism family depends on channel 853 binding support, so GSS-API mechanisms that do not support channel 854 binding cannot be successfully used as SASL mechanisms via the GS2 855 bridge. 857 Because GS2 does not support security layers it is strongly 858 RECOMMENDED that channel binding to a secure external channel be 859 used. Successful channel binding eliminates the possibility of man- 860 in-the-middle (MITM) attacks, provided that the external channel and 861 its channel binding data are secure and provided that the GSS-API 862 mechanism used is secure. Authentication failure because of channel 863 binding failure may indicate that an MITM attack was attempted, but 864 note that a real MITM attacker would likely attempt to close the 865 connection to the client or simulate network partition , thus MITM 866 attack detection is heuristic. 868 Use of channel binding will also protect the SASL mechanism 869 negotiation -- if there is no MITM then the external secure channel 870 will have protected the SASL mechanism negotiation. 872 The channel binding data MAY be sent (but the actual GSS-API 873 mechanism used) without confidentiality protection and knowledge of 874 it is assumed to provide no advantage to an MITM (who can, in any 875 case, compute the channel binding data independently). If the 876 external channel does not provide confidentiality protection and the 877 GSS-API mechanism does not provide confidentiality protection for the 878 channel binding data, then passive attackers (eavesdroppers) can 879 recover the channel binding data. See [RFC5056]. 881 When constructing the input_name_string for GSS_Import_name with the 882 GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT 883 canonicalize the server's fully qualified domain name using an 884 insecure or untrusted directory service, such as the Domain Name 885 System [RFC1034] without DNSSEC [RFC4033]. 887 SHA-1 is used to derive SASL mechanism names, but no traditional 888 cryptographic properties are required -- the required property is 889 that the truncated output for distinct inputs are different for 890 practical input values. GS2 does not use any other cryptographic 891 algorithm. Therefor GS2 is "algorithm agile", or, as agile as the 892 GSS-API mechanisms that are available for use in SASL applications 893 via GS2. 895 GS2 does not protect against downgrade attacks of channel binding 896 types. The complexities of negotiation a channel binding type, and 897 handling down-grade attacks in that negotiation, was intentionally 898 left out of scope for this document. 900 The security considerations of SASL [RFC4422], the GSS-API [RFC2743], 901 channel binding [RFC5056], any external channels (such as TLS, 902 [RFC5246], channel binding types (see the IANA channel binding type 903 registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism 904 [RFC4121] [RFC1964]), also apply. 906 17. Acknowledgements 908 The history of GS2 can be traced to the "GSSAPI" mechanism originally 909 specified by RFC2222. This document was derived from 910 draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with 911 significant contributions from John G. Myers, although the majority 912 of this document has been rewritten by the current authors. 914 Contributions of many members of the SASL mailing list are gratefully 915 acknowledged. In particular, ideas and feedback from Pasi Eronen, 916 Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved 917 the document and the protocol. Other suggestions to the documents 918 were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert 919 Sparks, and Glen Zorn. 921 18. References 923 18.1. Normative References 925 [FIPS.180-1.1995] 926 National Institute of Standards and Technology, "Secure 927 Hash Standard", FIPS PUB 180-1, April 1995, 928 . 930 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 931 Requirement Levels", BCP 14, RFC 2119, March 1997. 933 [RFC2743] Linn, J., "Generic Security Service Application Program 934 Interface Version 2, Update 1", RFC 2743, January 2000. 936 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 937 10646", STD 63, RFC 3629, November 2003. 939 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 940 Security Layer (SASL)", RFC 4422, June 2006. 942 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 943 Encodings", RFC 4648, October 2006. 945 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 946 Channels", RFC 5056, November 2007. 948 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 949 Specifications: ABNF", STD 68, RFC 5234, January 2008. 951 [RFC5554] Williams, N., "Clarifications and Extensions to the 952 Generic Security Service Application Program Interface 953 (GSS-API) for the Use of Channel Bindings", RFC 5554, 954 May 2009. 956 [CCITT.X690.2002] 957 International International Telephone and Telegraph 958 Consultative Committee, "ASN.1 encoding rules: 959 Specification of basic encoding Rules (BER), Canonical 960 encoding rules (CER) and Distinguished encoding rules 961 (DER)", CCITT Recommendation X.690, July 2002. 963 [tls-unique] 964 Zhu, L., "Registration of TLS unique channel binding 965 (generic)", IANA http://www.iana.org/assignments/ 966 channel-binding-types/tls-unique, July 2008. 968 18.2. Informative References 970 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 971 STD 13, RFC 1034, November 1987. 973 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 974 RFC 1964, June 1996. 976 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 977 (SPKM)", RFC 2025, October 1996. 979 [RFC2222] Myers, J., "Simple Authentication and Security Layer 980 (SASL)", RFC 2222, October 1997. 982 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 983 Rose, "DNS Security Introduction and Requirements", 984 RFC 4033, March 2005. 986 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 987 Version 5 Generic Security Service Application Program 988 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 989 July 2005. 991 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 992 Simple and Protected Generic Security Service Application 993 Program Interface (GSS-API) Negotiation Mechanism", 994 RFC 4178, October 2005. 996 [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple 997 Authentication and Security Layer (SASL) Mechanism", 998 RFC 4752, November 2006. 1000 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1001 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1003 [RFC5587] Williams, N., "Extended Generic Security Service Mechanism 1004 Inquiry APIs", RFC 5587, July 2009. 1006 [I-D.ietf-sasl-scram] 1007 Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, 1008 "Salted Challenge Response (SCRAM) SASL and GSS-API 1009 Mechanism", draft-ietf-sasl-scram-10 (work in progress), 1010 October 2009. 1012 [I-D.altman-tls-channel-bindings] 1013 Altman, J., Williams, N., and L. Zhu, "Channel Bindings 1014 for TLS", draft-altman-tls-channel-bindings-07 (work in 1015 progress), October 2009. 1017 [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1018 in Tunneled Authentication", 1019 WWW http://www.saunalahti.fi/~asokan/research/mitm.html. 1021 Authors' Addresses 1023 Simon Josefsson 1024 SJD AB 1025 Hagagatan 24 1026 Stockholm 113 47 1027 SE 1029 Email: simon@josefsson.org 1030 URI: http://josefsson.org/ 1031 Nicolas Williams 1032 Sun Microsystems 1033 5300 Riata Trace Ct 1034 Austin, TX 78727 1035 USA 1037 Email: Nicolas.Williams@sun.com