idnits 2.17.1 draft-josefsson-sasl-gs2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 811. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 795. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 801. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2005) is 6735 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) -- Looks like a reference, but probably isn't: 'THIS-DOC' on line 636 ** Obsolete normative reference: RFC 2222 (ref. '2') (Obsoleted by RFC 4422, RFC 4752) ** Downref: Normative reference to an Informational RFC: RFC 3174 (ref. '4') ** Obsolete normative reference: RFC 3548 (ref. '5') (Obsoleted by RFC 4648) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2478 (ref. '10') (Obsoleted by RFC 4178) == Outdated reference: A later version (-08) exists of draft-ietf-sasl-gssapi-03 -- Obsolete informational reference (is this intentional?): RFC 2246 (ref. '13') (Obsoleted by RFC 4346) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft November 17, 2005 4 Expires: May 21, 2006 6 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family 7 draft-josefsson-sasl-gs2-00 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 21, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes how to use a Generic Security Service 41 Application Program Interface mechanism in the the Simple 42 Authentication and Security Layer framework. 44 See for more information. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 50 3. Mechanism Name . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 3 52 3.2. Computing mechanism names manually . . . . . . . . . . . . 4 53 3.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Protocol specification . . . . . . . . . . . . . . . . . . . . 4 55 4.1. Packet format . . . . . . . . . . . . . . . . . . . . . . 4 56 4.2. Protocol overview . . . . . . . . . . . . . . . . . . . . 5 57 4.3. GSS-API parameters . . . . . . . . . . . . . . . . . . . . 9 58 4.4. Security layer bits . . . . . . . . . . . . . . . . . . . 9 59 4.5. Authorization identity format . . . . . . . . . . . . . . 10 60 4.6. Client side of authentication protocol exchange . . . . . 10 61 4.7. Server side of authentication protocol exchange . . . . . 12 62 5. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 64 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 65 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 66 9. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 16 67 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 68 10.1. Normative References . . . . . . . . . . . . . . . . . . . 16 69 10.2. Informative References . . . . . . . . . . . . . . . . . . 17 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 71 Intellectual Property and Copyright Statements . . . . . . . . . . 19 73 1. Introduction 75 Generic Security Service Application Program Interface (GSS-API) [3] 76 is a framework that provide security services to applications. 77 Simple Authentication and Security Layer (SASL) [2] is a framework to 78 provide authentication and security layers for connection based 79 protocols. This document describe how to use a GSS-API mechanism in 80 a connection-based protocol using the SASL framework. 82 All GSSAPI mechanism is implicitly registered by this specification 83 for use within SASL. The SASL mechanism defined in this document is 84 known as the GS2 family. 86 The "Kerberos V5 GSS-API mechanism" [9] and "The Simple and Protected 87 GSS-API Negotiation Mechanism" [10] are also supported in SASL 88 through "SASL GSSAPI mechanisms" [11]. The difference between that 89 protocol and the one described here, is that this protocol offer more 90 features (i.e., channel bindings and round-trip optimizations) while 91 the other protocol is more widely deployed. There are 92 interoperability concerns with supporting GSS-API mechanisms through 93 more than one SASL mechanism, see the section on SPNEGO below. 95 SASL mechanism names starting with "GS2-" are reserved for SASL 96 mechanisms which conform to this document. 98 The IESG is considered to be the owner of all SASL mechanisms which 99 conform to this document. This does not necessarily imply that the 100 IESG is considered to be the owner of the underlying GSSAPI 101 mechanism. 103 2. Conventions Used in this Document 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [1]. 109 3. Mechanism Name 111 3.1. Generating SASL mechanism names from GSS-API OIDs 113 The SASL mechanism name for a GSS-API mechanism is the concatenation 114 of the string "GS2-" and the Base32 encoding [5] (with an upper case 115 alphabet) of the first ten bytes of the binary SHA-1 hash [4] string 116 computed over the ASN.1 DER encoding [7] of the GSS-API mechanism's 117 Object Identifier. The Base32 rules on padding characters and 118 characters outside of the base32 alphabet are not relevant to this 119 use of Base32. If any padding or non-alphabet characters are 120 encountered, the name is not a GS2 family mechanism name. 122 3.2. Computing mechanism names manually 124 The SASL mechanism name may be computed manually. This is useful 125 when the set of supported GSS-API mechanisms is known in advance. It 126 also obliterate the need to implement Base32, SHA-1 and DER in the 127 SASL mechanism. The computed mechanism name can be used directly in 128 the implementation, and the implementation need not concern itself 129 with that the mechanism is part of a mechanism family. 131 3.3. Example 133 For example, the OID for the SPKM-1 mechanism [12] is 134 1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID is 06 07 2b 06 01 135 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is 136 1cf8f42b5a9f80fae9f831226d5d9d56278661ad. The Base32 encoding of the 137 first ten bytes of this is "dt4pik22t6epv2py". Thus the SASL 138 mechanism name for the SPKM-1 GSSAPI mechanism is "GS2- 139 DT4PIK22T6EPV2PY". 141 4. Protocol specification 143 Each SASL mechanism conforming to this document uses the following 144 specification. 146 4.1. Packet format 148 All messages follow the following format: 150 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | / 156 / GSS_Init_sec_context or / 157 / GSS_Accept_sec_context token, / 158 / of given length / 159 / --------------------/ 160 / ---------------------/ / 161 /--------------------/ / 162 / Optional GSS_Wrap token / 163 / / 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 The "length" field is a 4 octet (32 bit) integer encoded in network 167 byte order, indicating the length of the next field, containing a 168 GSS-API context establishment token. The length field does not 169 include the length of the length field itself. The GSS_Wrap token is 170 optional. Whether it is included or not can be infered from the 171 length field; if the length field is shorter than the entire packet 172 size minus 4 octets, the GSS_Wrap is present and begins after 173 length+4 octets into the packet. The GSS_Wrap token need not be 174 aligned to 32-bit a boundary. There is no padding between the 175 context establishment token and the GSS_Wrap token. 177 Packets shorter than 4 octets are invalid. If the length field is 178 longer than the entire packet size, minus 4 octets, the message is 179 invalid. 181 4.2. Protocol overview 183 This section describe several examples of high-level protocol 184 exchanges. The descriptions do not assume any properties of the 185 actual GSS-API mechanism. Protocol profiles, GSS-API mechanism 186 specific behaviour, and to some extent implementation and policy 187 choices, will dictate which packets are sent in what order. 189 An authentication exchange using GS2 may look like: 191 C: Request authentication exchange 192 S: Send [length=0] token 193 C: Send [length, GSS_Init_sec_context] token 194 ... 195 S: After PROT_READY is set, 196 send [length, GSS_Accept_sec_context, 197 GSS_Wrap(server_qops, server_maxbuf)] 198 C: After PROT_READY is set, 199 send [length, GSS_Init_sec_context, 200 GSS_Wrap (client_qop, client_maxbuf, authzid)] 201 S: Send [length, GSS_Accept_sec_context] token 202 C: Send [length, GSS_Init_sec_context] token 203 ... 204 S: Outcome of authentication exchange 206 The length field contain the length of the GSS_Init_sec_context or 207 GSS_Accept_sec_context token. The receiver can distinguish the case 208 where the GSS_Wrap token is present by comparing the length field 209 value with the total length of the token. The length field will be 0 210 in the initial token from the server to the client (when the protocol 211 profile do not support additional information to be sent together 212 with the authentication request), because GSS-API authentication is 213 initiated by the client. 215 If the PROT_READY flag become set in the client before the server, 216 the client can send the GSS_Wrap token first. In this case, the 217 client must send a bitmap of supported/preferred quality of 218 protection schemes, rather than one single quality of protection 219 method. 221 C: Request authentication exchange 222 S: Send [length=0] token 223 C: Send [length, GSS_Init_sec_context] token 224 ... 225 C: After PROT_READY is set, 226 send [length, GSS_Init_sec_context, 227 GSS_Wrap(client_qops, client_maxbuf, authzid)] 228 S: After PROT_READY is set, 229 send [length, GSS_Accept_sec_context, 230 GSS_Wrap (server_qop, server_maxbuf)] 231 C: Send [length, GSS_Init_sec_context] token 232 S: Send [length, GSS_Accept_sec_context] token 233 ... 234 S: Outcome of authentication exchange 236 The GSS_Wrap tokens can only be sent by the client and server after 237 the PROT_READY flag has been set by GSS_Init_sec_context and 238 GSS_Accept_sec_context, respectively. During any exchange, exactly 239 one GSS_Wrap token is sent in each direction. If more than one 240 GSS_Wrap token is received by either the client or the server, the 241 authentication MUST fail. The GSS_Wrap token does not have to be 242 sent directly whenever the PROT_READY flag is set. 244 If PROT_READY is never set by GSS_Init_sec_context or 245 GSS_Accept_sec_context, the GSS_Wrap messages can be sent after the 246 context has been established. In this case, the length field will 247 encode the integer 0, indicating that the context token is absent. 248 If the context has not been established at that point, the 249 authentication MUST fail. 251 If the protocol profile support the optional initial client response, 252 then the protocol exchange will look like: 254 C: Request authentication exchange and 255 send [length, GSS_Init_sec_context] token 256 S: Send [length, GSS_Accept_sec_context] token 257 C: Send [length, GSS_Init_sec_context] token 258 ... 259 S: Send [length, GSS_Accept_sec_context, 260 GSS_Wrap(server_qops, server_maxbuf)] token 261 C: Send [length, GSS_Init_sec_context, 262 GSS_Wrap (client_qop, client_maxbuf, authzid)] token 263 S: Send [length, GSS_Accept_sec_context] token 264 C: Send [length, GSS_Init_sec_context] token 265 ... 266 S: Outcome of authentication exchange 268 If the protocol profile can also send additional information when 269 indicating the outcome of the authentication, then the protocol 270 exchange will look like: 272 C: Request authentication exchange and 273 send [length, GSS_Init_sec_context] token 274 S: Send [length, GSS_Accept_sec_context] token 275 C: Send [length, GSS_Init_sec_context] token 276 ... 277 S: Send [length, GSS_Accept_sec_context, 278 GSS_Wrap(server_qops, server_maxbuf)] token 279 C: Send [length, GSS_Init_sec_context, 280 GSS_Wrap (client_qop, client_maxbuf, authzid)] token 281 S: Send [length, GSS_Accept_sec_context] token 282 C: Send [length, GSS_Init_sec_context] token 283 ... 284 C: Send [length, GSS_Init_sec_context] token 285 S: Indicate successful authentication and 286 send [length, GSS_Accept_sec_context] token 287 as additional information. 289 The client MUST verify that GSS_Init_context return GSS_S_COMPLETE 290 rather than trust the server's signaling of whether the 291 authentication was successful or not. If the server report 292 successful authentication and GSS_Init_sec_context did not return 293 GSS_S_COMPLETE on the last token, the authentication MUST be aborted 294 by the client. 296 If the PROT_READY flag is never set by the GSS-API mechanism, the 297 GSS_Wrap message will be sent after the context has been established. 298 The protocol may look like: 300 C: Request authentication exchange 301 ... 302 S: GSS_Accept_sec_context return GSS_S_COMPLETE, 303 send [length, GSS_Accept_sec_context] token 304 C: GSS_Init_sec_context return GSS_S_COMPLETE, 305 send [length, GSS_Init_sec_context] token 306 S: Send [length=0, GSS_Wrap(server_qops, server_maxbuf)] token 307 C: Send [length=0, 308 GSS_Wrap(client_qop, client_maxbuf, authzid)] token 309 S: Outcome of authentication exchange 311 Alternatively, if the client finishes first, it may look like: 313 C: Request authentication exchange 314 ... 315 C: GSS_Init_sec_context return GSS_S_COMPLETE, 316 send [length, GSS_Init_sec_context] token 317 S: GSS_Accept_sec_context return GSS_S_COMPLETE, 318 send [length, GSS_Accept_sec_context] token 319 C: Send [length=0, 320 GSS_Wrap(client_qops, client_maxbuf, authzid)] token 321 S: Send [length=0, GSS_Wrap(server_qop, server_maxbuf)] token 322 C: Empty Response 323 S: Outcome of authentication exchange 325 If the entity the finish first does not wish to send its GSS_Wrap 326 message first, it send an empty token to indicate this. Only one 327 empty token is permitted, more than one MUST lead to authentication 328 failure. Empty tokens are not permitted during the initial conext 329 establishment. The following figure illustrate this scenario: 331 C: Request authentication exchange 332 ... 333 C: GSS_Init_sec_context return GSS_S_COMPLETE, 334 send [length, GSS_Init_sec_context] token 335 S: GSS_Accept_sec_context return GSS_S_COMPLETE, 336 send [length, GSS_Accept_sec_context] token 337 C: Empty Response 338 S: Send [length=0, GSS_Wrap(server_qops, server_maxbuf)] token 339 C: Send [length=0, 340 GSS_Wrap(client_qop, client_maxbuf, authzid)] token 341 S: Outcome of authentication exchange 343 This alter which side chose the resulting quality of protection. 344 Earlier, the client sent a bit mask of which quality of protection he 345 support/prefer and the server chose one. Now, the server send a bit 346 mask of which quality of protections it support/prefer, and the 347 client chose one. Implementations are encouraged to pick the 348 strongest available method if there is a choice, but local policy may 349 dictate that a weaker method is to be used. If the client_qop or 350 server_qop received by the server or client does not match the 351 server_qops or client_qops bitmask, the semantic is that the 352 indicated (i.e., through client_qop or server_qop) quality of 353 protection is required by the other end to complete the 354 authentication. The entity receiving such a message may decide using 355 local policy whether to continue authentication or not. Normally, 356 the authentication is aborted (because the other end did not meet the 357 supported/preferred quality of protections announced by the local 358 end), but in some cases, accepting the other ends decision may be 359 acceptable. Note that the quality of protection fields are both 360 integrity and privacy protected, thus protecting this negotiation. 362 If the protocol support initial data from the client, and the 363 PROT_READY flag is set in the client after the first call to 364 GSS_Init_sec_context, and the server can send additional data to the 365 client when indicating successful authentication, the following 366 protocol exchange will occur. 368 C: Request authentication exchange and 369 send [length, GSS_Init_sec_context, 370 GSS_Wrap (client_qops, client_maxbuf, authzid)] token 371 S: Indicate successful authentication and 372 send [length, GSS_Accept_sec_context, 373 GSS_Wrap(server_qop, server_maxbuf)] token 374 as additional information. 376 The last example illustrate the optimal (round-trip wise) 377 authentication possible using this protocol. 379 4.3. GSS-API parameters 381 The implementation MAY set any GSSAPI flags or arguments not 382 mentioned in this specification as is necessary for the 383 implementation to enforce its security policy. 385 4.4. Security layer bits 387 The security layers and their corresponding bit-masks are as follows: 389 1 No security layer 390 2 Integrity protection. 391 Sender calls GSS_Wrap with conf_flag set to FALSE 392 4 Confidentiality protection. 393 Sender calls GSS_Wrap with conf_flag set to TRUE 395 Other bit-masks may be defined in the future; bits which are not 396 understood must be negotiated off. 398 Note that SASL negotiates the maximum size of the output_message to 399 send. Implementations can use the GSS_Wrap_size_limit call to 400 determine the corresponding maximum size input_message. 402 4.5. Authorization identity format 404 The authorization identity is encoded using UTF-8 [6]. The 405 authorization identity is not terminated with the NUL (U+0000) 406 character. 408 4.6. Client side of authentication protocol exchange 410 The client calls GSS_Init_sec_context, passing in 411 input_context_handle of 0 (initially), mech_type of the GSSAPI 412 mechanism for which this SASL mechanism is registered, any 413 chan_binding if requested by the application, and targ_name equal to 414 output_name from GSS_Import_Name called with input_name_type of 415 GSS_C_NT_HOSTBASED_SERVICE and input_name_string of 416 "service@hostname" where "service" is the service name specified in 417 the protocol's profile, and "hostname" is the fully qualified host 418 name of the server. If the client will be requesting a security 419 layer, it MUST also supply to the GSS_Init_sec_context a 420 mutual_req_flag of TRUE, a sequence_req_flag of TRUE, and an 421 integ_req_flag of TRUE. If the client will be requesting a security 422 layer providing confidentiality protection, it MUST also supply to 423 the GSS_Init_sec_context a conf_req_flag of TRUE. The client then 424 send a four-octet network byte order integer encoding the length of 425 the resulting output_token, concatenated with the actual token. If 426 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client 427 should expect the server to issue a token in a subsequent challenge 428 or as additional information to the outcome of the authentication. 429 The token received from the server will be prefixed with a four-octet 430 network byte-order integer encoding the length of the context token. 431 The client must pass the context token to another call to 432 GSS_Init_sec_context, repeating the actions in this paragraph, until 433 GSS_S_COMPLETE is returned or authentication is aborted. If the 434 server supply data beyond the context token, the context token should 435 be processed first, and then the overflow data should be passed to 436 GSS_Unwrap and the unwrapped data should be interpreted as described 437 below. 439 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines 440 the context to ensure that it provides a level of protection 441 permitted by the client's security policy. If the context is 442 unacceptable, the client abort the authentication. Otherwise, if the 443 last call to GSS_Init_sec_context returned an output_token, that 444 token is returned to the server (prefixed with the length integer) 445 together with a GSS_Wrap token, unless the client already sent the 446 GSS_Wrap token earlier. If the call to GSS_Init_sec_context did not 447 return any additional token in output_token, it will respond with an 448 empty context token (i.e., a length field value of 0) and a GSS_Wrap 449 token, unless the client already sent the GSS_Wrap token earlier. 451 When the context has been established, or if the PROT_READY flag is 452 set by the call to GSS_Init_sec_context, the client may send, in 453 addition to the length field and output_token (if any), a GSS_Wrap 454 token. The client passes data to GSS_Wrap with conf_flag set to 455 FALSE, and responds with the generated output_message. 457 If the client has not received a GSS_Wrap token from the server yet, 458 the data will contain one octet with a bit-mask indicating the 459 client's supported/preferred security layer ("client_qops"), then 460 three octets encoding, in network byte order, an integer indicating 461 the maximum message size ("client_maxbuf") that the client can 462 receive (set to 0 if no integrity or privacy layer is requested), and 463 the remaining data is the UTF-8 [6] encoded authorization identity 464 ("authzid") which may be empty. The client will later expect a 465 GSS_Wrap token from the server. The client passes this token to 466 GSS_Unwrap and interprets the first octet of resulting cleartext as 467 the selected security layer ("server_qop"), and the second through 468 fourth octets as the network byte order maximum size output_message 469 to send to the server ("server_maxbuf"). The client will verify that 470 the selected security layer is acceptable, it may be different from 471 what was requested in "client_qops". 473 If the client has received a GSS_Wrap token from the server earlier, 474 the client passes that token to GSS_Unwrap and interprets the first 475 octet of resulting cleartext as a bit-mask indicating the supported/ 476 preferred security layer that the server wish to use ("server_qops"), 477 and the second through fourth octets as the network byte order 478 integer indicating the maximum size output_message to send to the 479 server ("server_maxbuf"). The client then proceed to create the data 480 used as input to GSS_Wrap. The data will contain one octet 481 indicating the selected quality of protection level ("client_qop"), 482 which should be one of those indicated in the bit-mask received from 483 the server (but may be different if the client would abort 484 authentication here and want to give the server a chance to use a 485 different security method), three octets encoding, in network byte 486 order, an integer indicating the maximum buffer size 487 ("client_maxbuf") that the client can receive (set to 0 if no 488 integrity or privacy layer is requested), and the remaining octets 489 containing the UTF-8 [6] encoded authorization identity ("authzid") 490 which may be empty. 492 The client must validate the GSS_Wrap token it receive from the 493 server. If the resulting cleartext received from GSS_Unwrap is not 4 494 octets long, the client fails the negotiation. The client verifies 495 that the server maximum buffer is 0 if the server doesn't advertise 496 support for any security layer. 498 4.7. Server side of authentication protocol exchange 500 The server passes the first client response to GSS_Accept_sec_context 501 as input_token, setting input_context_handle to 0 (initially), 502 mech_type of the GSSAPI mechanism for which this SASL mechanism is 503 registered, any chan_binding if requested by the application, and 504 acceptor_cred_handle equal to output_cred_handle from 505 GSS_Acquire_cred called with desired_name equal to output_name from 506 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE 507 and input_name_string of "service@hostname" where "service" is the 508 service name specified in the protocol's profile, and "hostname" is 509 the fully qualified host name of the server. If 510 GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server send 511 to the client the challenge, consisting of a four-octet network byte 512 order integer encoding the length of the resulting output_token, 513 concatenated with the actual token. The server must pass the 514 resulting challenge from the client to another call to 515 GSS_Accept_sec_context, repeating the actions in this paragraph, 516 until GSS_S_COMPLETE is returned or authentication is aborted. If 517 the client supply data beyond the context token, the context token 518 should be processed first, and then the overflow data should be 519 passed to GSS_Unwrap and the unwrapped data should be interpreted as 520 described below. 522 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server 523 examines the context to ensure that it provides a level of protection 524 permitted by the server's security policy. If the context is 525 unacceptable, the server abort the authentication. Otherwise, if the 526 last call to GSS_Accept_sec_context returned an output_token, the 527 server returns it to the client in a challenge (prefixed with the 528 length integer) together with a GSS_Wrap token, unless the server 529 already sent the GSS_Wrap token earlier. If the 530 GSS_Accept_sec_context did not return an output token, the server 531 return an empty context (i.e., length=0) together with a GSS_Wrap 532 token, unless the server already sent the GSS_Wrap token earlier. 534 When the context has been established, or if the PROT_READY flag is 535 set by the call to GSS_Accept_sec_context, the server may send, in 536 addition to the length field and output_token (if any), a GSS_Wrap 537 token. The server passes data to GSS_Wrap with conf_flag set to 538 FALSE, and responds with the generated output_message. 540 If the server has not received a GSS_Wrap token from the client yet, 541 the data will contain one octet with a bit-mask indicating the 542 server's supported/preferred security layer ("server_qops"), then 543 three octets encoding, in network byte order, an integer indicating 544 the maximum message size ("server_maxbuf") that the server can 545 receive (set to 0 if no integrity or privacy layer is requested). 546 The server will later expect a GSS_Wrap token from the client. The 547 server pass this token to GSS_Unwrap and interprets the first octet 548 of resulting cleartext as the selected security layer ("client_qop"), 549 and the second through fourth octets as the network byte order 550 maximum size output_message to send to the client ("client_maxbuf"). 551 The server will verify that the selected security layer is 552 acceptable, it may be different from what indicated in "server_qops". 554 If the server has received a GSS_Wrap token from the client earlier, 555 the server passes that token to GSS_Unwrap and interprets the first 556 octet of resulting cleartext as a bit-mask indicating the client's 557 supported/preferred security layer ("client_qops"), and the second 558 through fourth octets as the network byte order integer indicating 559 the maximum size output_message to send to the client 560 ("client_maxbuf"). The server then proceed to create the data used 561 as input to GSS_Wrap. The data will contain one octet indicating the 562 selected security layer ("server_qop"), which should be one of those 563 indicated in the bit-mask received from the client (but may be 564 different if the server would abort authentication here and want to 565 give the client a chance to use a different security method), three 566 octets encoding, in network byte order, an integer indicating the 567 maximum buffer size ("server_maxbuf") that the server can receive 568 (set to 0 if no integrity or privacy layer is requested), and the 569 remaining octets containing the UTF-8 [6] encoded authorization 570 identity ("authzid") which may be empty. The server must verify that 571 the src_name identity is authorized to authenticate as the 572 authorization identity. After these verifications, the 573 authentication process is complete. 575 The server must validate the GSS_Wrap token it receive from the 576 client. If the resulting cleartext received from GSS_Unwrap is 577 shorter than 4 octets, the server fails the negotiation. The server 578 verifies that the server maximum buffer is 0 if the server doesn't 579 advertise support for any security layer. 581 5. SPNEGO 583 Use of The Simple and Protected GSS-API Negotiation Mechanism [10] 584 (SPNEGO) underneath SASL introduces subtle interoperability problems 585 and security considerations. To address these, this section places 586 additional requirements on implementations which support SPNEGO 587 underneath SASL. 589 A client which supports, for example, the Kerberos V5 GSSAPI 590 mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL 591 mechanism will not interoperate with a server which supports the 592 Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL 593 mechanism. A client that only support Kerberos V5 underneath "GSS- 594 SPNEGO" will not interoperate with a server that only support 595 Kerberos V5 in the GS2 mechanism and the GS2 SPNEGO mechanism. 597 Since SASL is capable of negotiating amongst GSSAPI mechanisms, the 598 only reason for a server or client to support the "GSS-SPNEGO" 599 mechanism is to allow a policy of only using mechanisms below a 600 certain strength if those mechanism's negotiation is protected. In 601 such a case, a client or server would only want to negotiate those 602 weaker mechanisms through SPNEGO. In any case, there is no down- 603 negotiation security consideration with using the strongest mechanism 604 and set of options the implementation supports, so for 605 interoperability that mechanism and set of options MUST be negotiable 606 without using the "GSS-SPNEGO" or the GS2 SPNEGO mechanism. 608 If a client's policy is to first prefer GSSAPI mechanism X, then non- 609 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports 610 mechanisms Y and Z but not X, then if the client attempts to 611 negotiate mechanism X by using the "GSS-SPNEGO" or the GS2 SPNEGO 612 mechanism, it may end up using mechanism Z when it should have used 613 mechanism Y. For this reason, implementations MUST exclude from 614 SPNEGO those GSSAPI mechanisms which are weaker than the strongest 615 non-GSSAPI SASL mechanism advertised by the server. 617 The situation is complicated by the fact that SPNEGO may be 618 negotiated through both the "GSS-SPNEGO" mechanism and the GS2 SPNEGO 619 mechanism. Because all the functionality in the "GSSAPI" and "GSS- 620 SPNEGO" mechanisms are available through the GS2 mechanism, and the 621 GS2 family in addition also offer channel bindings and round-trip 622 optimizations, it is expected that migration to the GS2 family will 623 eventually happen. 625 6. IANA Considerations 627 The IANA is advised that SASL mechanism names starting with "GS2-" 628 are reserved for SASL mechanisms which conform to this document. The 629 IANA is directed to place a statement to that effect in the sasl- 630 mechanisms registry. 632 Subject: Registration of SASL mechanism GS2-* 633 Family of SASL mechanisms: YES 634 SASL mechanism prefix: GS2- 635 Security considerations: RFC [THIS-DOC] 636 Published specification: RFC [THIS-DOC] 637 Person & email address to contact for further information: 638 Simon Josefsson 639 Intended usage: COMMON 640 Owner/Change controller: iesg@ietf.org 641 Note: 642 The Kerberos V5 and SPNEGO mechanisms are also supported 643 through the GSSAPI and GSS-SPNEGO mechanisms, respectively. 645 7. Security Considerations 647 Security issues are discussed throughout this memo. 649 When a server or client supports multiple authentication mechanisms, 650 each of which has a different security strength, it is possible for 651 an active attacker to cause a party to use the least secure mechanism 652 supported. There are several ways to mitigate this problem: 654 1. Integrity protected transports can be used, e.g., TLS [13]. To 655 protect against certain tunnel attacks [15] with that solution, a 656 mechanism that support channel bindings that can bind the 657 security layer (e.g., the TLS session id) to the authentication 658 is required. 659 2. A client or server which supports mechanisms of different 660 strengths should have a configurable minimum strength that it 661 will use. It is not sufficient for this minimum strength check 662 to only be on the server, since an active attacker can change 663 which mechanisms the client sees as being supported, causing the 664 client to send authentication credentials for its weakest 665 supported mechanism. 666 3. The SPNEGO mechanism can be used securely negotiate among GSS-API 667 mechanisms. This solution can only be used if all the SASL 668 mechanisms are GSS-API mechanisms. 670 Because the negotiation of a GSS-API mechanism may be done in the 671 clear, it is important for the GSS-API mechanisms to be designed such 672 that an active attacker cannot obtain an authentication with weaker 673 security properties by modifying the challenges and responses. 675 SPNEGO [10] has protection against many of these down-negotiation 676 attacks, SASL does not itself have such protection. The section 677 titled "SPNEGO" mentions considerations of choosing negotiation 678 through SASL versus SPNEGO. 680 The integrity protection provided by the security layer is useless to 681 the client unless the client also requests mutual authentication. 682 Therefore, a client wishing to benefit from the integrity protection 683 of a security layer MUST pass to the GSS_Init_sec_context call a 684 mutual_req_flag of TRUE. 686 When constructing the input_name_string, the client should not 687 canonicalize the server's fully qualified domain name using an 688 insecure or untrusted directory service, e.g., the Domain Name System 689 [8] without DNSSEC [14]. 691 Additional security considerations are in the SASL and GSSAPI 692 specifications. Additional security considerations for the Kerberos 693 V5 GSSAPI mechanism can be found in [9]. We stress that service 694 names should not be canonicalized using an unsecured directory 695 service such as the DNS without DNSSEC. 697 8. Acknowledgements 699 This document is a revision of RFC 2222 written by John G. Myers. He 700 also contributed significantly to this revision. This version was 701 derived from draft-ietf-sasl-gssapi-02 which was prepared by Alexey 702 Melnikov. 704 Contributions of many members of the SASL mailing list are gratefully 705 acknowledged. 707 9. Copying conditions 709 Regarding the portion of this document that was written by Simon 710 Josefsson ("the author", for the remainder of this section), the 711 author makes no guarantees and is not responsible for any damage 712 resulting from its use. The author grants irrevocable permission to 713 anyone to use, modify, and distribute it in any way that does not 714 diminish the rights of anyone else to use, modify, and distribute it, 715 provided that redistributed derivative works do not contain 716 misleading author or version information. Derivative works need not 717 be licensed under similar terms. 719 10. References 721 10.1. Normative References 723 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 724 Levels", BCP 14, RFC 2119, March 1997. 726 [2] Myers, J., "Simple Authentication and Security Layer (SASL)", 727 RFC 2222, October 1997. 729 [3] Linn, J., "Generic Security Service Application Program 730 Interface Version 2, Update 1", RFC 2743, January 2000. 732 [4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", 733 RFC 3174, September 2001. 735 [5] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", 736 RFC 3548, July 2003. 738 [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 739 STD 63, RFC 3629, November 2003. 741 [7] "Information Processing Systems - Open Systems Interconnection - 742 Specification of Abstract Syntax Notation One (ASN.1)", ISO 743 Standard 8824. 745 10.2. Informative References 747 [8] Mockapetris, P., "Domain names - concepts and facilities", 748 STD 13, RFC 1034, November 1987. 750 [9] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, 751 June 1996. 753 [10] Baize, E. and D. Pinkas, "The Simple and Protected GSS-API 754 Negotiation Mechanism", RFC 2478, December 1998. 756 [11] Melnikov, A., "SASL GSSAPI mechanisms", 757 draft-ietf-sasl-gssapi-03 (work in progress), September 2005. 759 [12] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", 760 RFC 2025, October 1996. 762 [13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 763 RFC 2246, January 1999. 765 [14] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 766 "DNS Security Introduction and Requirements", RFC 4033, 767 March 2005. 769 [15] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in 770 Tunneled Authentication", 771 WWW http://www.saunalahti.fi/~asokan/research/mitm.html. 773 Author's Address 775 Simon Josefsson 777 Email: simon@josefsson.org 779 Intellectual Property Statement 781 The IETF takes no position regarding the validity or scope of any 782 Intellectual Property Rights or other rights that might be claimed to 783 pertain to the implementation or use of the technology described in 784 this document or the extent to which any license under such rights 785 might or might not be available; nor does it represent that it has 786 made any independent effort to identify any such rights. Information 787 on the procedures with respect to rights in RFC documents can be 788 found in BCP 78 and BCP 79. 790 Copies of IPR disclosures made to the IETF Secretariat and any 791 assurances of licenses to be made available, or the result of an 792 attempt made to obtain a general license or permission for the use of 793 such proprietary rights by implementers or users of this 794 specification can be obtained from the IETF on-line IPR repository at 795 http://www.ietf.org/ipr. 797 The IETF invites any interested party to bring to its attention any 798 copyrights, patents or patent applications, or other proprietary 799 rights that may cover technology that may be required to implement 800 this standard. Please address the information to the IETF at 801 ietf-ipr@ietf.org. 803 Disclaimer of Validity 805 This document and the information contained herein are provided on an 806 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 807 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 808 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 809 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 810 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 811 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 813 Copyright Statement 815 Copyright (C) The Internet Society (2005). This document is subject 816 to the rights, licenses and restrictions contained in BCP 78, and 817 except as set forth therein, the authors retain all their rights. 819 Acknowledgment 821 Funding for the RFC Editor function is currently provided by the 822 Internet Society.