1
2
3
4Network Working Group                                       S. Josefsson
5Internet-Draft                                                    SJD AB
6Intended status: Standards Track                             N. Williams
7Expires: September 24, 2009                             Sun Microsystems
8                                                          March 23, 2009
9
10
11       Using GSS-API Mechanisms in SASL: The GS2 Mechanism Family
12                         draft-ietf-sasl-gs2-11
13
14Status of this Memo
15
16   This Internet-Draft is submitted to IETF in full conformance with the
17   provisions of BCP 78 and BCP 79.  This document may contain material
18   from IETF Documents or IETF Contributions published or made publicly
19   available before November 10, 2008.  The person(s) controlling the
20   copyright in some of this material may not have granted the IETF
21   Trust the right to allow modifications of such material outside the
22   IETF Standards Process.  Without obtaining an adequate license from
23   the person(s) controlling the copyright in such materials, this
24   document may not be modified outside the IETF Standards Process, and
25   derivative works of it may not be created outside the IETF Standards
26   Process, except to format it for publication as an RFC or to
27   translate it into languages other than English.
28
29   Internet-Drafts are working documents of the Internet Engineering
30   Task Force (IETF), its areas, and its working groups.  Note that
31   other groups may also distribute working documents as Internet-
32   Drafts.
33
34   Internet-Drafts are draft documents valid for a maximum of six months
35   and may be updated, replaced, or obsoleted by other documents at any
36   time.  It is inappropriate to use Internet-Drafts as reference
37   material or to cite them other than as "work in progress."
38
39   The list of current Internet-Drafts can be accessed at
40   http://www.ietf.org/ietf/1id-abstracts.txt.
41
42   The list of Internet-Draft Shadow Directories can be accessed at
43   http://www.ietf.org/shadow.html.
44
45   This Internet-Draft will expire on September 24, 2009.
46
47Copyright Notice
48
49   Copyright (c) 2009 IETF Trust and the persons identified as the
50   document authors.  All rights reserved.
51
52
53
54
55Josefsson & Williams   Expires September 24, 2009               [Page 1]
56
57Internet-Draft                 SASL GS2-*                     March 2009
58
59
60   This document is subject to BCP 78 and the IETF Trust's Legal
61   Provisions Relating to IETF Documents in effect on the date of
62   publication of this document (http://trustee.ietf.org/license-info).
63   Please review these documents carefully, as they describe your rights
64   and restrictions with respect to this document.
65
66Abstract
67
68   This document describes how to use a Generic Security Service
69   Application Program Interface (GSS-API) mechanism in the the Simple
70   Authentication and Security Layer (SASL) framework.  This is done by
71   defining a new SASL mechanism family, called GS2.  This mechanism
72   family offers a number of improvements over the previous "SASL/
73   GSSAPI" mechanism: it is more general, uses fewer messages for the
74   authentication phase in some cases, and supports negotiable use of
75   channel binding.  Only GSS-API mechanisms that support channel
76   binding are supported.
77
78   See <http://josefsson.org/sasl-gs2-*/> for more information.
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111Josefsson & Williams   Expires September 24, 2009               [Page 2]
112
113Internet-Draft                 SASL GS2-*                     March 2009
114
115
116Table of Contents
117
118   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
119   2.  Conventions used in this document  . . . . . . . . . . . . . .  5
120   3.  Mechanism name . . . . . . . . . . . . . . . . . . . . . . . .  5
121     3.1.  Generating SASL mechanism names from GSS-API OIDs  . . . .  5
122     3.2.  Computing mechanism names manually . . . . . . . . . . . .  5
123     3.3.  Examples . . . . . . . . . . . . . . . . . . . . . . . . .  6
124   4.  SASL Authentication Exchange Message Format  . . . . . . . . .  7
125     4.1.  SASL Messages  . . . . . . . . . . . . . . . . . . . . . .  7
126   5.  Channel Bindings . . . . . . . . . . . . . . . . . . . . . . .  9
127   6.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
128   7.  Authentication Conditions  . . . . . . . . . . . . . . . . . . 11
129   8.  GSS-API Parameters . . . . . . . . . . . . . . . . . . . . . . 11
130   9.  Naming . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
131   10. GSS_Mechanism_SASLname call  . . . . . . . . . . . . . . . . . 11
132     10.1. gss_mechanism_saslname . . . . . . . . . . . . . . . . . . 13
133   11. GSS_Inquire_mech_for_SASLname call . . . . . . . . . . . . . . 13
134     11.1. gss_inquire_mech_for_saslname  . . . . . . . . . . . . . . 15
135   12. Security Layers  . . . . . . . . . . . . . . . . . . . . . . . 15
136   13. Interoperability with the SASL "GSSAPI" mechanism  . . . . . . 16
137     13.1. The interoperability problem . . . . . . . . . . . . . . . 16
138     13.2. Resolving the problem  . . . . . . . . . . . . . . . . . . 16
139     13.3. Additional Recommendations . . . . . . . . . . . . . . . . 16
140   14. Mechanisms that negotiate other mechanisms . . . . . . . . . . 17
141     14.1. The interoperability problem . . . . . . . . . . . . . . . 17
142     14.2. Security problem . . . . . . . . . . . . . . . . . . . . . 17
143     14.3. Resolving the problems . . . . . . . . . . . . . . . . . . 17
144   15. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
145   16. Security Considerations  . . . . . . . . . . . . . . . . . . . 18
146   17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
147   18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
148     18.1. Normative References . . . . . . . . . . . . . . . . . . . 19
149     18.2. Informative References . . . . . . . . . . . . . . . . . . 20
150   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167Josefsson & Williams   Expires September 24, 2009               [Page 3]
168
169Internet-Draft                 SASL GS2-*                     March 2009
170
171
1721.  Introduction
173
174   Generic Security Service Application Program Interface (GSS-API)
175   [RFC2743] is a framework that provides security services to
176   applications using a variety of authentication "mechanisms".  Simple
177   Authentication and Security Layer (SASL) [RFC4422] is a framework to
178   provide authentication and "security layers" for connection based
179   protocols, also using a variety of mechanisms.  This document
180   describes how to use a GSS-API mechanism as though it were a SASL
181   mechanism.  This facility is called "GS2" -- a moniker that indicates
182   that this is the second GSS-API->SASL mechanism bridge.  The original
183   GSS-API->SASL mechanism bridge was specified by [RFC2222], now
184   [RFC4752]; we shall sometimes refer to the original bridge as "GS1"
185   in this document.
186
187   All GSS-API mechanisms are implicitly registered for use within SASL
188   by this specification.  The SASL mechanisms defined in this document
189   are known as the "GS2 family of mechanisms".
190
191   The GS1 bridge failed to gain wide deployment for any GSS-API
192   mechanism other than The "Kerberos V GSS-API mechanism" [RFC1964]
193   [RFC4121], and has a number of problems that lead us to desire a new
194   bridge.  Specifically: a) GS1 was not round-trip optimized, b) GS1
195   did not support channel binding [RFC5056].  These problems and the
196   opportunity to create the next SASL password-based mechanism, SCRAM
197   [I-D.newman-auth-scram], as a GSS-API mechanism used by SASL
198   applications via GS2, provide the motivation for GS2.
199
200   In particular, the current consensus of the SASL community appears to
201   be that SASL "security layers" (i.e., confidentiality and integrity
202   protection of application data after authentication) are too complex
203   and, since SASL applications tend to have an option to run over a
204   Transport Layer Security (TLS) [RFC5246] channel, redundant and best
205   replaced with channel binding.
206
207   GS2 is designed to be as simple as possible.  It adds to GSS-API
208   security context token exchanges only the bare minimum to support
209   SASL semantics and negotiation of use of channel binding.
210   Specifically, GS2 adds a small header (2 bytes or 4 bytes plus the
211   length of the client requested SASL authorization ID (authzid)) to
212   the initial context token and to the application channel binding
213   data, and it uses SASL mechanism negotiation to implement channel
214   binding negotiation.  All GS2 plaintext is protected via the use of
215   GSS-API channel binding.  Additionally, to simplify the
216   implementation of GS2 mechanisms for implementors who will not
217   implement a GSS-API framework, we compress the initial security
218   context token header required by [RFC2743] (see section 3.1).
219
220
221
222
223Josefsson & Williams   Expires September 24, 2009               [Page 4]
224
225Internet-Draft                 SASL GS2-*                     March 2009
226
227
2282.  Conventions used in this document
229
230   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
231   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
232   document are to be interpreted as described in [RFC2119].
233
234
2353.  Mechanism name
236
2373.1.  Generating SASL mechanism names from GSS-API OIDs
238
239   There are two SASL mechanism names for any GSS-API mechanism used
240   through this facility.  One denotes that the server supports channel
241   binding.  The other denotes that it does not.
242
243   The SASL mechanism name for a GSS-API mechanism is that which is
244   provided by that mechanism when it was specified, if one was
245   specified.  This name denotes that the server does not support
246   channel binding.  Add the suffix "-PLUS" and the resulting name
247   denotes that the server does support channel binding.  SASL
248   implementations can use the GSS_Mechanism_Name call (see below) to
249   query for the SASL mechanism name of a GSS-API mechanism.
250
251   For GSS-API mechanisms whose SASL names are not defined together with
252   the GSS-API mechanism or in this document, the SASL mechanism name is
253   concatenation of the string "GS2-" and the Base32 encoding [RFC4648]
254   (with an upper case alphabet) of the first 55 bits of the binary
255   SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER
256   encoding [CCITT.X690.2002], including the tag and length octets, of
257   the GSS-API mechanism's Object Identifier.  The Base32 rules on
258   padding characters and characters outside of the base32 alphabet are
259   not relevant to this use of Base32.  If any padding or non-alphabet
260   characters are encountered, the name is not a GS2 family mechanism
261   name.  This name denotes that the server does not support channel
262   binding.  Add the suffix "-PLUS" and the resulting name denotes that
263   the server does support channel binding.
264
2653.2.  Computing mechanism names manually
266
267   The hash-derived GS2 SASL mechanism name may be computed manually.
268   This is useful when the set of supported GSS-API mechanisms is known
269   in advance.  It also obliterate the need to implement Base32, SHA-1
270   and DER in the SASL mechanism.  The computed mechanism name can be
271   used directly in the implementation, and the implementation need not
272   concern itself with that the mechanism is part of a mechanism family.
273
274
275
276
277
278
279Josefsson & Williams   Expires September 24, 2009               [Page 5]
280
281Internet-Draft                 SASL GS2-*                     March 2009
282
283
2843.3.  Examples
285
286   The OID for the SPKM-1 mechanism [RFC2025] is 1.3.6.1.5.5.1.1.  The
287   ASN.1 DER encoding of the OID, including the tag and length, is (in
288   hex) 06 07 2b 06 01 05 05 01 01.  The SHA-1 hash of the ASN.1 DER
289   encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56
290   27 86 61 ad.  Convert the first 7 octets to binary, drop the last
291   bit, and re-group them in groups of 5, and convert them back to
292   decimal, which results in these computations:
293
294   hex:
295   1c f8 f4 2b 5a 9f 80
296
297   binary:
298   00011100 11111000 11110100 00101011 01011010
299   10011111 1000000
300
301   binary in groups of 5:
302   00011 10011 11100 01111 01000 01010 11010 11010
303   10011 11110 00000
304
305   decimal of each group:
306   3 19 28 15 8 10 26 26 19 30 0
307
308   base32 encoding:
309   D T 4 P I K 2 2 T 6 A
310
311   The last step translate each decimal value using table 3 in Base32
312   [RFC4648].  Thus the SASL mechanism name for the SPKM-1 GSSAPI
313   mechanism is "GS2-DT4PIK22T6A".
314
315   The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is
316   1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48
317   86 F7 12 01 02 02.  The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa
318   93 25 51 6a fc ff 04 b0 43 60.  Convert the first ten octets to
319   binary, and re-group them in groups of 5, and convert them back to
320   decimal, which results in these computations:
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335Josefsson & Williams   Expires September 24, 2009               [Page 6]
336
337Internet-Draft                 SASL GS2-*                     March 2009
338
339
340   hex:
341   82 d2 73 25 76 6b d6
342
343   binary:
344   10000010 11010010 01110011 00100101 01110110
345   01101011 1101011
346
347   binary in groups of 5:
348   10000 01011 01001 00111 00110 01001 01011 10110
349   01101 01111 01011
350
351   decimal of each group:
352   16 11 9 7 6 9 11 22 13 15 11
353
354   base32 encoding:
355   Q L J H G J L W N P L
356
357   The last step translate each decimal value using table 3 in Base32
358   [RFC4648].  Thus the SASL mechanism name for the Kerberos V5 GSSAPI
359   mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism
360   supports channel binding) "GS2-QLJHGJLWNPL-PLUS".  But instead, we
361   assign the Kerberos V mechanism a non-hash-derived mechanism name:
362   "KerberosV-GS2" and "KerberosV-GS2-PLUS" (see Section 15).
363
364
3654.  SASL Authentication Exchange Message Format
366
3674.1.  SASL Messages
368
369   During the SASL authentication exchange for GS2, a number of messages
370   following the following format is sent between the client and server.
371   This number is the same as the number of context tokens that the GSS-
372   API mechanism would normally require in order to establish a security
373   context (or to fail to do so).
374
375   Note that when using a GS2 mechanism the SASL client is always a GSS-
376   API initiator and the SASL server is always a GSS-API acceptor.  Thus
377   the SASL client calls GSS_Init_sec_context() and the server calls
378   GSS_Accept_sec_context().
379
380   All the SASL authentication messages exchanged are exactly the same
381   as the security context tokens of the GSS-API mechanism, except for
382   the initial security context token.
383
384   Also, the server SHOULD refrain from sending GSS-API error tokens
385   (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context()
386   along with a major status code other than GSS_S_COMPLETE or
387   GSS_S_CONTINUE_NEEDED) as SASL applications handle error conditions.
388
389
390
391Josefsson & Williams   Expires September 24, 2009               [Page 7]
392
393Internet-Draft                 SASL GS2-*                     March 2009
394
395
396   The initial security context token is modified as follows:
397   o  The [RFC2743] section 3.1 initial context token header MUST be
398      removed if present, and its presence is noted (see below).  On the
399      server side this header MUST be recomputed and restored prior to
400      passing the token to GSS_Accept_sec_context().
401   o  A GS2 header MUST be prefixed to the resulting initial context
402      token.  This header has the form given below in ABNF [RFC5234].
403
404      UTF8-1-safe    = %x01-2B / %x2D-3C / %x3E-7F
405                       ;; As UTF8-1 in RFC 3629 except
406                       ;; NUL, "=", and ",".
407      UTF8-2         = <as defined in RFC 3629 (STD 63)>
408      UTF8-3         = <as defined in RFC 3629 (STD 63)>
409      UTF8-4         = <as defined in RFC 3629 (STD 63)>
410      UTF8-char-safe = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
411
412      saslname     = 1*(UTF8-char-safe / "=2C" / "=3D")
413      gs2-authzid  = "a=" saslname
414                        ;; GS2 has to transport an authzid since
415                        ;; the GSS-API has no equivalent
416      gs2-std-mech = "F"
417                        ;; "F" means the mechanism is NOT is a
418                        ;; standard GSS-API mechanism in that the
419                        ;; RFC2743 section 3.1 header was missing
420      gs2-cb-flag  = "n" / "y" / "p"
421                        ;; GS2 channel binding (CB) flag
422                        ;; "n" -> client does not support CB
423                        ;; "y" -> client supports CB, thinks the server
424                        ;;           does not
425                        ;; "p" -> client supports and used CB
426      gs2-header   = [gs2-std-mech] gs2-cb-flag [gs2-authzid] ","
427                        ;; The GS2 header is gs2-header.
428                        ;; gs2-std-mech is present if the GSS-API
429                        ;; mechanism's initial context token did not
430                        ;; have the standard header defined in
431                        ;; [RFC2743] section 3.1.
432
433   The GS2 header is also prepended to the application's channel binding
434   data.  If the application did not provide channel binding data then
435   the GS2 header is used as though it were application-provided channel
436   binding data.
437
438   The "gs2-authzid" holds the SASL authorization identity.  It is
439   encoded using UTF-8 [RFC3629] with three exceptions:
440   o  The NUL characters is forbidden as required by section 3.4.1 of
441      [RFC4422].
442
443
444
445
446
447Josefsson & Williams   Expires September 24, 2009               [Page 8]
448
449Internet-Draft                 SASL GS2-*                     March 2009
450
451
452   o  The server MUST replace any occurance of "," (comma) in the string
453      with "=2C".
454   o  The server MUST replace any occurance of "=" (comma) in the string
455      with "=3D".
456
457   If a server sends a string that does not conform to this syntax, the
458   client MUST reject authentication.
459
460
4615.  Channel Bindings
462
463   If the server supports channel binding then it must list both forms
464   of the SASL mechanism name for each GSS-API mechanism supported via
465   GS2 (i.e., GSS-API mechanisms that support channel binding).
466
467   If the client supports channel binding and the server does not (i.e.,
468   the server did not advertise the -PLUS names) then the client MUST
469   either fail authentication or it MUST set the channel binding flag in
470   the GS2 initial security context token to "y" and MUST NOT include
471   application channel binding data in the GSS-API channel binding input
472   to GSS_Init_sec_context().
473
474   If the client supports channel binding and the server also does then
475   the client MUST set the channel binding flag in the GS2 initial
476   security context token to "p" and MUST include application channel
477   binding data in the GSS-API channel binding input to
478   GSS_Init_sec_context().
479
480   If the client does not support channel binding then it MUST set the
481   channel binding flag in the GS2 initial security context token to "n"
482   and MUST NOT include application channel binding data in the GSS-API
483   channel binding input to GSS_Init_sec_context().
484
485   Upon receipt of the initial authentication message the server checks
486   the channel binding flag in the GS2 header and constructs a channel
487   binding data input for GSS_Accept_sec_context() accordingly.  If the
488   client channel binding flag was "n" then the server MUST NOT include
489   application channel binding data in the GSS-API channel binding input
490   to GSS_Accept_sec_context().  If the client channel binding flag was
491   "y" and the server does support channel binding then the server MUST
492   fail authentication.  If the client channel binding flag was "p" the
493   server MUST include application channel binding data in the GSS-API
494   channel binding input to GSS_Accept_sec_context().
495
496   For more discussions of channel bindings, and the syntax of the
497   channel binding data for various security protocols, see [RFC5056].
498
499
500
501
502
503Josefsson & Williams   Expires September 24, 2009               [Page 9]
504
505Internet-Draft                 SASL GS2-*                     March 2009
506
507
5086.  Examples
509
510   Example #1: a one round-trip GSS-API context token exchange, no
511   channel binding, optional authzid given.
512
513         C: Request authentication exchange
514         S: Empty Challenge
515         C: nauthzid=someuser, <initial context token with standard
516                                header removed>
517         S: Send reply context token as is
518         C: Empty message
519         S: Outcome of authentication exchange
520
521   Example #2: a one and one half round-trip GSS-API context token
522   exchange.
523
524         C: Request authentication exchange
525         S: Empty Challenge
526         C: nauthzid=someuser, <initial context token with standard
527                                header removed>
528         S: Send reply context token as is
529         C: Send reply context token as is
530         S: Outcome of authentication exchange
531
532   Example #3: a two round-trip GSS-API context token exchange.
533
534         C: Request authentication exchange
535         S: Empty Challenge
536         C: nauthzid=someuser, <initial context token with standard
537                                header removed>
538         S: Send reply context token as is
539         C: Send reply context token as is
540         S: Send reply context token as is
541         C: Empty message
542         S: Outcome of authentication exchange
543
544   Example #4: using channel binding.
545
546         C: Request authentication exchange
547         S: Empty Challenge
548         C: yauthzid=someuser, <initial context token with standard
549                                header removed>
550         S: Send reply context token as is
551         ...
552
553   GSS-API authentication is always initiated by the client.  The SASL
554   framework allows either the client and server to initiate
555   authentication.  In GS2 the server will send an initial empty
556
557
558
559Josefsson & Williams   Expires September 24, 2009              [Page 10]
560
561Internet-Draft                 SASL GS2-*                     March 2009
562
563
564   challenge (zero byte string) if it has not yet received a token from
565   the client.  See section 3 of [RFC4422].
566
567
5687.  Authentication Conditions
569
570   Authentication MUST NOT succeed if any one of the following
571   conditions are true:
572
573   o  GSS_Init/Accept_sec_context() return anything other than
574      GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.
575   o  If the client's GS2 channel binding flag was "y" and the server
576      supports channel binding.
577   o  If the client requires use of channel binding and the server did
578      not advertise support for channel binding.
579   o  Authorization of client principal (i.e., src_name in
580      GSS_Accept_sec_context()) to requested authzid failed.
581   o  If the client is not authorized to the requested authzid or an
582      authzid could not be derived from the client's initiator principal
583      name.
584
585
5868.  GSS-API Parameters
587
588   GS2 does not use any GSS-API per-message tokens.  Therefore the
589   setting of req_flags related to per-message tokens is irrelevant.
590
591
5929.  Naming
593
594   There's no requirement that any particular GSS-API name-types be
595   used.  However, typically SASL servers will have host-based acceptor
596   principal names (see [RFC2743] section 4.1) and clients will
597   typically have username initiator principal names (see [RFC2743]
598   section 4.2).
599
600
60110.  GSS_Mechanism_SASLname call
602
603   To allow SASL implementations to query for the SASL mechanism name of
604   a GSS-API mechanism, we specify a new GSS-API function for this
605   purpose.
606
607
608
609
610
611
612
613
614
615Josefsson & Williams   Expires September 24, 2009              [Page 11]
616
617Internet-Draft                 SASL GS2-*                     March 2009
618
619
620      Inputs:
621
622      o desired_mech OBJECT IDENTIFIER
623
624      Outputs:
625
626      o sasl_mech_name OCTET STRING -- SASL name for this mechanism
627        (really, ASCII)
628
629      o mech_name UTF-8 STRING -- name of this mechanism, possibly
630        localized
631
632      o mech_description UTF-8 STRING -- possibly localized
633        description of this mechanism.
634
635      Return major_status codes:
636
637      o  GSS_S_COMPLETE indicates successful completion, and that output
638         parameters holds correct information.
639
640      o  GSS_S_BAD_MECH indicates that a disred_mech was unsupported by
641         the GSS-API implementation.
642
643      The GSS_Mechanism_SASLname call is used to get the SASL mechanism
644      name for a GSS-API mechanism.  It also returns a name and
645      description of the mechanism in a human readable form.
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671Josefsson & Williams   Expires September 24, 2009              [Page 12]
672
673Internet-Draft                 SASL GS2-*                     March 2009
674
675
67610.1.  gss_mechanism_saslname
677
678   The C binding for the GSS_Mechanism_SASLname call is as follows.
679
680     OM_uint32 gss_mechanism_saslname(
681       OM_uint32     *minor_status,
682       const gss_OID  desired_mech,
683       gss_buffer_t   sasl_mech_name,
684       gss_buffer_t   mech_name,
685       gss_buffer_t   mech_description,
686     );
687
688     Purpose:
689
690     Output the SASL mechanism name of a GSS-API mechanism.  Also output
691     a name and description of the mechanism in a human readable form.
692
693     Parameters:
694
695     minor_status      Integer, modify
696                       Mechanism specific status code.
697
698     Function value:   GSS status code
699
700     GSS_S_COMPLETE    Successful completion
701
702     GSS_S_BAD_MECH    The desired_mech OID is unsupported
703
704
70511.  GSS_Inquire_mech_for_SASLname call
706
707   To allow SASL clients to more efficiently identify which GSS-API
708   mechanism a particular SASL mechanism name refers to we specify a new
709   GSS-API utility function for this purpose.
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727Josefsson & Williams   Expires September 24, 2009              [Page 13]
728
729Internet-Draft                 SASL GS2-*                     March 2009
730
731
732      Inputs:
733
734      o sasl_mech_name OCTET STRING -- SASL name of mechanism
735        (really, ASCII)
736
737      Outputs:
738
739      o  mech_type OBJECT IDENTIFIER -- must be explicit mechanism,
740         and not "default" specifier
741
742      Return major_status codes:
743
744      o  GSS_S_COMPLETE indicates successful completion, and that output
745         parameters holds correct information.
746
747      o  GSS_S_BAD_MECH indicates that no supported GSS-API mechanism
748         had the indicated sasl_mech_name.
749
750      The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API
751      mechanism OID associated with a SASL mechanism name.
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783Josefsson & Williams   Expires September 24, 2009              [Page 14]
784
785Internet-Draft                 SASL GS2-*                     March 2009
786
787
78811.1.  gss_inquire_mech_for_saslname
789
790   The C binding for the GSS_Inquire_mech_for_SASLname call is as
791   follows.
792
793      OM_uint32 gss_inquire_mech_for_saslname(
794        OM_uint32           *minor_status,
795        const gss_buffer_t   sasl_mech_name,
796        gss_OID             *mech_type
797      );
798
799      Purpose:
800
801      Output GSS-API mechanism OID of mechanism associated with given
802      sasl_mech_name.
803
804      Parameters:
805
806      minor_status      Integer, modify
807                        Mechanism specific status code.
808
809      Function value:   GSS status code
810
811      GSS_S_COMPLETE    Successful completion
812
813      GSS_S_BAD_MECH    The desired_mech OID is unsupported
814
815
81612.  Security Layers
817
818   GS2 does not currently support SASL security layers.  Applications
819   that need integrity protection or confidentiality and integrity
820   protection MUST use either channel binding to a secure external
821   channel or a SASL mechanism that does provide security layers.
822
823   NOTE WELL: the GS2 client's first authentication message MUST always
824   start with "F", "n", "y" or "p", otherwise the server MUST fail
825   authentication.  This will allow us to add support for security
826   layers in the future if it were to become necessary.  Note that
827   adding security layer support to GS2 must not break existing SASL/GS2
828   applications, which can be accomplished by making security layers
829   optional.
830
831   [A sketch of how to add sec layer support...  Add a way for the
832   client to: a) make an offer of sec layers and max buffer, b) make an
833   opportunistic selection of sec layer and buffer size, both in the
834   first client authentication message, and starting with a character
835   other than "F", "n", "y" or "p".  The server could accept the
836
837
838
839Josefsson & Williams   Expires September 24, 2009              [Page 15]
840
841Internet-Draft                 SASL GS2-*                     March 2009
842
843
844   opportunistic proposal (reply token prefixed with a byte indicating
845   acceptance) or reject it along with an indication of the server's
846   acceptable sec layers and max buffer size.  In the latter case the
847   GSS-API security context token exchange must be abandoned and
848   recommenced, although this would be a detail of the GS2 bridge not
849   exposed to the SASL application.  The negotiation would be protected
850   via GSS channel binding, as with the rest of GS2.]
851
852
85313.  Interoperability with the SASL "GSSAPI" mechanism
854
855   The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL
856   under the name "GSSAPI", see GSSAPI mechanism [RFC4752].  The
857   Kerberos V5 mechanism may also be used with the GS2 family.  This
858   causes an interopability problem, which is discussed and resolved
859   below.
860
86113.1.  The interoperability problem
862
863   The SASL "GSSAPI" mechanism is not wire-compatible with the Kerberos
864   V GSS-API mechanism used as a SASL GS2 mechanism.
865
866   If a client (or server) only support Kerberos V5 under the "GSSAPI"
867   name and the server (or client) only support Kerberos V5 under the
868   GS2 family, the mechanism negotiation will fail.
869
87013.2.  Resolving the problem
871
872   If the Kerberos V5 mechanism is supported under GS2 in a server, the
873   server SHOULD also support Kerberos V5 through the "GSSAPI"
874   mechanism, to avoid interoperability problems with older clients.
875
876   Reasons for violating this recommendation may include security
877   considerations regarding the absent features in the GS2 mechanism.
878   The SASL "GSSAPI" mechanism lacks support for channel bindings, which
879   means that using an external secure channel may not be sufficient
880   protection against active attackers (see [RFC5056], [mitm]).
881
88213.3.  Additional Recommendations
883
884   If the application requires security layers then it MUST prefer the
885   SASL "GSSAPI" mechanism over "KerberosV-GS2".
886
887   If the application can use channel binding to an external channel
888   then it is RECOMMENDED that it select Kerberos V5 through the GS2
889   mechanism rather than the "GSSAPI" mechanism.
890
891
892
893
894
895Josefsson & Williams   Expires September 24, 2009              [Page 16]
896
897Internet-Draft                 SASL GS2-*                     March 2009
898
899
90014.  Mechanisms that negotiate other mechanisms
901
902   A GSS-API mechanism that negotiate other mechanisms interact badly
903   with the SASL mechanism negotiation.  There are two problems.  The
904   first is an interoperability problem and the second is a security
905   concern.  The problems are described and resolved below.
906
90714.1.  The interoperability problem
908
909   If a client implement GSS-API mechanism X, potentially negotiated
910   through a GSS-API mechanism Y, and the server also implement GSS-API
911   mechanism X negotiated through a GSS-API mechanism Z, the
912   authentication negotiation will fail.
913
91414.2.  Security problem
915
916   If a client's policy is to first prefer GSSAPI mechanism X, then non-
917   GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports
918   mechanisms Y and Z but not X, then if the client attempts to
919   negotiate mechanism X by using a GSS-API mechanism that negotiate
920   other mechanisms (such as SPNEGO), it may end up using mechanism Z
921   when it ideally should have used mechanism Y. For this reason, the
922   use of GSS-API mechanisms that negotiate other mechanisms are
923   disallowed under GS2.
924
92514.3.  Resolving the problems
926
927   GSS-API mechanisms that negotiate other mechanisms MUST NOT be used
928   with the GS2 SASL mechanism.  Specifically SPNEGO [RFC4178] MUST NOT
929   be used as a GS2 mechanism.  To make this easier for SASL
930   implementations we assign a symbolic SASL mechanism name to the
931   SPNEGO GSS-API mechanism: "SPNEGO".  SASL client implementations MUST
932   NOT choose the SPNEGO mechanism under any circumstances.  [What about
933   SASL apps that don't do mechanism negotiation?  Probably none exist.
934   But if any did then presumably it would OK to use the SPNEGO
935   mechanism, no? -Nico]
936
937   The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech()
938   [I-D.ietf-kitten-extended-mech-inquiry] can be used to identify such
939   mechanisms.
940
941
94215.  IANA Considerations
943
944   The SASL names for the Kerberos V GSS-API mechanism [RFC4121]
945   [RFC1964] used via GS2 SHALL be "KerberosV-GS2" and "KerberosV-GS2-
946   PLUS".
947
948
949
950
951Josefsson & Williams   Expires September 24, 2009              [Page 17]
952
953Internet-Draft                 SASL GS2-*                     March 2009
954
955
956   The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be
957   "SPNEGO" and "SPNEGO-PLUS".  As described in Section 14 the SASL
958   "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used.  These names are
959   provided as a convienience for SASL library implementors.
960
961   The IANA is advised that SASL mechanism names starting with "GS2-"
962   are reserved for SASL mechanisms which conform to this document.  The
963   IANA is directed to place a statement to that effect in the sasl-
964   mechanisms registry.
965
966   The IANA is further advised that SASL mechanisms MUST NOT end in
967   "-PLUS" except as a version of another mechanism name simply suffixed
968   with "-PLUS".
969
970     Subject: Registration of SASL mechanism GS2-*
971     SASL mechanism prefix: GS2-
972     Security considerations: RFC [THIS-DOC]
973     Published specification: RFC [THIS-DOC]
974     Person & email address to contact for further information:
975       Simon Josefsson <simon@josefsson.org>
976     Intended usage: COMMON
977     Owner/Change controller: iesg@ietf.org
978     Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.
979
980
98116.  Security Considerations
982
983   Security issues are also discussed throughout this memo.
984
985   The security provided by a GS2 mechanism depends on the security of
986   the GSS-API mechanism.  The GS2 mechanism family depends on channel
987   binding support, so GSS-API mechanisms that do not support channel
988   binding cannot be successfully used as SASL mechanisms via the GS2
989   bridge.
990
991   Because GS2 does not support security layers it is strongly
992   RECOMMENDED that channel binding to a secure external channel be
993   used.  Successful channel binding eliminates the possibility of man-
994   in-the-middle (MITM) attacks, provided that the external channel and
995   its channel binding data are secure and provided that the GSS-API
996   mechanism used is secure.  Authentication failure because of channel
997   binding failure may indicate that an MITM attack was attempted, but
998   note that a real MITM attacker would likely attempt to close the
999   connection to the client or simulate network partition , thus MITM
1000   attack detection is heuristic.
1001
1002   Use of channel binding will also protect the SASL mechanism
1003   negotiation -- if there is no MITM then the external secure channel
1004
1005
1006
1007Josefsson & Williams   Expires September 24, 2009              [Page 18]
1008
1009Internet-Draft                 SASL GS2-*                     March 2009
1010
1011
1012   will have protected the SASL mechanism negotiation.
1013
1014   The channel binding data MAY be sent (byt the actual GSS-API
1015   mechanism used) without confidentiality protection and knowledge of
1016   it is assumed to provide no advantage to an MITM (who can, in any
1017   case, compute the channel binding data independently).  If the
1018   external channel does not provide confidentiality protection and the
1019   GSS-API mechanism does not provide confidentiality protection for the
1020   channel binding data, then passive attackers (eavesdroppers) can
1021   recover the channel binding data.  See [RFC5056].
1022
1023   When constructing the input_name_string for GSS_Import_name() with
1024   the GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT
1025   canonicalize the server's fully qualified domain name using an
1026   insecure or untrusted directory service, such as the Domain Name
1027   System [RFC1034] without DNSSEC [RFC4033].
1028
1029   GS2 does not directly use any cryptographic algorithms, therefore it
1030   is automatically "algorithm agile", or, as agile as the GSS-API
1031   mechanisms that are available for use in SASL apoplications via GS2.
1032
1033   The security considerations of SASL [RFC4422], the GSS-API [RFC2743],
1034   channel binding [RFC5056], any external channels (such as TLS,
1035   [RFC5246], channel binding types (see the IANA channel binding type
1036   registry), and GSS-API mechanisms (such as the Kerberos V mechanism
1037   [RFC4121] [RFC1964]), may also apply.
1038
1039
104017.  Acknowledgements
1041
1042   The history of GS2 can be traced to the "GSSAPI" mechanism originally
1043   specified by RFC2222.  This document was derived from
1044   draft-ietf-sasl-gssapi-02 which was prepared by Alexey Melnikov with
1045   significant contributions from John G. Myers, although the majority
1046   of this document has been rewritten by the current authors.
1047
1048   Contributions of many members of the SASL mailing list are gratefully
1049   acknowledged.  In particular, ideas and feedback from Sam Hartman,
1050   Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document
1051   and the protocol.
1052
1053
105418.  References
1055
105618.1.  Normative References
1057
1058   [FIPS.180-1.1995]
1059              National Institute of Standards and Technology, "Secure
1060
1061
1062
1063Josefsson & Williams   Expires September 24, 2009              [Page 19]
1064
1065Internet-Draft                 SASL GS2-*                     March 2009
1066
1067
1068              Hash Standard", FIPS PUB 180-1, April 1995,
1069              <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.
1070
1071   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1072              Requirement Levels", BCP 14, RFC 2119, March 1997.
1073
1074   [RFC2743]  Linn, J., "Generic Security Service Application Program
1075              Interface Version 2, Update 1", RFC 2743, January 2000.
1076
1077   [RFC3629]  Yergeau, F., "UTF-8, a transformation format of ISO
1078              10646", STD 63, RFC 3629, November 2003.
1079
1080   [RFC4422]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
1081              Security Layer (SASL)", RFC 4422, June 2006.
1082
1083   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
1084              Encodings", RFC 4648, October 2006.
1085
1086   [RFC5056]  Williams, N., "On the Use of Channel Bindings to Secure
1087              Channels", RFC 5056, November 2007.
1088
1089   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
1090              Specifications: ABNF", STD 68, RFC 5234, January 2008.
1091
1092   [CCITT.X690.2002]
1093              International International Telephone and Telegraph
1094              Consultative Committee, "ASN.1 encoding rules:
1095              Specification of basic encoding Rules (BER), Canonical
1096              encoding rules (CER) and Distinguished encoding rules
1097              (DER)", CCITT Recommendation X.690, July 2002.
1098
109918.2.  Informative References
1100
1101   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
1102              STD 13, RFC 1034, November 1987.
1103
1104   [RFC1964]  Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
1105              RFC 1964, June 1996.
1106
1107   [RFC2025]  Adams, C., "The Simple Public-Key GSS-API Mechanism
1108              (SPKM)", RFC 2025, October 1996.
1109
1110   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
1111              (SASL)", RFC 2222, October 1997.
1112
1113   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
1114              Rose, "DNS Security Introduction and Requirements",
1115              RFC 4033, March 2005.
1116
1117
1118
1119Josefsson & Williams   Expires September 24, 2009              [Page 20]
1120
1121Internet-Draft                 SASL GS2-*                     March 2009
1122
1123
1124   [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
1125              Version 5 Generic Security Service Application Program
1126              Interface (GSS-API) Mechanism: Version 2", RFC 4121,
1127              July 2005.
1128
1129   [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
1130              Simple and Protected Generic Security Service Application
1131              Program Interface (GSS-API) Negotiation Mechanism",
1132              RFC 4178, October 2005.
1133
1134   [RFC4752]  Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple
1135              Authentication and Security Layer (SASL) Mechanism",
1136              RFC 4752, November 2006.
1137
1138   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
1139              (TLS) Protocol Version 1.2", RFC 5246, August 2008.
1140
1141   [I-D.newman-auth-scram]
1142              Menon-Sen, A., Melnikov, A., and C. Newman, "Salted
1143              Challenge Response (SCRAM) SASL Mechanism",
1144              draft-newman-auth-scram-10 (work in progress),
1145              February 2009.
1146
1147   [I-D.ietf-kitten-extended-mech-inquiry]
1148              Williams, N., "Extended Generic Security Service Mechanism
1149              Inquiry APIs", draft-ietf-kitten-extended-mech-inquiry-04
1150              (work in progress), March 2008.
1151
1152   [mitm]     Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle
1153              in Tunneled Authentication",
1154              WWW http://www.saunalahti.fi/~asokan/research/mitm.html.
1155
1156
1157Authors' Addresses
1158
1159   Simon Josefsson
1160   SJD AB
1161   Hagagatan 24
1162   Stockholm  113 47
1163   SE
1164
1165   Email: simon@josefsson.org
1166   URI:   http://josefsson.org/
1167
1168
1169
1170
1171
1172
1173
1174
1175Josefsson & Williams   Expires September 24, 2009              [Page 21]
1176
1177Internet-Draft                 SASL GS2-*                     March 2009
1178
1179
1180   Nicolas Williams
1181   Sun Microsystems
1182   5300 Riata Trace Ct
1183   Austin, TX  78727
1184   USA
1185
1186   Email: Nicolas.Williams@sun.com
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231Josefsson & Williams   Expires September 24, 2009              [Page 22]
1232
1233