3 SASL Working Group A. Melnikov
5 Expires: May 22, 2004 November 22, 2003
9 draft-ietf-sasl-gssapi-00
13 This document is an Internet-Draft and is in full conformance with
14 all provisions of Section 10 of RFC2026.
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-
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 http://
27 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 22, 2004.
36 Copyright (C) The Internet Society (2003). All Rights Reserved.
40 The Simple Authentication and Security Layer [SASL] is a method for
41 adding authentication support to connection-based protocols. This
42 document describes the method for using the Generic Security Service
43 Application Program Interface [GSSAPI] in the Simple Authentication
44 and Security Layer [SASL].
46 This document replaces section 7.2 of RFC 2222 [SASL], the definition
47 of the "GSSAPI" SASL mechanism.
55 Melnikov Expires May 22, 2004 [Page 1]
57 Internet-Draft SASL GSSAPI mechanisms November 2003
62 1. Conventions Used in this Document . . . . . . . . . . . . . . 3
63 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4
64 2.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 3. SPNEGO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
66 4. Specification common to all GSSAPI mechanisms . . . . . . . . 6
67 4.1 Client side of authentication protocol exchange . . . . . . . 6
68 4.2 Server side of authentication protocol exchange . . . . . . . 7
69 4.3 Security layer . . . . . . . . . . . . . . . . . . . . . . . . 8
70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
73 Normative References . . . . . . . . . . . . . . . . . . . . . 13
74 Informative References . . . . . . . . . . . . . . . . . . . . 14
75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14
76 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
111 Melnikov Expires May 22, 2004 [Page 2]
113 Internet-Draft SASL GSSAPI mechanisms November 2003
116 1. Conventions Used in this Document
118 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
119 in this document are to be interpreted as defined in "Key words for
120 use in RFCs to Indicate Requirement Levels" [KEYWORDS].
167 Melnikov Expires May 22, 2004 [Page 3]
169 Internet-Draft SASL GSSAPI mechanisms November 2003
172 2. Introduction and Overview
174 Each and every GSSAPI mechanism used within SASL is implicitly
175 registered by this specification.
177 For backwards compatibility with existing implementations of Kerberos
178 V5 and SPNEGO under SASL, the SASL mechanism name for the Kerberos V5
179 GSSAPI mechanism [KRB5GSS] is "GSSAPI" and the SASL mechanism for the
180 SPNEGO GSSAPI mechanism [SPNEGO] is "GSS-SPNEGO". The SASL mechanism
181 name for any other GSSAPI mechanism is the concatenation of "GSS-"
182 and the Base32 [BASE-ENCODING] encoding of the first ten bytes of the
183 MD5 hash [MD5] of the ASN.1 DER encoding [ASN1] of the GSSAPI
184 mechanism's OID. The Base32 rules on padding characters and
185 characters outside of the base32 alphabet are not relevant to this
188 SASL mechanism names starting with "GSS-" are reserved for SASL
189 mechanisms which conform to this document.
191 The specification of all SASL mechanisms conforming to this document
192 is in the "Specification common to all GSSAPI mechanisms" section of
195 The IESG is considered to be the owner of all SASL mechanisms which
196 conform to this document. This does NOT necessarily imply that the
197 IESG is considered to be the owner of the underlying GSSAPI
202 The OID for the SPKM-1 mechanism [SPKM1] is 1.3.6.1.5.5.1. The ASN.1
203 DER encoding of this OID is 06 06 2b 06 01 05 05 01. The MD5 hash of
204 the ASN.1 DER encoding is 57 ee 81 82 4e ac 4d b0 e6 50 9f 60 1f 46
205 8a 30. The Base32 encoding of the first ten bytes of this is
206 "K7XIDASOVRG3BZSQ". Thus the SASL mechanism name for the SPKM-1
207 GSSAPI mechanism is "GSS-K7XIDASOVRG3BZSQ".
223 Melnikov Expires May 22, 2004 [Page 4]
225 Internet-Draft SASL GSSAPI mechanisms November 2003
230 Use of the Simple and Protected GSS-API Negotiation Mechanism
231 [SPNEGO] underneath SASL introduces subtle interoperability problems
232 and security considerations. To address these, this section places
233 additional requirements on implementations which support SPNEGO
236 A client which supports, for example, the Kerberos V5 GSSAPI
237 mechanism only underneath SPNEGO underneath the "GSS-SPNEGO" SASL
238 mechanism will not interoperate with a server which supports the
239 Kerberos V5 GSSAPI mechanism only underneath the "GSSAPI" SASL
242 Since SASL is capable of negotiating amongst GSSAPI mechanisms, the
243 only reason for a server or client to support the "GSS-SPNEGO"
244 mechanism is to allow a policy of only using mechanisms below a
245 certain strength if those mechanism's negotiation is protected. In
246 such a case, a client or server would only want to negotiate those
247 weaker mechanisms through SPNEGO. In any case, there is no down-
248 negotiation security consideration with using the strongest mechanism
249 and set of options the implementation supports, so for
250 interoperability that mechanism and set of options MUST be negotiable
251 without using the "GSS-SPNEGO" mechanism.
253 If a client's policy is to first prefer GSSAPI mechanism X, then non-
254 GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
255 mechanisms Y and Z but not X, then if the client attempts to
256 negotiate mechanism X by using the "GSS-SPNEGO" SASL mechanism, it
257 may end up using mechanism Z when it should have used mechanism Y.
258 For this reason, implementations MUST exclude from SPNEGO those
259 GSSAPI mechanisms which are weaker than the strongest non-GSSAPI SASL
260 mechanism advertised by the server.
279 Melnikov Expires May 22, 2004 [Page 5]
281 Internet-Draft SASL GSSAPI mechanisms November 2003
284 4. Specification common to all GSSAPI mechanisms
286 Each SASL mechanism which uses a GSSAPI mechanism uses the following
289 The implementation MAY set any GSSAPI flags or arguments not
290 mentioned in this specification as is necessary for the
291 implementation to enforce its security policy.
293 4.1 Client side of authentication protocol exchange
295 The client calls GSS_Init_sec_context, passing in
296 input_context_handle of 0 (initially), mech_type of the GSSAPI
297 mechanism for which this SASL mechanism is registered, chan_binding
298 of NULL, and targ_name equal to output_name from GSS_Import_Name
299 called with input_name_type of GSS_C_NT_HOSTBASED_SERVICE and
300 input_name_string of "service@hostname" where "service" is the
301 service name specified in the protocol's profile, and "hostname" is
302 the fully qualified host name of the server. If the client will be
303 requesting a security layer, it MUST also supply to the
304 GSS_Init_sec_context a mutual_req_flag of TRUE, a sequence_req_flag
305 of TRUE, and an integ_req_flag of TRUE. If the client will be
306 requesting a security layer providing confidentiality protection, it
307 MUST also supply to the GSS_Init_sec_context a conf_req_flag of TRUE.
308 The client then responds with the resulting output_token. If
309 GSS_Init_sec_context returns GSS_S_CONTINUE_NEEDED, then the client
310 should expect the server to issue a token in a subsequent challenge.
311 The client must pass the token to another call to
312 GSS_Init_sec_context, repeating the actions in this paragraph.
314 When GSS_Init_sec_context returns GSS_S_COMPLETE, the client examines
315 the context to ensure that it provides a level of protection
316 permitted by the client's security policy. If the context is
317 acceptable, the client takes the following actions: If the last call
318 to GSS_Init_sec_context returned an output_token, then the client
319 responds with the output_token, otherwise the client responds with no
320 data. The client should then expect the server to issue a token in a
321 subsequent challenge. The client passes this token to GSS_Unwrap and
322 interprets the first octet of resulting cleartext as a bit-mask
323 specifying the security layers supported by the server and the second
324 through fourth octets as the network byte order maximum size
325 output_message to send to the server (if the resulting cleartext is
326 not 4 octets long, the client fails the negotiation). The client
327 then constructs data, with the first octet containing the bit-mask
328 specifying the selected security layer, the second through fourth
329 octets containing in network byte order the maximum size
330 output_message the client is able to receive, and the remaining
331 octets containing the authorization identity, encoded according to
335 Melnikov Expires May 22, 2004 [Page 6]
337 Internet-Draft SASL GSSAPI mechanisms November 2003
340 the application profile specification. The authorization identity is
341 not NUL-terminated. The client passes the data to GSS_Wrap with
342 conf_flag set to FALSE, and responds with the generated
343 output_message. The client can then consider the server
346 4.2 Server side of authentication protocol exchange
348 The server passes the initial client response to
349 GSS_Accept_sec_context as input_token, setting input_context_handle
350 to 0 (initially), mech_type of the GSSAPI mechanism for which this
351 SASL mechanism is registered, chan_binding of NULL, and
352 acceptor_cred_handle equal to output_cred_handle from
353 GSS_Acquire_cred called with desired_name equal to output_name from
354 GSS_Import_name with input_name_type of GSS_C_NT_HOSTBASED_SERVICE
355 and input_name_string of "service@hostname" where "service" is the
356 service name specified in the protocol's profile, and "hostname" is
357 the fully qualified host name of the server. If
358 GSS_Accept_sec_context returns GSS_S_CONTINUE_NEEDED, the server
359 returns the generated output_token to the client in challenge and
360 passes the resulting response to another call to
361 GSS_Accept_sec_context, repeating the actions in this paragraph.
363 When GSS_Accept_sec_context returns GSS_S_COMPLETE, the server
364 examines the context to ensure that it provides a level of protection
365 permitted by the server's security policy. If the context is
366 acceptable, the server takes the following actions: If the last call
367 to GSS_Accept_sec_context returned an output_token, the server
368 returns it to the client in a challenge and expects a reply from the
369 client with no data. Whether or not an output_token was returned
370 (and after receipt of any response from the client to such an
371 output_token), the server then constructs 4 octets of data, with the
372 first octet containing a bit-mask specifying the security layers
373 supported by the server and the second through fourth octets
374 containing in network byte order the maximum size output_token the
375 server is able to receive. The server must then pass the plaintext
376 to GSS_Wrap with conf_flag set to FALSE and issue the generated
377 output_message to the client in a challenge. The server must then
378 pass the resulting response to GSS_Unwrap and interpret the first
379 octet of resulting cleartext as the bit-mask for the selected
380 security layer, the second through fourth octets as the network byte
381 order maximum size output_message to send to the client, and the
382 remaining octets as the authorization identity. The server must
383 verify that the src_name is authorized to authenticate as the
384 authorization identity. After these verifications, the
385 authentication process is complete.
391 Melnikov Expires May 22, 2004 [Page 7]
393 Internet-Draft SASL GSSAPI mechanisms November 2003
398 The security layers and their corresponding bit-masks are as follows:
401 2 Integrity protection.
402 Sender calls GSS_Wrap with conf_flag set to FALSE
403 4 Confidentiality protection.
404 Sender calls GSS_Wrap with conf_flag set to TRUE
406 Other bit-masks may be defined in the future; bits which are not
407 understood must be negotiated off.
409 Note that SASL negotiates the maximum size of the output_message to
410 send. Implementations can use the GSS_Wrap_size_limit call to
411 determine the corresponding maximum size input_message.
447 Melnikov Expires May 22, 2004 [Page 8]
449 Internet-Draft SASL GSSAPI mechanisms November 2003
452 5. IANA Considerations
454 The IANA is advised that SASL mechanism names starting with "GSS-"
455 are reserved for SASL mechanisms which conform to this document. The
456 IANA is directed to place a statement to that effect in the sasl-
459 Family of SASL mechanisms: YES
463 Security considerations: RFC [THIS-DOC]
465 Published Specification: RFC [THIS-DOC]
467 Person & email address to contact for further information: Alexey
468 Melnikov <Alexey.Melnikov@isode.com>
470 Intended usage: COMMON
472 Author/Change controller: iesg@ietf.org
474 The IANA is directed to modify the existing registration for "GSSAPI"
477 Family of SASL mechanisms: NO
479 SASL mechanism name: GSSAPI
481 Security considerations: ?
483 Published Specification: RFC [THIS-DOC]
485 Person & email address to contact for further information: Alexey
486 Melnikov <Alexey.Melnikov@isode.com>
488 Intended usage: COMMON
490 Author/Change controller: iesg@ietf.org
492 Additional Information: This mechanism is for the Kerberos V5
493 mechanism of GSSAPI. Other GSSAPI mechanisms use other SASL
494 mechanism names, as described in this mechanism's published
497 The IANA is directed to modify the existing registration for "GSS-
503 Melnikov Expires May 22, 2004 [Page 9]
505 Internet-Draft SASL GSSAPI mechanisms November 2003
508 Family of SASL mechanisms: NO
510 SASL mechanism name: GSS-SPNEGO
512 Security considerations: See the "SPNEGO" section of RFC [THIS-DOC].
514 Published Specification: RFC [THIS-DOC]
516 Person & email address to contact for further information: Alexey
517 Melnikov <Alexey.Melnikov@isode.com>
519 Intended usage: LIMITED USE
521 Author/Change controller: iesg@ietf.org
559 Melnikov Expires May 22, 2004 [Page 10]
561 Internet-Draft SASL GSSAPI mechanisms November 2003
564 6. Security Considerations
566 Security issues are discussed throughout this memo.
568 When a server or client supports multiple authentication mechanisms,
569 each of which has a different security strength, it is possible for
570 an active attacker to cause a party to use the least secure mechanism
571 supported. To protect against this sort of attack, a client or
572 server which supports mechanisms of different strengths should have a
573 configurable minimum strength that it will use. It is not sufficient
574 for this minimum strength check to only be on the server, since an
575 active attacker can change which mechanisms the client sees as being
576 supported, causing the client to send authentication credentials for
577 its weakest supported mechanism.
579 The client's selection of a SASL mechanism is done in the clear and
580 may be modified by an active attacker. It is important for any new
581 SASL mechanisms to be designed such that an active attacker cannot
582 obtain an authentication with weaker security properties by modifying
583 the SASL mechanism name and/or the challenges and responses.
585 [SPNEGO] has protection against many of these down-negotiation
586 attacks, SASL does not itself have such protection. The section
587 titled "SPNEGO" mentions considerations of choosing negotiation
588 through SASL versus SPNEGO.
590 The integrity protection provided by the security layer is useless to
591 the client unless the client also requests mutual authentication.
592 Therefore, a client wishing to benefit from the integrity protection
593 of a security layer MUST pass to the GSS_Init_sec_context call a
594 mutual_req_flag of TRUE.
596 When constructing the input_name_string, the client should not
597 canonicalize the server's fully qualified domain name using an
598 insecure or untrusted directory service.
600 Additional security considerations are in the [SASL] and [GSSAPI]
615 Melnikov Expires May 22, 2004 [Page 11]
617 Internet-Draft SASL GSSAPI mechanisms November 2003
622 This document is a revision of RFC 2222 written by John G. Myers.
623 He also contributed significantly to this revision.
625 Thank you to Lawrence Greenfield for converting text of this draft to
628 Contributions of many members of the SASL mailing list are gratefully
671 Melnikov Expires May 22, 2004 [Page 12]
673 Internet-Draft SASL GSSAPI mechanisms November 2003
678 [ASN1] International Organization for Standardization,
679 "Information Processing Systems - Open Systems
680 Interconnection - Specification of Abstract Syntax
681 Notation One (ASN.1)", ISO Standard 8824, December
684 [BASE-ENCODING] Josefsson, S., "The Base16, Base32, and Base64 Data
685 Encodings", RFC 3548, July 2003.
687 [GSSAPI] Linn, J., "Generic Security Service Application
688 Program Interface Version 2, Update 1", RFC 2743,
691 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
692 Requirement Levels", BCP 14, RFC 2119, March 1997.
694 [KRB5GSS] Linn, J., "The Kerberos Version 5 GSS-API
695 Mechanism", RFC 1964, June 1996.
697 [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC
700 [SASL] Myers, J., "Simple Authentication and Security Layer
701 (SASL)", RFC 2222, October 1997.
703 [SASL(rev)] Melnikov, A., "Simple Authentication and Security
704 Layer (SASL)", draft-ietf-sasl-rfc2222bis (work in
705 progress), October 2003.
707 [SPNEGO] Baize, E. and D. Pinkas, "The Simple and Protected
708 GSS-API Negotiation Mechanism", RFC 2478, December
727 Melnikov Expires May 22, 2004 [Page 13]
729 Internet-Draft SASL GSSAPI mechanisms November 2003
732 Informative References
734 [SPKM1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
735 RFC 2025, October 1996.
737 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
738 RFC 2279, January 1998.
743 Alexey Melnikov (Ed.)
745 5 Castle Business Village
747 Hampton, Middlesex TW12 2BX
750 EMail: Alexey.Melnikov@isode.com
751 URI: http://www.melnikov.ca/
783 Melnikov Expires May 22, 2004 [Page 14]
785 Internet-Draft SASL GSSAPI mechanisms November 2003
788 Full Copyright Statement
790 Copyright (C) The Internet Society (2003). All Rights Reserved.
792 This document and translations of it may be copied and furnished to
793 others, and derivative works that comment on or otherwise explain it
794 or assist in its implementation may be prepared, copied, published
795 and distributed, in whole or in part, without restriction of any
796 kind, provided that the above copyright notice and this paragraph are
797 included on all such copies and derivative works. However, this
798 document itself may not be modified in any way, such as by removing
799 the copyright notice or references to the Internet Society or other
800 Internet organizations, except as needed for the purpose of
801 developing Internet standards in which case the procedures for
802 copyrights defined in the Internet Standards process must be
803 followed, or as required to translate it into languages other than
806 The limited permissions granted above are perpetual and will not be
807 revoked by the Internet Society or its successors or assigns.
809 This document and the information contained herein is provided on an
810 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
811 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
812 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
813 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
814 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
818 Funding for the RFC Editor function is currently provided by the
839 Melnikov Expires May 22, 2004 [Page 15]