idnits 2.17.1 draft-ietf-sasl-gs2-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (April 18, 2009) is 5487 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 733, 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 (-13) exists of draft-newman-auth-scram-12 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 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: October 20, 2009 Sun Microsystems 6 April 18, 2009 8 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family 9 draft-ietf-sasl-gs2-12 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. This document may contain material 15 from IETF Documents or IETF Contributions published or made publicly 16 available before November 10, 2008. The person(s) controlling the 17 copyright in some of this material may not have granted the IETF 18 Trust the right to allow modifications of such material outside the 19 IETF Standards Process. Without obtaining an adequate license from 20 the person(s) controlling the copyright in such materials, this 21 document may not be modified outside the IETF Standards Process, and 22 derivative works of it may not be created outside the IETF Standards 23 Process, except to format it for publication as an RFC or to 24 translate it into languages other than English. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on October 20, 2009. 44 Copyright Notice 46 Copyright (c) 2009 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents in effect on the date of 51 publication of this document (http://trustee.ietf.org/license-info). 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. 55 Abstract 57 This document describes how to use a Generic Security Service 58 Application Program Interface (GSS-API) mechanism in the the Simple 59 Authentication and Security Layer (SASL) framework. This is done by 60 defining a new SASL mechanism family, called GS2. This mechanism 61 family offers a number of improvements over the previous "SASL/ 62 GSSAPI" mechanism: it is more general, uses fewer messages for the 63 authentication phase in some cases, and supports negotiable use of 64 channel binding. Only GSS-API mechanisms that support channel 65 binding are supported. 67 See for more information. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Conventions used in this document . . . . . . . . . . . . . . 5 73 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 5 75 3.2. Computing mechanism names manually . . . . . . . . . . . . 6 76 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 3.4. Grandfathered mechanism names . . . . . . . . . . . . . . 7 78 4. SASL Authentication Exchange Message Format . . . . . . . . . 7 79 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 7 80 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 9 81 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 11 83 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 12 84 9. Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 10. GSS_Inquire_SASLname_for_mech call . . . . . . . . . . . . . . 12 86 10.1. gss_inquire_saslname_for_mech . . . . . . . . . . . . . . 13 87 11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13 88 11.1. gss_inquire_mech_for_saslname . . . . . . . . . . . . . . 15 89 12. Security Layers . . . . . . . . . . . . . . . . . . . . . . . 15 90 13. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 16 91 13.1. The interoperability problem . . . . . . . . . . . . . . . 16 92 13.2. Resolving the problem . . . . . . . . . . . . . . . . . . 16 93 13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16 94 14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17 95 14.1. The interoperability problem . . . . . . . . . . . . . . . 17 96 14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17 97 14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17 98 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 16. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 101 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 102 18.1. Normative References . . . . . . . . . . . . . . . . . . . 19 103 18.2. Informative References . . . . . . . . . . . . . . . . . . 20 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 106 1. Introduction 108 Generic Security Service Application Program Interface (GSS-API) 109 [RFC2743] is a framework that provides security services to 110 applications using a variety of authentication "mechanisms". Simple 111 Authentication and Security Layer (SASL) [RFC4422] is a framework to 112 provide authentication and "security layers" for connection based 113 protocols, also using a variety of mechanisms. This document 114 describes how to use a GSS-API mechanism as though it were a SASL 115 mechanism. This facility is called "GS2" -- a moniker that indicates 116 that this is the second GSS-API->SASL mechanism bridge. The original 117 GSS-API->SASL mechanism bridge was specified by [RFC2222], now 118 [RFC4752]; we shall sometimes refer to the original bridge as "GS1" 119 in this document. 121 All GSS-API mechanisms are implicitly registered for use within SASL 122 by this specification. The SASL mechanisms defined in this document 123 are known as the "GS2 family of mechanisms". 125 The GS1 bridge failed to gain wide deployment for any GSS-API 126 mechanism other than The "Kerberos V5 GSS-API mechanism" [RFC1964] 127 [RFC4121], and has a number of problems that lead us to desire a new 128 bridge. Specifically: a) GS1 was not round-trip optimized, b) GS1 129 did not support channel binding [RFC5056]. These problems and the 130 opportunity to create the next SASL password-based mechanism, SCRAM 131 [I-D.newman-auth-scram], as a GSS-API mechanism used by SASL 132 applications via GS2, provide the motivation for GS2. 134 In particular, the current consensus of the SASL community appears to 135 be that SASL "security layers" (i.e., confidentiality and integrity 136 protection of application data after authentication) are too complex 137 and, since SASL applications tend to have an option to run over a 138 Transport Layer Security (TLS) [RFC5246] channel, redundant and best 139 replaced with channel binding. 141 GS2 is designed to be as simple as possible. It adds to GSS-API 142 security context token exchanges only the bare minimum to support 143 SASL semantics and negotiation of use of channel binding. 144 Specifically, GS2 adds a small header (2 bytes or 3 bytes plus the 145 length of the client requested SASL authorization ID (authzid)) to 146 the initial context token and to the application channel binding 147 data, and it uses SASL mechanism negotiation to implement channel 148 binding negotiation. All GS2 plaintext is protected via the use of 149 GSS-API channel binding. Additionally, to simplify the 150 implementation of GS2 mechanisms for implementors who will not 151 implement a GSS-API framework, we compress the initial security 152 context token header required by [RFC2743] (see section 3.1). 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 3. Mechanism name 162 There are two SASL mechanism names for any GSS-API mechanism used 163 through this facility. One denotes that the server supports channel 164 binding. The other denotes that it does not. 166 The SASL mechanism name for a GSS-API mechanism is that which is 167 provided by that mechanism when it was specified, if one was 168 specified. This name denotes that the server does not support 169 channel binding. Add the suffix "-PLUS" and the resulting name 170 denotes that the server does support channel binding. SASL 171 implementations can use the GSS_Inquire_SASLname_for_mech call (see 172 below) to query for the SASL mechanism name of a GSS-API mechanism. 174 If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 175 implementation need some other mechanism to map mechanism OIDs to 176 SASL name internally. In this case, the implementation can only 177 support the mechanisms for which it knows the SASL name. If the 178 GSS_Inquire_SASLname_for_mech call fails, and the GS2 implementation 179 cannot map the OID to a SASL mechanism name using some other means, 180 it cannot use the particular GSS-API mechanism since it does not know 181 its SASL mechanism name. 183 If the GSS_Inquire_SASLname_for_mech call is successful, but provides 184 a zero length string [FIXME: is this a good idea? --simon], it means 185 the GSS-API mechanism did not have a registered mechanism name. In 186 this case, the GS2 implementation can derive the SASL mechanism name 187 from the GSS-API mechanism OID as follows. 189 3.1. Generating SASL mechanism names from GSS-API OIDs 191 For GSS-API mechanisms whose SASL names are not defined together with 192 the GSS-API mechanism or in this document, the SASL mechanism name is 193 concatenation of the string "GS2-" and the Base32 encoding [RFC4648] 194 (with an upper case alphabet) of the first 55 bits of the binary 195 SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER 196 encoding [CCITT.X690.2002], including the tag and length octets, of 197 the GSS-API mechanism's Object Identifier. The Base32 rules on 198 padding characters and characters outside of the base32 alphabet are 199 not relevant to this use of Base32. If any padding or non-alphabet 200 characters are encountered, the name is not a GS2 family mechanism 201 name. This name denotes that the server does not support channel 202 binding. Add the suffix "-PLUS" and the resulting name denotes that 203 the server does support channel binding. 205 3.2. Computing mechanism names manually 207 The hash-derived GS2 SASL mechanism name may be computed manually. 208 This is useful when the set of supported GSS-API mechanisms is known 209 in advance. It also obliterate the need to implement Base32, SHA-1 210 and DER in the SASL mechanism. The computed mechanism name can be 211 used directly in the implementation, and the implementation need not 212 concern itself with that the mechanism is part of a mechanism family. 214 3.3. Examples 216 The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The 217 ASN.1 DER encoding of the OID, including the tag and length, is (in 218 hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER 219 encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 220 27 86 61 ad. Convert the first 7 octets to binary, drop the last 221 bit, and re-group them in groups of 5, and convert them back to 222 decimal, which results in these computations: 224 hex: 225 1c f8 f4 2b 5a 9f 80 227 binary: 228 00011100 11111000 11110100 00101011 01011010 229 10011111 1000000 231 binary in groups of 5: 232 00011 10011 11100 01111 01000 01010 11010 11010 233 10011 11110 00000 235 decimal of each group: 236 3 19 28 15 8 10 26 26 19 30 0 238 base32 encoding: 239 D T 4 P I K 2 2 T 6 A 241 The last step translate each decimal value using table 3 in Base32 242 [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI 243 mechanism is "GS2-DT4PIK22T6A". 245 The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is 246 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 247 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 248 93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop 249 the last bit, and re-group them in groups of 5, and convert them back 250 to decimal, which results in these computations: 252 hex: 253 82 d2 73 25 76 6b d6 255 binary: 256 10000010 11010010 01110011 00100101 01110110 257 01101011 1101011 259 binary in groups of 5: 260 10000 01011 01001 00111 00110 01001 01011 10110 261 01101 01111 01011 263 decimal of each group: 264 16 11 9 7 6 9 11 22 13 15 11 266 base32 encoding: 267 Q L J H G J L W N P L 269 The last step translate each decimal value using table 3 in Base32 270 [RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI 271 mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism 272 supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next 273 section assigns the Kerberos V5 mechanism a non-hash-derived 274 mechanism name. 276 3.4. Grandfathered mechanism names 278 Some older GSS-API mechanisms were not specified with a SASL GS2 279 mechanism name. Using a shorter name can be useful nonetheless. We 280 specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5 281 mechanism, to be used as if the original specification documented it. 282 See Section 15. 284 4. SASL Authentication Exchange Message Format 286 4.1. SASL Messages 288 During the SASL authentication exchange for GS2, a number of messages 289 following the following format is sent between the client and server. 290 This number is the same as the number of context tokens that the GSS- 291 API mechanism would normally require in order to establish a security 292 context (or to fail to do so). 294 Note that when using a GS2 mechanism the SASL client is always a GSS- 295 API initiator and the SASL server is always a GSS-API acceptor. Thus 296 the SASL client calls GSS_Init_sec_context and the server calls 297 GSS_Accept_sec_context. 299 All the SASL authentication messages exchanged are exactly the same 300 as the security context tokens of the GSS-API mechanism, except for 301 the initial security context token. 303 Also, the server SHOULD refrain from sending GSS-API error tokens 304 (tokens output by GSS_Init_sec_context or GSS_Accept_sec_context 305 along with a major status code other than GSS_S_COMPLETE or 306 GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions. 308 The initial security context token is modified as follows: 309 o The [RFC2743] section 3.1 initial context token header MUST be 310 removed if present. If the header is not present, the client MUST 311 send a "gs2-nonstd-flag" flag (see below). On the server side 312 this header MUST be recomputed and restored prior to passing the 313 token to GSS_Accept_sec_context, except when the "gs2-nonstd-flag" 314 is sent. 315 o A GS2 header MUST be prefixed to the resulting initial context 316 token. This header has the form "gs2-header" given below in ABNF 317 [RFC5234]. 319 UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F 320 ;; As UTF8-1 in RFC 3629 except 321 ;; NUL, "=", and ",". 322 UTF8-2 = 323 UTF8-3 = 324 UTF8-4 = 325 UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4 327 saslname = 1*(UTF8-char-safe / "=2C" / "=3D") 328 gs2-authzid = "a=" saslname 329 ;; GS2 has to transport an authzid since 330 ;; the GSS-API has no equivalent 331 gs2-nonstd-flag = "F" 332 ;; "F" means the mechanism is not a 333 ;; standard GSS-API mechanism in that the 334 ;; RFC2743 section 3.1 header was missing 335 gs2-cb-flag = "p" / "n" / "y" 336 ;; GS2 channel binding (CB) flag 337 ;; "p" -> client supports and used CB 338 ;; "n" -> client does not support CB 339 ;; "y" -> client supports CB, thinks the server 340 ;; does not 341 gs2-header = [gs2-nonstd-flag] gs2-cb-flag [gs2-authzid] "," 342 ;; The GS2 header is gs2-header. 344 When the "gs2-nonstd-flag" flag is present, the client did not find/ 345 remove a [RFC2743] section 3.1 token header from the initial token 346 returned by GSS_Init_sec_context. This signals to the server that it 347 MUST NOT re-add the data that is normally removed by the client. 349 The "gs2-cb-flag" signals the channel binding mode. One of "p", "n", 350 or "y" is used. A "p" means the client supports and used a channel 351 binding. A "n" means that the client does not support channel 352 binding. A "y" means the client supports channel binding, but 353 believes the server does not, so it did not use a channel binding. 354 See the next section for more details. 356 The "gs2-authzid" holds the SASL authorization identity. It is 357 encoded using UTF-8 [RFC3629] with three exceptions: 358 o The NUL characters is forbidden as required by section 3.4.1 of 359 [RFC4422]. 360 o The server MUST replace any "," (comma) in the string with "=2C". 361 o The server MUST replace any "=" (equals) in the string with "=3D". 363 If a server sends a string that does not conform to this syntax, the 364 client MUST reject authentication. 366 5. Channel Bindings 368 If the server supports channel binding then it MUST list both forms 369 of the SASL mechanism name for each GSS-API mechanism supported via 370 GS2 (i.e., GSS-API mechanisms that support channel binding). 372 If the client supports channel binding and the server does not (i.e., 373 the server did not advertise the -PLUS names) then the client MUST 374 either fail authentication or it MUST set the channel binding flag in 375 the GS2 initial security context token to "y" and MUST NOT include 376 application channel binding data in the GSS-API channel binding input 377 to GSS_Init_sec_context. 379 If the client supports channel binding and the server also does then 380 the client MUST set the channel binding flag in the GS2 initial 381 security context token to "p" and MUST include application channel 382 binding data in the GSS-API channel binding input to 383 GSS_Init_sec_context. This is done by pre-pending the gs2-header to 384 the application's channel binding data. If the application did not 385 provide channel binding data then the GS2 header is used as though it 386 were application-provided channel binding data. 388 If the client does not support channel binding then it MUST set the 389 channel binding flag in the GS2 initial security context token to "n" 390 and MUST NOT include application channel binding data in the GSS-API 391 channel binding input to GSS_Init_sec_context. 393 Upon receipt of the initial authentication message the server checks 394 the channel binding flag in the GS2 header and constructs a channel 395 binding data input for GSS_Accept_sec_context accordingly. If the 396 client channel binding flag was "n" then the server MUST NOT include 397 application channel binding data in the GSS-API channel binding input 398 to GSS_Accept_sec_context. If the client channel binding flag was 399 "y" and the server does support channel binding then the server MUST 400 fail authentication. If the client channel binding flag was "p" the 401 server MUST include application channel binding data in the GSS-API 402 channel binding input to GSS_Accept_sec_context. 404 For more discussions of channel bindings, and the syntax of the 405 channel binding data for various security protocols, see [RFC5056]. 407 6. Examples 409 Example #1: a one round-trip GSS-API context token exchange, no 410 channel binding, optional authzid given. 412 C: Request authentication exchange 413 S: Empty Challenge 414 C: na=someuser, 416 S: Send reply context token as is 417 C: Empty message 418 S: Outcome of authentication exchange 420 Example #2: a one and one half round-trip GSS-API context token 421 exchange. 423 C: Request authentication exchange 424 S: Empty Challenge 425 C: na=someuser, 427 S: Send reply context token as is 428 C: Send reply context token as is 429 S: Outcome of authentication exchange 431 Example #3: a two round-trip GSS-API context token exchange, no 432 standard token header. 434 C: Request authentication exchange 435 S: Empty Challenge 436 C: Fna=someuser, 438 S: Send reply context token as is 439 C: Send reply context token as is 440 S: Send reply context token as is 441 C: Empty message 442 S: Outcome of authentication exchange 444 Example #4: using channel binding 446 C: Request authentication exchange 447 S: Empty Challenge 448 C: pa=someuser, 450 S: Send reply context token as is 451 ... 453 GSS-API authentication is always initiated by the client. The SASL 454 framework allows either the client and server to initiate 455 authentication. In GS2 the server will send an initial empty 456 challenge (zero byte string) if it has not yet received a token from 457 the client. See section 3 of [RFC4422]. 459 7. Authentication Conditions 461 Authentication MUST NOT succeed if any one of the following 462 conditions are true: 464 o GSS_Init/Accept_sec_context return anything other than 465 GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. 466 o If the client's GS2 channel binding flag was "y" and the server 467 supports channel binding. 468 o If the client requires use of channel binding and the server did 469 not advertise support for channel binding. 470 o Authorization of client principal (i.e., src_name in 471 GSS_Accept_sec_context) to requested authzid failed. 472 o If the client is not authorized to the requested authzid or an 473 authzid could not be derived from the client's initiator principal 474 name. 476 8. GSS-API Parameters 478 GS2 does not use any GSS-API per-message tokens. Therefore the 479 setting of req_flags related to per-message tokens is irrelevant. 481 9. Naming 483 There's no requirement that any particular GSS-API name-types be 484 used. However, typically SASL servers will have host-based acceptor 485 principal names (see [RFC2743] section 4.1) and clients will 486 typically have username initiator principal names (see [RFC2743] 487 section 4.2). 489 10. GSS_Inquire_SASLname_for_mech call 491 To allow SASL implementations to query for the SASL mechanism name of 492 a GSS-API mechanism, we specify a new GSS-API function for this 493 purpose. 495 Inputs: 497 o desired_mech OBJECT IDENTIFIER 499 Outputs: 501 o sasl_mech_name UTF-8 STRING -- SASL name for this mechanism 503 o mech_name UTF-8 STRING -- name of this mechanism, possibly 504 localized 506 o mech_description UTF-8 STRING -- possibly localized 507 description of this mechanism. 509 Return major_status codes: 511 o GSS_S_COMPLETE indicates successful completion, and that output 512 parameters holds correct information. 514 o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by 515 the GSS-API implementation. 517 The GSS_Inquire_SASLname_for_mech call is used to get the SASL 518 mechanism name for a GSS-API mechanism. It also returns a name 519 and description of the mechanism in a human readable form. 521 10.1. gss_inquire_saslname_for_mech 523 The C binding for the GSS_Inquire_SASLname_for_mech call is as 524 follows. 526 OM_uint32 gss_inquire_saslname_for_mech( 527 OM_uint32 *minor_status, 528 const gss_OID desired_mech, 529 gss_buffer_t sasl_mech_name, 530 gss_buffer_t mech_name, 531 gss_buffer_t mech_description, 532 ); 534 Purpose: 536 Output the SASL mechanism name of a GSS-API mechanism. 537 It also returns a name and description of the mechanism in a 538 human readable form. 540 Parameters: 542 minor_status Integer, modify 543 Mechanism specific status code. 545 Function value: GSS status code 547 GSS_S_COMPLETE Successful completion 549 GSS_S_BAD_MECH The desired_mech OID is unsupported 551 11. GSS_Inquire_mech_for_SASLname call 553 To allow SASL clients to more efficiently identify which GSS-API 554 mechanism a particular SASL mechanism name refers to we specify a new 555 GSS-API utility function for this purpose. 557 Inputs: 559 o sasl_mech_name UTF-8 STRING -- SASL name of mechanism 561 Outputs: 563 o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, 564 and not "default" specifier 566 Return major_status codes: 568 o GSS_S_COMPLETE indicates successful completion, and that output 569 parameters holds correct information. 571 o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism 572 had the indicated sasl_mech_name. 574 The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API 575 mechanism OID associated with a SASL mechanism name. 577 11.1. gss_inquire_mech_for_saslname 579 The C binding for the GSS_Inquire_mech_for_SASLname call is as 580 follows. 582 OM_uint32 gss_inquire_mech_for_saslname( 583 OM_uint32 *minor_status, 584 const gss_buffer_t sasl_mech_name, 585 gss_OID *mech_type 586 ); 588 Purpose: 590 Output GSS-API mechanism OID of mechanism associated with given 591 sasl_mech_name. 593 Parameters: 595 minor_status Integer, modify 596 Mechanism specific status code. 598 Function value: GSS status code 600 GSS_S_COMPLETE Successful completion 602 GSS_S_BAD_MECH The desired_mech OID is unsupported 604 12. Security Layers 606 GS2 does not currently support SASL security layers. Applications 607 that need integrity protection or confidentiality and integrity 608 protection MUST use either channel binding to a secure external 609 channel or a SASL mechanism that does provide security layers. 611 NOTE WELL: the GS2 client's first authentication message MUST always 612 start with "F", "p", "n" or "y", otherwise the server MUST fail 613 authentication. This will allow us to add support for security 614 layers in the future if it were to become necessary. Note that 615 adding security layer support to GS2 must not break existing SASL/GS2 616 applications, which can be accomplished by making security layers 617 optional. 619 [A sketch of how to add sec layer support... Add a way for the 620 client to: a) make an offer of sec layers and max buffer, b) make an 621 opportunistic selection of sec layer and buffer size, both in the 622 first client authentication message, and starting with a character 623 other than "F", "n", "y" or "p". The server could accept the 624 opportunistic proposal (reply token prefixed with a byte indicating 625 acceptance) or reject it along with an indication of the server's 626 acceptable sec layers and max buffer size. In the latter case the 627 GSS-API security context token exchange must be abandoned and 628 recommenced, although this would be a detail of the GS2 bridge not 629 exposed to the SASL application. The negotiation would be protected 630 via GSS channel binding, as with the rest of GS2.] 632 13. Interoperability with the SASL "GSSAPI" mechanism 634 The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL 635 under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The 636 Kerberos V5 mechanism may also be used with the GS2 family. This 637 causes an interoperability problem, which is discussed and resolved 638 below. 640 13.1. The interoperability problem 642 The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos 643 V GSS-API mechanism used as a SASL GS2 mechanism. 645 If a client (or server) only support Kerberos V5 under the "GSSAPI" 646 name and the server (or client) only support Kerberos V5 under the 647 GS2 family, the mechanism negotiation will fail. 649 13.2. Resolving the problem 651 If the Kerberos V5 mechanism is supported under GS2 in a server, the 652 server SHOULD also support Kerberos V5 through the "GSSAPI" 653 mechanism, to avoid interoperability problems with older clients. 655 Reasons for violating this recommendation may include security 656 considerations regarding the absent features in the GS2 mechanism. 657 The SASL "GSSAPI" mechanism lacks support for channel bindings, which 658 means that using an external secure channel may not be sufficient 659 protection against active attackers (see [RFC5056], [mitm]). 661 13.3. Additional Recommendations 663 If the application requires security layers then it MUST prefer the 664 SASL "GSSAPI" mechanism over "GS2-KRB5" or "GS2-KRB5-PLUS". 666 If the application can use channel binding to an external channel 667 then it is RECOMMENDED that it select Kerberos V5 through the GS2 668 mechanism rather than the "GSSAPI" mechanism. 670 14. Mechanisms that negotiate other mechanisms 672 A GSS-API mechanism that negotiate other mechanisms interact badly 673 with the SASL mechanism negotiation. There are two problems. The 674 first is an interoperability problem and the second is a security 675 concern. The problems are described and resolved below. 677 14.1. The interoperability problem 679 If a client implement GSS-API mechanism X, potentially negotiated 680 through a GSS-API mechanism Y, and the server also implement GSS-API 681 mechanism X negotiated through a GSS-API mechanism Z, the 682 authentication negotiation will fail. 684 14.2. Security problem 686 If a client's policy is to first prefer GSSAPI mechanism X, then non- 687 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports 688 mechanisms Y and Z but not X, then if the client attempts to 689 negotiate mechanism X by using a GSS-API mechanism that negotiate 690 other mechanisms (such as SPNEGO), it may end up using mechanism Z 691 when it ideally should have used mechanism Y. For this reason, the 692 use of GSS-API mechanisms that negotiate other mechanisms are 693 disallowed under GS2. 695 14.3. Resolving the problems 697 GSS-API mechanisms that negotiate other mechanisms MUST NOT be used 698 with the GS2 SASL mechanism. Specifically SPNEGO [RFC4178] MUST NOT 699 be used as a GS2 mechanism. To make this easier for SASL 700 implementations we assign a symbolic SASL mechanism name to the 701 SPNEGO GSS-API mechanism: "SPNEGO". SASL client implementations MUST 702 NOT choose the SPNEGO mechanism under any circumstances. [What about 703 SASL apps that don't do mechanism negotiation? Probably none exist. 704 But if any did then presumably it would OK to use the SPNEGO 705 mechanism, no? -Nico] 707 The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech 708 [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such 709 mechanisms. 711 15. IANA Considerations 713 The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121] 714 [RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS". 716 The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be 717 "SPNEGO" and "SPNEGO-PLUS". As described in Section 14 the SASL 718 "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are 719 provided as a convenience for SASL library implementors. 721 The IANA is advised that SASL mechanism names starting with "GS2-" 722 are reserved for SASL mechanisms which conform to this document. The 723 IANA is directed to place a statement to that effect in the sasl- 724 mechanisms registry. 726 The IANA is further advised that SASL mechanisms MUST NOT end in 727 "-PLUS" except as a version of another mechanism name simply suffixed 728 with "-PLUS". 730 Subject: Registration of SASL mechanism GS2-* 731 SASL mechanism prefix: GS2- 732 Security considerations: RFC [THIS-DOC] 733 Published specification: RFC [THIS-DOC] 734 Person & email address to contact for further information: 735 Simon Josefsson 736 Intended usage: COMMON 737 Owner/Change controller: iesg@ietf.org 738 Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. 740 16. Security Considerations 742 Security issues are also discussed throughout this memo. 744 The security provided by a GS2 mechanism depends on the security of 745 the GSS-API mechanism. The GS2 mechanism family depends on channel 746 binding support, so GSS-API mechanisms that do not support channel 747 binding cannot be successfully used as SASL mechanisms via the GS2 748 bridge. 750 Because GS2 does not support security layers it is strongly 751 RECOMMENDED that channel binding to a secure external channel be 752 used. Successful channel binding eliminates the possibility of man- 753 in-the-middle (MITM) attacks, provided that the external channel and 754 its channel binding data are secure and provided that the GSS-API 755 mechanism used is secure. Authentication failure because of channel 756 binding failure may indicate that an MITM attack was attempted, but 757 note that a real MITM attacker would likely attempt to close the 758 connection to the client or simulate network partition , thus MITM 759 attack detection is heuristic. 761 Use of channel binding will also protect the SASL mechanism 762 negotiation -- if there is no MITM then the external secure channel 763 will have protected the SASL mechanism negotiation. 765 The channel binding data MAY be sent (but the actual GSS-API 766 mechanism used) without confidentiality protection and knowledge of 767 it is assumed to provide no advantage to an MITM (who can, in any 768 case, compute the channel binding data independently). If the 769 external channel does not provide confidentiality protection and the 770 GSS-API mechanism does not provide confidentiality protection for the 771 channel binding data, then passive attackers (eavesdroppers) can 772 recover the channel binding data. See [RFC5056]. 774 When constructing the input_name_string for GSS_Import_name with the 775 GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT 776 canonicalize the server's fully qualified domain name using an 777 insecure or untrusted directory service, such as the Domain Name 778 System [RFC1034] without DNSSEC [RFC4033]. 780 GS2 does not directly use any cryptographic algorithms, therefore it 781 is automatically "algorithm agile", or, as agile as the GSS-API 782 mechanisms that are available for use in SASL applications via GS2. 784 The security considerations of SASL [RFC4422], the GSS-API [RFC2743], 785 channel binding [RFC5056], any external channels (such as TLS, 786 [RFC5246], channel binding types (see the IANA channel binding type 787 registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism 788 [RFC4121] [RFC1964]), may also apply. 790 17. Acknowledgements 792 The history of GS2 can be traced to the "GSSAPI" mechanism originally 793 specified by RFC2222. This document was derived from 794 draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with 795 significant contributions from John G. Myers, although the majority 796 of this document has been rewritten by the current authors. 798 Contributions of many members of the SASL mailing list are gratefully 799 acknowledged. In particular, ideas and feedback from Sam Hartman, 800 Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document 801 and the protocol. 803 18. References 805 18.1. Normative References 807 [FIPS.180-1.1995] 808 National Institute of Standards and Technology, "Secure 809 Hash Standard", FIPS PUB 180-1, April 1995, 810 . 812 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 813 Requirement Levels", BCP 14, RFC 2119, March 1997. 815 [RFC2743] Linn, J., "Generic Security Service Application Program 816 Interface Version 2, Update 1", RFC 2743, January 2000. 818 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 819 10646", STD 63, RFC 3629, November 2003. 821 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 822 Security Layer (SASL)", RFC 4422, June 2006. 824 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 825 Encodings", RFC 4648, October 2006. 827 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 828 Channels", RFC 5056, November 2007. 830 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 831 Specifications: ABNF", STD 68, RFC 5234, January 2008. 833 [CCITT.X690.2002] 834 International International Telephone and Telegraph 835 Consultative Committee, "ASN.1 encoding rules: 836 Specification of basic encoding Rules (BER), Canonical 837 encoding rules (CER) and Distinguished encoding rules 838 (DER)", CCITT Recommendation X.690, July 2002. 840 18.2. Informative References 842 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 843 STD 13, RFC 1034, November 1987. 845 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 846 RFC 1964, June 1996. 848 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 849 (SPKM)", RFC 2025, October 1996. 851 [RFC2222] Myers, J., "Simple Authentication and Security Layer 852 (SASL)", RFC 2222, October 1997. 854 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 855 Rose, "DNS Security Introduction and Requirements", 856 RFC 4033, March 2005. 858 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 859 Version 5 Generic Security Service Application Program 860 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 861 July 2005. 863 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 864 Simple and Protected Generic Security Service Application 865 Program Interface (GSS-API) Negotiation Mechanism", 866 RFC 4178, October 2005. 868 [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple 869 Authentication and Security Layer (SASL) Mechanism", 870 RFC 4752, November 2006. 872 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 873 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 875 [I-D.newman-auth-scram] 876 Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, 877 "Salted Challenge Response (SCRAM) SASL Mechanism", 878 draft-newman-auth-scram-12 (work in progress), March 2009. 880 [I-D.ietf-kitten-extended-mech-inquiry] 881 Williams, N., "Extended Generic Security Service Mechanism 882 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-06 883 (work in progress), April 2009. 885 [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 886 in Tunneled Authentication", 887 WWW http://www.saunalahti.fi/~asokan/research/mitm.html. 889 Authors' Addresses 891 Simon Josefsson 892 SJD AB 893 Hagagatan 24 894 Stockholm 113 47 895 SE 897 Email: simon@josefsson.org 898 URI: http://josefsson.org/ 899 Nicolas Williams 900 Sun Microsystems 901 5300 Riata Trace Ct 902 Austin, TX 78727 903 USA 905 Email: Nicolas.Williams@sun.com