idnits 2.17.1 draft-ietf-sasl-gs2-10.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1145. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1156. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1163. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1169. 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 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 (July 13, 2008) is 5738 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 960, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ITU.X690.1994' -- Obsolete informational reference (is this intentional?): RFC 4346 (Obsoleted by RFC 5246) == Outdated reference: A later version (-10) exists of draft-altman-tls-channel-bindings-01 == Outdated reference: A later version (-06) exists of draft-ietf-kitten-extended-mech-inquiry-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Josefsson 3 Internet-Draft July 13, 2008 4 Intended status: Standards Track 5 Expires: January 14, 2009 7 Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family 8 draft-ietf-sasl-gs2-10 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 14, 2009. 35 Abstract 37 This document describes how to use a Generic Security Service 38 Application Program Interface (GSS-API) mechanism in the the Simple 39 Authentication and Security Layer (SASL) framework. This is done by 40 defining a new SASL mechanism family, called GS2. This mechanism 41 family offers a number of improvements over the previous SASL/GSS-API 42 mechanism: it is more general, uses fewer messages for the 43 authentication phase in some cases, and supports a SASL-specific 44 notion of channel binding. 46 See for more information. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. Conventions used in this document . . . . . . . . . . . . . . 5 52 3. Mechanism name . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3.1. Generating SASL mechanism names from GSS-API OIDs . . . . 6 54 3.2. Computing mechanism names manually . . . . . . . . . . . . 6 55 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. SASL Authentication Exchange Message Format . . . . . . . . . 8 57 4.1. SASL Messages . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2. Context Token Field . . . . . . . . . . . . . . . . . . . 9 59 4.2.1. Client side . . . . . . . . . . . . . . . . . . . . . 9 60 4.2.2. Server side . . . . . . . . . . . . . . . . . . . . . 10 61 4.3. Wrap Token Field . . . . . . . . . . . . . . . . . . . . . 11 62 4.3.1. The GS2_Wrap function . . . . . . . . . . . . . . . . 12 63 4.3.2. Client first GS2_Wrap input . . . . . . . . . . . . . 12 64 4.3.3. Server last GS2_Wrap input . . . . . . . . . . . . . . 13 65 4.3.4. Server first GS2_Wrap input . . . . . . . . . . . . . 14 66 4.3.5. Client last GS2_Wrap input . . . . . . . . . . . . . . 14 67 5. Channel Bindings . . . . . . . . . . . . . . . . . . . . . . . 15 68 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 16 69 7. Authentication Conditions . . . . . . . . . . . . . . . . . . 20 70 8. GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 21 71 9. Security Layer Bits . . . . . . . . . . . . . . . . . . . . . 22 72 9.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23 73 10. Non-integrity capable GSS-API mechanisms . . . . . . . . . . . 24 74 11. Interoperability with the SASL "GSSAPI" mechanism . . . . . . 25 75 11.1. The interoperability problem . . . . . . . . . . . . . . . 25 76 11.2. Resolving the problem . . . . . . . . . . . . . . . . . . 25 77 11.3. Additional recommendations . . . . . . . . . . . . . . . . 25 78 12. Mechanisms that negotiate other mechanisms . . . . . . . . . . 26 79 12.1. The interoperability problem . . . . . . . . . . . . . . . 26 80 12.2. Security problem . . . . . . . . . . . . . . . . . . . . . 26 81 12.3. Resolving the problems . . . . . . . . . . . . . . . . . . 26 82 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 83 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 84 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 85 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 86 16.1. Normative References . . . . . . . . . . . . . . . . . . . 31 87 16.2. Informative References . . . . . . . . . . . . . . . . . . 31 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 33 89 Intellectual Property and Copyright Statements . . . . . . . . . . 34 91 1. Introduction 93 Generic Security Service Application Program Interface (GSS-API) 94 [RFC2743] is a framework that provide security services to 95 applications. Simple Authentication and Security Layer (SASL) 96 [RFC4422] is a framework to provide authentication and security 97 layers for connection based protocols. This document describe how to 98 use a GSS-API mechanism in a connection-based protocol using the SASL 99 framework. 101 All GSSAPI mechanisms are implicitly registered for use within SASL 102 by this specification. The SASL mechanism defined in this document 103 is known as the GS2 family. 105 The "Kerberos V5 GSS-API mechanism" [RFC1964] is also supported in 106 SASL through "SASL GSSAPI mechanisms" [RFC4752]. The difference 107 between that protocol and the one described here, is that this 108 protocol offer more features (i.e., channel bindings and round-trip 109 optimizations) while the other protocol is more widely deployed. 110 There are interoperability concerns by having the same GSS-API 111 mechanism available under more than one SASL mechanism name, see the 112 section "Interoperability with the GSSAPI mechanism" below. 114 There are interoperability and security concerns if this SASL 115 mechanism is used together with a GSS-API mechanism that negotiate 116 other GSS-API mechanisms (such as SPNEGO [RFC4178]), see the section 117 "Mechanisms that negotiate other mechanisms" below. 119 There are interoperability and security concerns with GSSAPI 120 mechanism that do not provide integrity, see the section "Non- 121 integrity capable GSS-API mechanisms" below. 123 SASL mechanism names starting with "GS2-" are reserved for SASL 124 mechanisms which conform to this document. 126 The IESG is considered to be the owner of all SASL mechanisms which 127 conform to this document. This does not necessarily imply that the 128 IESG is considered to be the owner of the underlying GSSAPI 129 mechanism. 131 2. Conventions used in this document 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 3. Mechanism name 139 3.1. Generating SASL mechanism names from GSS-API OIDs 141 The SASL mechanism name for a GSS-API mechanism is the concatenation 142 of the string "GS2-" and the Base32 encoding [RFC4648] (with an upper 143 case alphabet) of the first ten bytes of the binary SHA-1 hash 144 [FIPS.180-1.1995] string computed over the ASN.1 DER encoding 145 [ITU.X690.1994], including the tag and length octets, of the GSS-API 146 mechanism's Object Identifier. The Base32 rules on padding 147 characters and characters outside of the base32 alphabet are not 148 relevant to this use of Base32. If any padding or non-alphabet 149 characters are encountered, the name is not a GS2 family mechanism 150 name. 152 3.2. Computing mechanism names manually 154 The SASL mechanism name may be computed manually. This is useful 155 when the set of supported GSS-API mechanisms is known in advance. It 156 also obliterate the need to implement Base32, SHA-1 and DER in the 157 SASL mechanism. The computed mechanism name can be used directly in 158 the implementation, and the implementation need not concern itself 159 with that the mechanism is part of a mechanism family. 161 3.3. Examples 163 The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1. The 164 ASN.1 DER encoding of the OID, including the tag and length, is (in 165 hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER 166 encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 167 27 86 61 ad. Convert the first ten octets to binary, and re-group 168 them in groups of 5, and convert them back to decimal, which results 169 in these computations: 171 hex: 172 1c f8 f4 2b 5a 9f 80 fa e9 f8 174 binary: 175 00011100 11111000 11110100 00101011 01011010 176 10011111 10000000 11111010 11101001 11111000 178 binary in groups of 5: 179 00011 10011 11100 01111 01000 01010 11010 11010 180 10011 11110 00000 01111 10101 11010 01111 11000 182 decimal of each group: 183 3 19 28 15 8 10 26 26 19 30 0 15 21 26 15 24 185 base32 encoding: 186 D T 4 P I K 2 2 T 6 A P V 2 P Y 188 The last step translate each decimal value using table 3 in Base32 189 [RFC4648]. Thus the SASL mechanism name for the SPKM-1 GSSAPI 190 mechanism is "GS2-DT4PIK22T6APV2PY". 192 The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is 193 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 194 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 195 93 25 51 6a fc ff 04 b0 43 60. Convert the first ten octets to 196 binary, and re-group them in groups of 5, and convert them back to 197 decimal, which results in these computations: 199 hex: 200 82 d2 73 25 76 6b d6 c8 45 aa 202 binary: 203 10000010 11010010 01110011 00100101 01110110 204 01101011 11010110 11001000 01000101 10101010 206 binary in groups of 5: 207 10000 01011 01001 00111 00110 01001 01011 10110 208 01101 01111 01011 01100 10000 10001 01101 01010 210 decimal of each group: 211 16 11 9 7 6 9 11 22 13 15 11 12 16 17 13 10 213 base32 encoding: 214 Q L J H G J L W N P L M Q R N K 216 The last step translate each decimal value using table 3 in Base32 217 [RFC4648]. Thus the SASL mechanism name for the Kerberos V5 GSSAPI 218 mechanism is "GS2-QLJHGJLWNPLMQRNK". 220 4. SASL Authentication Exchange Message Format 222 4.1. SASL Messages 224 During the SASL authentication exchange for GS2, a number of messages 225 following the following format is sent between the client and server. 227 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Context length | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Wrap token length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | / 235 / [Context token] / 236 / --------------------/ 237 / ---------------------/ / 238 /--------------------/ / 239 / [Wrap token] / 240 / / 241 / | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 The "Context length" and "Wrap token length" fields each contain a 4 245 octet (32 bit) integer encoded in network byte order, that indicate 246 the length of the "Context token" and "Wrap token" fields, 247 respectively. A length of 0 means that a particular field is not 248 present. 250 The "Context token" field, if present, contain a GSS-API context 251 establishment token generated by GSS_Init_sec_context or 252 GSS_Accept_sec_context. 254 The "Wrap token" field, if present, contain the output generated by 255 the GS2_Wrap function. 257 The fields need not be aligned to 32-bit a boundary. There is no 258 padding between fields. 260 Messages shorter than or equal to 8 octets are invalid. (The only 261 exception is the initial empty challenge sent by the server which may 262 be 0 octets.) From that it follows that at least one of the "Context 263 token length" and the "Wrap token length" integers MUST be non-zero 264 in a particular message. If the sum of the length integers is longer 265 than the entire message size, minus 8 octets for the length fields, 266 the message is invalid. 268 During any successful authentication exchange, the client and server 269 will each send exactly one (non-empty) "Wrap token". 271 Conforming implementations MUST NOT send additional data after the 272 above message syntax, and MUST ignore additional data. To 273 illustrate, implementations MUST NOT assume that the last "Wrap token 274 length" octets of the packet correspond to the "Wrap token", because 275 that would be incorrect if the packet contained additional data not 276 described by this document. 278 4.2. Context Token Field 280 The format of the "Context token" field inside the SASL token is 281 defined by each GSS-API mechanism, and the data is computed by (for 282 the client) GSS_Init_sec_context and (for the server) 283 GSS_Accept_sec_context. 285 4.2.1. Client side 287 The client calls GSS_Init_sec_context, passing in 288 input_context_handle of GSS_C_NO_CONTEXT (initially), mech_type of 289 the GSSAPI mechanism for which this SASL mechanism is registered, the 290 chan_binding is set to NULL, and targ_name equal to output_name from 291 GSS_Import_Name called with input_name_type of 292 GSS_C_NT_HOSTBASED_SERVICE (*) and input_name_string of 293 "service@hostname" where "service" is the service name specified in 294 the protocol's profile, and "hostname" is the fully qualified host 295 name of the server. 297 (*) - Clients MAY use name types other than 298 GSS_C_NT_HOSTBASED_SERVICE to import servers' acceptor names, but 299 only when they have a priori knowledge that the servers support 300 alternate name types. Otherwise clients MUST use 301 GSS_C_NT_HOSTBASED_SERVICE for importing acceptor names. 303 When calling the GSS_Init_sec_context the client SHOULD pass the 304 integ_req_flag of TRUE, but MAY set it to FALSE (see section 10 305 below). If the client intends to request a security layer, it MUST 306 also supply to the GSS_Init_sec_context a mutual_req_flag of TRUE, 307 and a sequence_req_flag of TRUE. If the client will be requesting a 308 security layer providing confidentiality protection, it MUST also 309 supply to the GSS_Init_sec_context a conf_req_flag of TRUE. 311 The client then responds with any resulting output_token. 313 If GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the 314 client expect the server to issue a token in a subsequent challenge 315 or as additional information to the outcome of the authentication. 317 The client pass the context token to another call to 318 GSS_Init_sec_context, repeating the procedure, until GSS_S_COMPLETE 319 is returned or authentication is aborted. 321 If the server sent a (non-empty) "Wrap token", the context token is 322 processed before processing the other tokens. This is required 323 because GSS_Unwrap may need the context to be in the state it is 324 after the "Context token" in the message has been processed. 326 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client MUST 327 examine the context to ensure that it provides a level of protection 328 permitted by the client's security policy. 330 4.2.2. Server side 332 The server passes the first context token to GSS_Accept_sec_context 333 as input_token, setting input_context_handle to GSS_C_NO_CONTEXT 334 (initially), the chan_binding set to NULL, and a suitable 335 acceptor_cred_handle (see below). 337 Servers SHOULD use a credential obtained by calling GSS_Acquire_cred 338 or GSS_Add_cred for the GSS_C_NO_NAME desired_name and the OID of the 339 GSS-API mechanism for which this SASL mechanism is registered (*). 340 Servers MAY use GSS_C_NO_CREDENTIAL as an acceptor credential handle. 341 Servers MAY use a credential obtained by calling GSS_Acquire_cred or 342 GSS_Add_cred for the server's principal name(s) (**) and the GSS-API 343 mechanism for which this SASL mechanism is registered. 345 (*) - Unlike GSS_Add_cred the GSS_Acquire_cred uses an OID set of 346 GSS-API mechanism as an input parameter. The OID set can be created 347 by using GSS_Create_empty_OID_set and GSS_Add_OID_set_member. It can 348 be freed by calling the GSS_Release_oid_set. 350 (**) - Use of server's principal names having 351 GSS_C_NT_HOSTBASED_SERVICE name type and "service@hostname" format, 352 where "service" is the service name specified in the protocol's 353 profile, and "hostname" is the fully qualified host name of the 354 server, is RECOMMENDED. The server name can be generated by calling 355 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE 356 and input_name_string of "service@hostname". 358 The server then responds with any resulting output_token. 360 The server pass any resulting challenge from the client to another 361 call to GSS_Accept_sec_context, repeating the procedure, until 362 GSS_S_COMPLETE is returned or authentication is aborted. 364 If the client sent a (non-empty) "Wrap token", the context token is 365 processed first. 367 Upon successful establishment of the security context (i.e. 368 GSS_Accept_sec_context returns GSS_S_COMPLETE) the server SHOULD 369 verify that the negotiated GSS-API mechanism is indeed the registered 370 one. This is done by examining the value of the mech_type parameter 371 returned from the GSS_Accept_sec_context call. If the value differ, 372 the SASL authentication MUST be aborted. 374 Upon successful establishment of the security context and if the 375 server used GSS_C_NO_NAME/GSS_C_NO_CREDENTIAL to create acceptor 376 credential handle, the server SHOULD also check using the 377 GSS_Inquire_context that the target_name used by the client matches: 379 - the GSS_C_NT_HOSTBASED_SERVICE "service@hostname" name syntax, 380 where "service" is the service name specified in the application 381 protocol's profile, and "hostname" is the fully qualified host name 382 of the server. 384 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server MUST 385 examine the context to ensure that it provides a level of protection 386 permitted by the server's security policy. 388 4.3. Wrap Token Field 390 The Wrap token field MUST NOT be sent or received before the 391 PROT_READY flag is set locally (by GSS_Init_sec_context or 392 Gss_Accept_sec_context), or if the PROT_READY flag is never set, 393 before the context has been fully established. The Wrap token field 394 does not have to be present directly when the PROT_READY flag is set. 395 During any exchange, exactly one Wrap token field is sent in each 396 direction. The GS2_Wrap function is defined below, and its inputs 397 MUST follow the format described below. If not exactly one Wrap 398 token is received by the client and by the server, the authentication 399 MUST fail. 401 If PROT_READY is never set by GSS_Init_sec_context or 402 GSS_Accept_sec_context, the flag is implied by successful context 403 negotiation. This is for GSS-API v1 mechanisms that do not support 404 PROT_READY, or for GSS-API mechanism that do not provide per-message 405 protection. This may result in a SASL token consisting of a context 406 token length of 0 and a Wrap token. 408 The entity that sends the first Wrap token will have to specify a 409 bitmap of supported and preferred quality of protection schemes. The 410 entity that replies to the Wrap tokens will pick a scheme, based on 411 the bitmask and local policy. The quality of protection values are 412 defined in section 9. 414 Two pairs of input formats to the GS2_Wrap function are defined. The 415 first pair is used when the client sends the Wrap token first and the 416 server responds. The other pair is used when the server sends the 417 Wrap token first and the client responds. 419 The inputs below are passed to GS2_Wrap, and the output is used as 420 the Wrap token value. 422 Some fields in the input formats are optional, indicated by brackets 423 ("[" and "]") and explained by the text below. 425 4.3.1. The GS2_Wrap function 427 The GS2_Wrap function have two implementations, and which one is used 428 depends on whether the negotiated GSS-API context supports per- 429 message protection. When a context is successfully negotiated (i.e., 430 when GSS_S_COMPLETE is returned from, for clients, 431 GSS_Init_sec_context, or, for servers, GSS_Accept_sec_context) and 432 the output variable integ_avail is FALSE, then GSS_Wrap cannot be 433 used and instead we define GS2_Wrap to be the identity function. 434 When integ_avail is negotiated TRUE, the GS2_Wrap is identical to 435 calling the GSS_Wrap function with conf_flag set to FALSE and using 436 the generated output_message as the output data. 438 4.3.2. Client first GS2_Wrap input 440 The input to GS2_Wrap when the client sends a Wrap token field first 441 is as follows. 443 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 444 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 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | client_qops | client_maxbuf | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | channel_binding_length | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |[client_cbqops]| [channel_binding_data] / 451 / / 452 / / [authzid] / 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 The "client_qops" integer indicate the client's preferred quality of 456 protection if channel bindings are absent or the negotiation of the 457 channel binding fails. The quality of protection values are defined 458 in section 9. 460 The "client_maxbuf" field indicate the maximum protected buffer size 461 the client can receive in network byte order. It MUST be 0 if the 462 client doesn't advertise support for any security layer, the server 463 MUST verify this. Small values can make it impossible for the server 464 to send any protected message to the client, due to the overhead 465 added by GSS_Wrap, and the server MAY reject the authentication if it 466 detects this situation. 468 The "channel_binding_length" is a network byte order integer that 469 indicate the length of the "channel_binding_data" field. 471 The optional field "client_cbqops" is present only if 472 "channel_binding_length" is non-zero, and indicate the client's 473 preferred quality of protection if channel binding negotiation 474 succeeds. The quality of protection values are defined in section 9. 476 The optional field "channel_binding_data" is present only if 477 "channel_binding_length" is non-zero, and contain the actual channel 478 binding data. 480 The optional field "authzid" contain the authorization identity. The 481 authorization identity is encoded using UTF-8 [RFC3629]. The 482 authorization identity is not terminated with the NUL (U+0000) 483 character. Servers MUST validate that the authorization identity is 484 valid UTF-8. 486 4.3.3. Server last GS2_Wrap input 488 The input to GS2_Wrap when the server sends a Wrap token field, after 489 receiving the Wrap token in the previous section from the client, is 490 as follows. 492 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | server_qop | server_maxbuf | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 The "server_qop" field integer indicate the selected quality of 499 protection. The quality of protection values are defined in section 500 9. 502 The "server_maxbuf" field indicate the maximum protected data buffer 503 size the server can receive in network byte order. It MUST be 0 if 504 the server doesn't advertise support for any security layer, the 505 client MUST verify this. Small values can make it impossible for the 506 client to send any protected message to the server, due to the 507 overhead added by GSS_Wrap, and the client MAY reject the 508 authentication if it detects this situation. 510 4.3.4. Server first GS2_Wrap input 512 The input to GS2_Wrap when the server sends the Wrap token first is 513 as follows. 515 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | server_qops | server_maxbuf | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 |[server_cbqops]| [channel_binding_data] / 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 The "server_qops" field is an integer indicating the server's 524 preferred quality of protection if channel bindings are absent or the 525 negotiation of the channel binding fails. The quality of protection 526 values are defined in section 9. 528 The "server_maxbuf" is the same as above. 530 The optional field "server_cbqops" indicate the server's preferred 531 quality of protection if channel binding negotiation succeeds. The 532 quality of protection values are defined in section 9. 534 The optional field "channel_binding_data" contain the actual channel 535 binding data. 537 4.3.5. Client last GS2_Wrap input 539 The input to GS2_Wrap when the clients sends a Wrap token field, 540 after receiving the Wrap token in the previous section from the 541 server, is as follows. 543 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 544 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 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | client_qop | client_maxbuf | 547 / [authzid] | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 The "client_qop" field is the selected quality of protection. The 551 quality of protection values are defined in section 9. 553 The "client_maxbuf" and "authzid" fields are as above. 555 5. Channel Bindings 557 The GS2 mechanism provide its own channel binding mechanism, instead 558 of using the "chan_binding" parameter in the GSS-API context 559 functions. The reason for this is that the GS2 mechanism provide an 560 option to proceed even if the channel bindings does not match. The 561 GSS-API framework specifies that authentication cannot proceed if 562 channel bindings do not match. 564 Client and servers MUST set the "chan_binding" parameter in the calls 565 to GSS_Init_sec_context and GSS_Accept_sec_context, respectively, to 566 NULL. 568 Implementations SHOULD set the "client_cbqops" and "server_cbqops" to 569 no security layer and instead depend on the session security afforded 570 by the bound-in channel. 572 In order to accomodate the requirement in [RFC5056] "Authentication 573 frameworks and mechanisms that support channel binding MUST 574 communicate channel binding failure to applications" implementations 575 assert a bit in the security layer bitmask (see Section 9) on 576 negotiation failures. 578 Use of no SASL security layers in combination with channel binding 579 should provide better performance than using SASL security layers 580 over secure channels, and better security characteristics than using 581 no SASL security layers over secure channels without channel binding. 583 For more discussions of channel bindings, and the syntax of the 584 channel binding data for various security protocols, see [RFC5056]. 585 For easy reference, the channel binding format used for The Transport 586 Layer Security (TLS) Protocol [RFC4346] is specified in 587 [I-D.altman-tls-channel-bindings]. 589 6. Protocol Overview 591 This section describe several high-level protocol exchanges. The 592 descriptions do not assume any properties of the actual GSS-API 593 mechanism. Protocol profiles, GSS-API mechanism specific behaviour, 594 and to some extent implementation and policy choices, will dictate 595 which packets are sent in what order. The protocol exchanges are 596 examples and other exchanges are permitted and will occur. 598 An informal pseudo-language is used to describe the packets sent 599 below. GS2_Wrap refer to the operation of calling GS2_Wrap on the 600 indicated fields, formatted in the structures described earlier. 601 GSS_Init_sec_context and GSS_Accept_sec_context refer to the context 602 token generated by calling the respective function. The GS2 SASL 603 Message is denoted as [Context_token, Wrap_token], and the length 604 fields are not mentioned. 606 An authentication exchange using GS2 may look like: 608 C: Request authentication exchange 609 S: Empty Challenge 610 C: Send [GSS_Init_sec_context, ""] token 611 ... 612 S: After PROT_READY is set, 613 send [GSS_Accept_sec_context, 614 GS2_Wrap(server_qops | server_maxbuf] 615 ... 616 C: After PROT_READY is set, 617 send [GSS_Init_sec_context, 618 GS2_Wrap (client_qop | client_maxbuf | authzid)] 619 S: Send [GSS_Accept_sec_context, ""] token 620 C: Send [GSS_Init_sec_context, ""] token 621 ... 622 S: Outcome of authentication exchange 624 GSS-API authentication is always initiated by the client. The SASL 625 framework allows either the client and server to initiate 626 authentication. In GS2 the server will send an initial empty 627 challenge (zero byte string) if it has not yet received a token from 628 the client. See section 3 of [RFC4422]. 630 The next example illustrate when the client sends its Wrap token 631 first. 633 C: Request authentication exchange 634 S: Empty Challenge 635 C: Send [GSS_Init_sec_context, ""] token 636 ... 637 C: After PROT_READY is set, 638 send [GSS_Init_sec_context, 639 GS2_Wrap(client_qops | client_maxbuf | 640 channel_binding_length=0 | authzid)] 641 ... 642 S: After PROT_READY is set, 643 send [GSS_Accept_sec_context, 644 GS2_Wrap (server_qop | server_maxbuf)] 645 C: Send [GSS_Init_sec_context, ""] token 646 S: Send [GSS_Accept_sec_context, ""] token 647 ... 648 S: Outcome of authentication exchange 650 If the protocol profile support the optional initial client response, 651 the first empty message can be optimized away, and then the protocol 652 exchange will look like: 654 C: Request authentication exchange and 655 send [GSS_Init_sec_context, ""] token 656 S: Send [GSS_Accept_sec_context, ""] token 657 ... 658 S: Outcome of authentication exchange 660 If the protocol profile can also send additional information when 661 indicating the outcome of the authentication, then the protocol 662 exchange will look like: 664 C: Request authentication exchange and 665 send [GSS_Init_sec_context, ""] token 666 S: Send [GSS_Accept_sec_context, ""] token 667 ... 668 C: Send [GSS_Init_sec_context, ""] token 669 S: Indicate successful authentication and 670 send [GSS_Accept_sec_context, ""] token 671 as additional information. 673 If the PROT_READY flag is never set by the GSS-API mechanism, the 674 GS2_Wrap message will be sent after the context has been established. 675 The protocol may look like: 677 C: Request authentication exchange 678 ... 679 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and outputs 680 a token, send ["", GS2_Wrap(server_qops | server_maxbuf)] 681 C: GSS_Init_sec_context() returns GSS_S_COMPLETE and does not 682 output a token, send 683 ["", GS2_Wrap(client_qop | client_maxbuf | 684 channel_binding_length=0 | authzid)] 685 S: Outcome of authentication exchange 687 Alternatively, if the client finishes first, it may look like: 689 C: Request authentication exchange 690 ... 691 C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a 692 token, send ["", GS2_Wrap(client_qops | client_maxbuf | 693 channel_binding_length=0 | authzid)] 694 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not 695 output a token, send ["", GS2_Wrap(server_qop | server_maxbuf | 696 channel_binding_length=0)] 697 S: Outcome of authentication exchange 699 Adding channel bindings to the last examples, gives the following 700 complex situation. Here the client request confidentiality for the 701 application data if channel binding fails but no SASL security layer 702 if channel binding negotiation succeeds: 704 C: Request authentication exchange 705 ... 706 C: GSS_Init_sec_context() returns GSS_S_COMPLETE and outputs a 707 token, send [GSS_Init_sec_context, 708 GS2_Wrap(client_qops=0x04 | client_maxbuf | 709 channel_binding_length=n | 710 client_cbqops=0x01 | channel_binding_data | 711 authzid)] 712 S: GSS_Accept_sec_context() returns GSS_S_COMPLETE and does not 713 output a token, send ["", 714 GS2_Wrap(server_qop | server_maxbuf | 715 channel_binding_length=0)] 716 S: Outcome of authentication exchange 718 If the protocol support initial data from the client, and the 719 PROT_READY flag is set in the client after the first call to 720 GSS_Init_sec_context, and the server can send additional data to the 721 client when indicating successful authentication, the following 722 protocol exchange will occur. 724 C: Request authentication exchange and 725 send [GSS_Init_sec_context, 726 GS2_Wrap (client_qops | client_maxbuf | 727 channel_binding_length=0 | authzid)] token 728 S: Indicate successful authentication and 729 send [GSS_Accept_sec_context, 730 GS2_Wrap(server_qop | server_maxbuf)] token 731 as additional information. 733 The last example illustrate the optimal (round-trip wise) 734 authentication possible using this protocol. 736 7. Authentication Conditions 738 Authentication MUST NOT succeed if any one of the following 739 conditions are true: 741 o An invalid SASL token is received (e.g., length field checks 742 discussed in section 4.1 fail). 744 o GSS_Init/Accept_sec_context() return anything other than 745 GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE. 747 o GSS_Wrap() returns anything other than GSS_S_COMPLETE. 749 o GSS_Unwrap() returns anything other than GSS_S_COMPLETE. (There 750 can't be supplementary status codes in GS2 at this point, so any 751 indications of out of order processing or replays is fatal.) 753 o The token returned from GSS_Unwrap fail to parse correctly (e.g., 754 too short, invalid maximum buffer size) as the expected Wrap 755 token. 757 o Local policy reject the attempt. For example, client and server 758 can't agree on qop proposal, or channel binding negotiation 759 failed. 761 o (server-side) Authorization of client principal (i.e., src_name in 762 GSS_Acecpt_sec_context) to requested authzid failed. 764 8. GSS-API Parameters 766 The implementation MAY set any GSSAPI flags or arguments not 767 mentioned in this specification as is necessary for the 768 implementation to enforce its security policy. 770 9. Security Layer Bits 772 The fields "client_qops", "server_qops", "client_cbqops", and 773 "server_cbqops" are bit-fields that encode a set of requested quality 774 of protection. The fields "client_qop" and "server_qop" encode a 775 single quality of protection value. 777 The "client_qop" and "server_qop" will contains the chosen security 778 layer. 780 Note that "client_qop" and "server_qop" MAY indicate a quality of 781 protection that was not offered by the server and client, 782 respectively. This SHOULD only be used when the server or client 783 (respectively) would otherwise fail the entire authentication 784 exchange. The server/client that receives a "client_qop"/ 785 "server_qop" MUST verify that it corresponds to an acceptable 786 security level. 788 Whether the channel binding negotiation is successful or not may 789 influence the security layer selection. The most significant bit is 790 used to signal failed channel binding negotiation. Implementations 791 MUST set the bit if channel bindings were provided from the other end 792 and a local channel binding is absent or not equal. Implementation 793 MUST clear the bit otherwise. 795 The security layers and their corresponding bit-masks are as follows: 797 1 No security layer. 798 2 Integrity protection. 799 Sender calls GSS_Wrap with conf_flag set to FALSE. 800 4 Confidentiality protection. 801 Sender calls GSS_Wrap with conf_flag set to TRUE. 802 8-64 Reserved. 803 128 Channel binding negotiation failed. 805 The bit-masks 8-64 are reserved and may be defined in the future; 806 bits which are not understood MUST be negotiated off. 808 When decoding any received data with GSS_Unwrap the major_status 809 other than the GSS_S_COMPLETE MUST be treated as a fatal error. 811 For integrity and confidentiality protection, GS2 negotiates the 812 maximum size of the output_message to send. Implementations can use 813 the GSS_Wrap_size_limit call to determine the corresponding maximum 814 size input_message. 816 9.1. Examples 818 When no security layer is negotiated the octet will encode an integer 819 1 as follows. 821 7 6 5 4 3 2 1 0 822 +-+-+-+-+-+-+-+-+ 823 |0|0|0|0|0|0|0|1| 824 +-+-+-+-+-+-+-+-+ 826 When integrity is negotiated the octet will encode an integer 2 as 827 follows. 829 7 6 5 4 3 2 1 0 830 +-+-+-+-+-+-+-+-+ 831 |0|0|0|0|0|0|1|0| 832 +-+-+-+-+-+-+-+-+ 834 When confidentiality is negotiated, and channel binding negotiation 835 failed, the octet will encode an integer 128+4=132 as follows. 837 7 6 5 4 3 2 1 0 838 +-+-+-+-+-+-+-+-+ 839 |1|0|0|0|0|1|0|0| 840 +-+-+-+-+-+-+-+-+ 842 When a bitmask that indicates that all security layers are 843 acceptable, the octet will encode an integer 1+2+4=7 as follows. 845 7 6 5 4 3 2 1 0 846 +-+-+-+-+-+-+-+-+ 847 |0|0|0|0|0|1|1|1| 848 +-+-+-+-+-+-+-+-+ 850 10. Non-integrity capable GSS-API mechanisms 852 Mechanisms that do not support integrity can be used with GS2, but 853 some security features cannot be provided, in particular including 854 channel bindings, security layers, and integrity protection of the 855 authorization identity. 857 Channel bindings and security layers MUST NOT be negotiated when the 858 GSS-API mechanism do not support integrity. It should also be 859 understood that the authorization identity is not integrity 860 protected. 862 Whether a mechanism supports integrity or not, for the purpose of 863 GS2, is decided by whether the integ_avail output variable from 864 GSS_Init_sec_context (for clients) and GSS_Accept_sec_context (for 865 servers). If integ_avail is FALSE, integrity is not supported. 867 There is a potential interoperability problem if a client call 868 GSS_Init_sec_context with integ_req_flag of TRUE and the context 869 negotiation fails because the mechanism (due to design, the 870 capability of the credentials, or policy) cannot provide per-message 871 protection. Calling GSS_Init_sec_context with a FALSE integ_req_flag 872 instead is not optimal, since a mechanism may then negotiate less 873 security than it would have otherwise done. 875 It is RECOMMENDED that implementations only ever call 876 GSS_Init_sec_context with a integ_req_flag of FALSE when it knows 877 that the particular GSS-API mechanism will not be able to negotiate 878 per-message protection services. 880 Implementations MAY have a policy to disallow non-integrity capable 881 mechanisms, and always call GSS_Init_sec_context with the 882 integ_req_flag set to TRUE. 884 11. Interoperability with the SASL "GSSAPI" mechanism 886 The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL 887 under the name "GSSAPI", see GSSAPI mechanism [RFC4752]. The 888 Kerberos V5 mechanism may also be used with the GS2 family. This 889 causes an interopability problem, which is discussed and resolved 890 below. 892 11.1. The interoperability problem 894 If a client (or server) only support Kerberos V5 under the "GSSAPI" 895 name and the server (or client) only support Kerberos V5 under the 896 GS2 family, the authentication negotiation will fail. 898 11.2. Resolving the problem 900 If the Kerberos V5 mechanism is supported under GS2 in a server, the 901 server SHOULD also support Kerberos V5 through the "GSSAPI" 902 mechanism, to avoid interoperability problems with older clients. 904 Reasons for violating this recommendation may include security 905 considerations regarding the absent features in the GS2 mechanism. 906 The Kerberos V5 "GSSAPI" SASL mechanism lack channel bindings, which 907 could enable certain tunnel attacks [mitm]. 909 11.3. Additional recommendations 911 It is RECOMMENDED to negotiate Kerberos V5 through the GS2 mechanism 912 rather than through the "GSSAPI" mechanism, if both are available, 913 because of the additional features in the GS2 mechanism. 915 12. Mechanisms that negotiate other mechanisms 917 A GSS-API mechanism that negotiate other mechanisms interact badly 918 with the SASL mechanism negotiation. There are two problems. The 919 first is an interoperability problem and the second is a security 920 concern. The problems are described and resolved below. 922 12.1. The interoperability problem 924 If a client implement GSS-API mechanism X, potentially negotiated 925 through a GSS-API mechanism Y, and the server also implement GSS-API 926 mechanism X negotiated through a GSS-API mechanism Z, the 927 authentication negotiation will fail. 929 12.2. Security problem 931 If a client's policy is to first prefer GSSAPI mechanism X, then non- 932 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports 933 mechanisms Y and Z but not X, then if the client attempts to 934 negotiate mechanism X by using a GSS-API mechanism that negotiate 935 other mechanisms (such as SPNEGO), it may end up using mechanism Z 936 when it ideally should have used mechanism Y. For this reason, the 937 use of GSS-API mechanisms that negotiate other mechanisms are 938 disallowed under GS2. 940 12.3. Resolving the problems 942 GSS-API mechanisms that negotiate other mechanisms MUST NOT be used 943 with the GS2 SASL mechanism. This specifically exclude negotiating 944 SPNEGO [RFC4178] under GS2. 946 The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech() 947 [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such 948 mechanisms. 950 13. IANA Considerations 952 The IANA is advised that SASL mechanism names starting with "GS2-" 953 are reserved for SASL mechanisms which conform to this document. The 954 IANA is directed to place a statement to that effect in the sasl- 955 mechanisms registry. 957 Subject: Registration of SASL mechanism GS2-* 958 SASL mechanism prefix: GS2- 959 Security considerations: RFC [THIS-DOC] 960 Published specification: RFC [THIS-DOC] 961 Person & email address to contact for further information: 962 Simon Josefsson 963 Intended usage: COMMON 964 Owner/Change controller: iesg@ietf.org 965 Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms. 967 14. Security Considerations 969 The security provided by GS2 depends on the security provided by the 970 GSS-API mechanism. If the mechanism do not provide integrity 971 protection, the authorization identity can be replaced by a man in 972 the middle, and channel bindings and security layers cannot be 973 negotiated. Therefor, it is generally recommended against using any 974 GSS-API mechanism widely on the Internet that do not support 975 integrity. 977 Because the negotiation of a particular GSS-API mechanism may be done 978 in the clear, it is important for the GSS-API mechanisms to be 979 designed such that an active attacker cannot obtain an authentication 980 with weaker security properties by modifying the challenges and 981 responses. This is a generic design critera for the GSS-API 982 mechanisms used under GS2. 984 GS2 permits channel binding negotiation to fail. Implementation may 985 have a local policy to reject authentication attempts in this case. 987 When a server or client supports multiple GSS-API mechanisms, each of 988 which has a different security strength, it is possible for an active 989 attacker to cause a party to use the least secure mechanism 990 supported. This problem and a solution is discussed in section 6.1.2 991 of [RFC4422], but some additional methods to mitigate the problem 992 include: 994 1. Use of an integrity protected transport, such as TLS [RFC4346]. 995 To protect against certain tunnel attacks [mitm], channel 996 bindings need to be used. 998 2. A client or server which supports mechanisms of different 999 strengths should have a configurable minimum strength that it 1000 will use. It is not sufficient for this minimum strength check 1001 to only be on the server, since an active attacker can change 1002 which mechanisms the client sees as being supported, causing the 1003 client to send authentication credentials for its weakest 1004 supported mechanism. This solution, however, is not guaranteed 1005 to lead to the most secure mechanism supported by both parties, 1006 and is therefor only recommended as an additional precaution. 1008 The channel binding is sent without privacy protection and knowledge 1009 of it is assumed to provide no advantage to an attacker. This is a 1010 property that has to be considered when specifying channel bindings 1011 for a security protocol that will be used with GS2. 1013 When constructing the input_name_string, the client should not 1014 canonicalize the server's fully qualified domain name using an 1015 insecure or untrusted directory service, such as the Domain Name 1016 System [RFC1034] without DNSSEC [RFC4033]. 1018 The GS2 protocol hard code the SHA-1 algorithm for computing the 1019 mechanism names. It is not possible to negotiate another hash 1020 algorithm. However, no traditional cryptographic hash properties 1021 (such as collision resistance or pre-image resistance) are required 1022 nor assumed. The required and assumed property is that it is 1023 statistically unlikely that two different DER-encoded OID's share the 1024 same first 10 octets of the SHA-1 value. It is possible to 1025 practically confirm that the SHA-1 algorithm has the necessary 1026 property, by testing many different inputs. 1028 Additional security considerations are in the SASL and GSSAPI 1029 specifications. Additional security considerations for the Kerberos 1030 V5 GSSAPI mechanism can be found in [RFC1964]. We stress that 1031 service names should not be canonicalized using an unsecured 1032 directory service such as the DNS without DNSSEC. Security issues 1033 are also discussed throughout this memo. 1035 15. Acknowledgements 1037 The history of GS2 can be traced to the GSSAPI mechanism described in 1038 RFC 2222. The GSSAPI mechanism had some drawbacks, which created a 1039 need for an improved version. This document was derived from 1040 draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with 1041 significant contributions from John G. Myers, although the majority 1042 of this document has been rewritten by the current author. 1044 Contributions of many members of the SASL mailing list are gratefully 1045 acknowledged. In particular, ideas and feedback from Sam Hartman, 1046 Jeffrey Hutzelman, Alexey Melnikov, Nicolas Williams, and Tom Yu 1047 improved the document and the protocol. 1049 16. References 1051 16.1. Normative References 1053 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1054 Requirement Levels", BCP 14, RFC 2119, March 1997. 1056 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 1057 Security Layer (SASL)", RFC 4422, June 2006. 1059 [RFC2743] Linn, J., "Generic Security Service Application Program 1060 Interface Version 2, Update 1", RFC 2743, January 2000. 1062 [FIPS.180-1.1995] 1063 National Institute of Standards and Technology, "Secure 1064 Hash Standard", FIPS PUB 180-1, April 1995, 1065 . 1067 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1068 10646", STD 63, RFC 3629, November 2003. 1070 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1071 Encodings", RFC 4648, October 2006. 1073 [ITU.X690.1994] 1074 International Telecommunications Union, "Information 1075 Technology - ASN.1 encoding rules: Specification of Basic 1076 Encoding Rules (BER), Canonical Encoding Rules (CER) and 1077 Distinguished Encoding Rules (DER)", ITU-T Recommendation 1078 X.690, 1994. 1080 [RFC5056] Williams, N., "On the Use of Channel Bindings to Secure 1081 Channels", RFC 5056, November 2007. 1083 16.2. Informative References 1085 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1086 STD 13, RFC 1034, November 1987. 1088 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 1089 RFC 1964, June 1996. 1091 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 1092 Simple and Protected Generic Security Service Application 1093 Program Interface (GSS-API) Negotiation Mechanism", 1094 RFC 4178, October 2005. 1096 [RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple 1097 Authentication and Security Layer (SASL) Mechanism", 1098 RFC 4752, November 2006. 1100 [RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism 1101 (SPKM)", RFC 2025, October 1996. 1103 [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security 1104 (TLS) Protocol Version 1.1", RFC 4346, April 2006. 1106 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1107 Rose, "DNS Security Introduction and Requirements", 1108 RFC 4033, March 2005. 1110 [I-D.altman-tls-channel-bindings] 1111 Altman, J. and N. Williams, "On the Use of Channel 1112 Bindings to Secure Channels", 1113 draft-altman-tls-channel-bindings-01 (work in progress), 1114 December 2006. 1116 [I-D.ietf-kitten-extended-mech-inquiry] 1117 Williams, N., "Extended Generic Security Service Mechanism 1118 Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-02 1119 (work in progress), June 2006. 1121 [mitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle 1122 in Tunneled Authentication", 1123 WWW http://www.saunalahti.fi/~asokan/research/mitm.html. 1125 Author's Address 1127 Simon Josefsson 1129 Email: simon@josefsson.org 1131 Full Copyright Statement 1133 Copyright (C) The IETF Trust (2008). 1135 This document is subject to the rights, licenses and restrictions 1136 contained in BCP 78, and except as set forth therein, the authors 1137 retain all their rights. 1139 This document and the information contained herein are provided on an 1140 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1141 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1142 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1143 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1144 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1145 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1147 Intellectual Property 1149 The IETF takes no position regarding the validity or scope of any 1150 Intellectual Property Rights or other rights that might be claimed to 1151 pertain to the implementation or use of the technology described in 1152 this document or the extent to which any license under such rights 1153 might or might not be available; nor does it represent that it has 1154 made any independent effort to identify any such rights. Information 1155 on the procedures with respect to rights in RFC documents can be 1156 found in BCP 78 and BCP 79. 1158 Copies of IPR disclosures made to the IETF Secretariat and any 1159 assurances of licenses to be made available, or the result of an 1160 attempt made to obtain a general license or permission for the use of 1161 such proprietary rights by implementers or users of this 1162 specification can be obtained from the IETF on-line IPR repository at 1163 http://www.ietf.org/ipr. 1165 The IETF invites any interested party to bring to its attention any 1166 copyrights, patents or patent applications, or other proprietary 1167 rights that may cover technology that may be required to implement 1168 this standard. Please address the information to the IETF at 1169 ietf-ipr@ietf.org.