7 Network Working Group E. Baize
8 Request for Comments: 2478 D. Pinkas
9 Category: Standards Track Bull
13 The Simple and Protected GSS-API Negotiation Mechanism
17 This document specifies an Internet standards track protocol for the
18 Internet community, and requests discussion and suggestions for
19 improvements. Please refer to the current edition of the "Internet
20 Official Protocol Standards" (STD 1) for the standardization state
21 and status of this protocol. Distribution of this memo is unlimited.
25 Copyright (C) The Internet Society (1998). All Rights Reserved.
29 This document specifies a Security Negotiation Mechanism for the
30 Generic Security Service Application Program Interface (GSS-API)
31 which is described in [1].
33 The GSS-API provides a generic interface which can be layered atop
34 different security mechanisms such that if communicating peers
35 acquire GSS-API credentials for the same security mechanism, then a
36 security context may be established between them (subject to policy).
37 However, GSS-API doesn't prescribe the method by which GSS-API peers
38 can establish whether they have a common security mechanism.
40 The Simple and Protected GSS-API Negotiation Mechanism defined here
41 is a pseudo-security mechanism, represented by the object identifier
42 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which
43 enables GSS-API peers to determine in-band whether their credentials
44 share common GSS-API security mechanism(s), and if so, to invoke
45 normal security context establishment for a selected common security
46 mechanism. This is most useful for applications that are based on
47 GSS-API implementations which support multiple security mechanisms.
49 This allows to negotiate different security mechanisms, different
50 options within a given security mechanism or different options from
51 several security mechanisms.
58 Baize & Pinkas Standards Track [Page 1]
60 RFC 2478 GSS-API Negotiation Mechanism December 1998
63 Once the common security mechanism is identified, the security
64 mechanism may also negotiate mechanism-specific options during its
65 context establishment. This will be inside the mechanism tokens, and
66 invisible to the SPNEGO protocol.
68 The simple and protected GSS-API mechanism negotiation is based on
69 the following negotiation model : the initiator proposes one security
70 mechanism or an ordered list of security mechanisms, the target
71 either accepts the proposed security mechanism, or chooses one from
72 an offered set, or rejects the proposed value(s). The target then
73 informs the initiator of its choice.
75 In its basic form this protocol requires an extra-round trip. Network
76 connection setup is a critical performance characteristic of any
77 network infrastructure and extra round trips over WAN links, packet
78 radio networks, etc. really make a difference. In order to avoid such
79 an extra round trip the initial security token of the preferred
80 mechanism for the initiator may be embedded in the initial token. If
81 the target preferred mechanism matches the initiator's preferred
82 mechanism, no additional round trips are incurred by using the
85 The simple and protected GSS-API mechanism negotiation provides a
86 technique to protect the negotiation that must be used when the
87 underlying mechanism selected by the target is capable of integrity
90 When all the mechanisms proposed by the initiator support integrity
91 protection or when the selected mechanism supports integrity
92 protection, then the negotiation mechanism becomes protected since
93 this guarantees that the appropriate mechanism supported by both
94 peers has been selected.
96 The Simple and Protected GSS-API Negotiation Mechanism uses the
97 concepts developed in the GSS-API specification [1]. The negotiation
98 data is encapsulated in context-level tokens. Therefore, callers of
99 the GSS-API do not need to be aware of the existence of the
100 negotiation tokens but only of the new pseudo-security mechanism. A
101 failure in the negotiation phase causes a major status code to be
102 returned: GSS_S_BAD_MECH.
114 Baize & Pinkas Standards Track [Page 2]
116 RFC 2478 GSS-API Negotiation Mechanism December 1998
121 2.1. Negotiation description
123 The model for security mechanism negotiation reuses a subset of the
124 concepts specified in [2].
126 Each OID represents one GSS-API mechanism or one variant of it.
128 - When one security mechanism is proposed by the initiator, it
129 represents the only security mechanism supported or selected
130 (when the additional APIs defined in the Annex A are used) by the
133 - When several security mechanisms are proposed by the initiator,
134 they represent a set of security mechanisms supported or selected
135 (when the additional APIs defined in the Annex A are used) by the
138 The first negotiation token sent by the initiator contains an ordered
139 list of mechanisms, a set of options (e.g. deleg, replay, conf flags)
140 that should be supported by the selected mechanism and optionally the
141 initial security token for the desired mechanism of the initiator
142 (i.e. the first of the list).
144 The first negotiation token sent by the target contains the result of
145 the negotiation (accept_completed, accept_incomplete or reject) and,
146 in case of accept, the agreed security mechanism. It may also include
147 the response to the initial security token from the initiator, when
148 the first proposed mechanism of the initiator has been selected. When
149 the first mechanism is acceptable to the target,it should respond to
150 the initial security token for the desired mechanism of the initiator
151 when it is present. However, if this is not possible, the target can
152 simply ignore it and omit the responseToken from the first reply.
154 Implementations that can piggyback the initial token will be rewarded
155 by faster connection setup.
157 In case of a successful negotiation, the security mechanism
158 represents the value suitable for the target, and picked up from the
159 list offered by the initiator. The policy by which the target
160 chooses a mechanism is an implementation-specific local matter. In
161 the absence of other policy, the target should chose the first
162 mechanism in the list for which valid credentials are available.
164 Once a mechanism has been selected, the tokens specific to the
165 selected mechanism are carried within the negotiation tokens (in the
166 mechToken for the initiator and in the responseToken for the target).
170 Baize & Pinkas Standards Track [Page 3]
172 RFC 2478 GSS-API Negotiation Mechanism December 1998
175 2.2. Negotiation procedure
177 The negotiation procedure is summarised as follows:
179 (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but
180 requests (either explicitly, with the negotiation mechanism, or
181 through accepting a default, when the default is the negotiation
182 mechanism) that the Simple and Protected GSS-API Negotiation
185 (b) the initiator GSS-API implementation emits a negotiation token
186 containing a list of supported security mechanisms for the
187 credentials used for this context establishment, and optionally
188 an initial security token for the first mechanism from that list
189 (i.e. the preferred mechanism), and indicates
190 GSS_S_CONTINUE_NEEDED status;
192 (c) The GSS-API initiator sends the token to the target application;
194 (d) The GSS-API target deposits the token through invoking
195 GSS_Accept_sec_context. The target GSS-API implementation emits a
196 negotiation token containing which if any of the proposed
197 mechanisms it supports (or has selected).
199 If the mechanism selected by the target matches the preferred
200 mechanism identified by the initiator and the initiator provides a
201 mechToken, the negotiation token response may contain also an initial
202 security token from that mechanism.
204 If the preferred mechanism is accepted, GSS_Accept_sec_context()
205 indicates GSS_S_COMPLETE when unilateral or mutual authentication has
206 been performed and involves a single token in either direction.
208 If a proposed mechanism is accepted, and it was not the preferred
209 mechanism, or if the first negotiation token sent by the initiator
210 did not included a mechToken, then the negotiation token response
211 sent by the target may contain also a response token from that
212 mechanism which transmits mechanism-specific information (e.g. to
213 transmit a certificate). The initiator may ignore such an initial
214 token if it is not prepared to process it.
216 If a proposed mechanism other than the preferred mechanism is
217 accepted, or the preferred mechanism is accepted but involves
218 multiple exchanges (e.g. challenge-response authentication), then
219 GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.
226 Baize & Pinkas Standards Track [Page 4]
228 RFC 2478 GSS-API Negotiation Mechanism December 1998
231 If the proposed mechanism(s) are rejected, GSS_Accept_sec_context()
232 indicates GSS_S_BAD_MECH status. The security context initialisation
235 (e) The GSS-API target returns the token to the initiator
238 (f) The GSS-API initiator deposits the token through invoking
239 GSS_Init_sec_context.
241 GSS_Init_sec_context() may then indicate GSS_S_CONTINUE_NEEDED,
242 GSS_S_COMPLETE or GSS_S_BAD_MECH status.
244 The GSS_S_BAD_MECH status is returned when the negotiation token
245 carries a reject result or when the negotiation token carries an
246 accept result and the mechanism selected by the target is not
247 included in the initial list sent by the initiator.
249 The GSS_S_BAD_MIC status is returned when the selected mechanism
250 supports a MIC token but the MIC computed over the list of
251 mechanisms sent by the initiator is missing or incorrect.
253 If the negotiation token carries a reject result, the context
254 establishment is impossible. For example, a rejection will occur
255 if the target doesn't support the initiator's proposed mechanism
256 type(s). Upon failure of the mechanism negotiation procedure, the
257 mech_type output parameter value is the negotiation mechanism
260 The GSS_S_CONTINUE_NEEDED status is returned when the negotiation
261 token carries an accept result and further tokens must be
262 transferred in order to complete context establishment for the
263 selected mechanism. In that case GSS_Init_sec_context() returns an
264 initial context token as output_token (with the selected
265 mechanism's context token encapsulated within that output_token).
267 The initiator then sends the output_token to the target. The
268 security context initialisation is then continued according to the
269 standard GSS-API conventions for the selected mechanism, where the
270 tokens of the selected mechanism are encapsulated until the
271 GSS_S_COMPLETE is returned for both the initiator and the target.
272 When GSS_S_CONTINUE_NEEDED is returned, the mech_type output
273 parameter is not yet valid.
275 When GSS_S_COMPLETE is returned, the mech_type output parameter
276 indicates the selected mechanism. When the final negotiation token
277 does not contain a MIC, the initiator GSS-API implementation must
278 check the returned/selected mechanism is on the originally
282 Baize & Pinkas Standards Track [Page 5]
284 RFC 2478 GSS-API Negotiation Mechanism December 1998
287 submitted list of mechanisms and also verify that the selected
288 mechanism is not able to support a MIC. When the final negotiation
289 token contains a MIC over the initial mechanisms list sent by the
290 initiator, the MIC must be verified.
292 Note that the *_req_flag input parameters for context establishment
293 are relative to the selected mechanism, as are the *_state output
294 parameters. i.e., these parameters are not applicable to the
295 negotiation process per se.
297 The initiator GSS-API calling application may need to know when the
298 negotiation exchanges were protected or not. For this, when
299 GSS_S_COMPLETE is returned, it can simply test the integ_avail flag.
300 When this flag is set it indicates that the negotiation was
303 On receipt of a negotiation token on the target side, a GSS-API
304 implementation that does not support negotiation would indicate the
305 GSS_S_BAD_MECH status as if a particular basic security mechanism had
306 been requested but was not supported.
308 When GSS_Acquire_cred is invoked with the negotiation mechanism as
309 desired_mechs, an implementation-specific default credential is used
310 to carry on the negotiation. A set of mechanisms as specified locally
311 by the system administrator is then available for negotiation. If
312 there is a desire for the caller to make its own choice, then an
313 additional API has to be used (see Appendix A).
319 MechType::= OBJECT IDENTIFIER
322 Each security mechanism is as defined in [1].
324 3.2. Negotiation Tokens
326 The syntax of the negotiation tokens follows the InitialContextToken
327 syntax defined in [1]. The security mechanism of the initial
328 negotiation token is identified by the Object Identifier
329 iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2).
338 Baize & Pinkas Standards Track [Page 6]
340 RFC 2478 GSS-API Negotiation Mechanism December 1998
345 This section specifies the syntax of the corresponding
346 "innerContextToken" field for the first token and subsequent
347 negotiation tokens. During the mechanism negociation, the
348 "innerContextToken" field contains the ASN.1 structure
349 "NegociationToken" given below, encoded using the DER encoding
352 NegotiationToken ::= CHOICE {
353 negTokenInit [0] NegTokenInit,
354 negTokenTarg [1] NegTokenTarg }
356 MechTypeList ::= SEQUENCE OF MechType
358 NegTokenInit ::= SEQUENCE {
359 mechTypes [0] MechTypeList OPTIONAL,
360 reqFlags [1] ContextFlags OPTIONAL,
361 mechToken [2] OCTET STRING OPTIONAL,
362 mechListMIC [3] OCTET STRING OPTIONAL
365 ContextFlags ::= BIT STRING {
376 Negotiation token sent by the initiator to the target, which
377 contains, for the first token sent, one or more security mechanisms
378 supported by the initiator (as indicated in the field mechTypes)
379 and the service options (reqFlags) that are requested to establish
380 the context. The context flags should be filled in from the
381 req_flags parameter of init_sec_context().
383 The mechToken field is optional for the first token sent that all
384 target implementations would not have to support. However for those
385 targets that do support piggybacking the initial mechToken, an
386 optimistic negotiation response is possible. Otherwise the
387 mechToken is used to carry the tokens specific to the mechanism
394 Baize & Pinkas Standards Track [Page 7]
396 RFC 2478 GSS-API Negotiation Mechanism December 1998
399 The mechListMIC is an optional field. In the case that the chosen
400 mechanism supports integrity, the initiator may optionally include
401 a mechListMIC which is the result of a GetMIC of the MechTypes in
402 the initial NegTokenInit and return GSS_S_COMPLETE.
404 When the chosen mechanism uses an odd number of messages, the final
405 mechanism token will be sent from the initiator to the acceptor. In
406 this case, there is a tradeoff between using the optimal number of
407 messages, or using an additional message from the acceptor to the
408 initiator in order to give the initiator assurance that no
409 modification of the initiator's mechanism list occurred. The
410 implementation can choose which tradeoff to make (see section 4.2.2
411 for further details for the processing of that field).
413 NegTokenTarg ::= SEQUENCE {
414 negResult [0] ENUMERATED {
415 accept_completed (0),
416 accept_incomplete (1),
417 reject (2) } OPTIONAL,
418 supportedMech [1] MechType OPTIONAL,
419 responseToken [2] OCTET STRING OPTIONAL,
420 mechListMIC [3] OCTET STRING OPTIONAL
424 Negotiation token returned by the target to the initiator which
425 contains, for the first token returned, a global negotiation result
426 and the security mechanism selected (if any).
429 The result accept_completed indicates that a context has been
430 successfully established, while the result accept_incomplete
431 indicates that additional token exchanges are needed.
433 Note: For the case where (a) a single-token context setup is
434 used and (b) the preferred mechanism does not support the
435 integrity facility which would cause a mechListMIC to be
436 generated and enclosed, this feature allows to make a
437 difference between a mechToken sent by the initiator but not
438 processed by the target (accept_incomplete) and a mechToken
439 sent by the initiator and processed by the target
442 For those targets that support piggybacking the initial mechToken,
443 an optimistic negotiation response is possible and includes in that
444 case a responseToken which may continue the authentication exchange
445 (e.g. when mutual authentication has been requested or when
446 unilateral authentication requires several round trips). Otherwise
450 Baize & Pinkas Standards Track [Page 8]
452 RFC 2478 GSS-API Negotiation Mechanism December 1998
455 the responseToken is used to carry the tokens specific to the
456 mechanism selected. For subsequent tokens (if any) returned by the
457 target, negResult, and supportedMech are not present.
459 For the last token returned by the target, the mechListMIC, when
460 present, is a MIC computed over the MechTypes using the selected
464 Result of the negotiation exchange, specified by the target.
469 The target accepts the preferred security mechanism,
470 and the context is established for the target or,
473 The target accepts one of the proposed security
474 mechanisms and further exchanges are necessary, or,
477 The target rejects all the proposed security
481 This field has to be present when negResult is "accept_completed"
482 or "accept_incomplete". It is a choice from the mechanisms offered
486 This field may be used either to transmit the response to the
487 mechToken when sent by the initiator and when the first mechanism
488 from the list has been selected by the target or to carry the
489 tokens specific to the selected security mechanism.
492 If the selected mechanism is capable of integrity protection, this
493 field must be present in the last message of the negotiation,
494 (i.e., when the underlying mechanism returns a non-empty token and
495 a major status of GSS_S_COMPLETE); it contains the result of a
496 GetMIC of the MechTypes field in the initial NegTokenInit. It
497 allows to verify that the list initially sent by the initiator has
498 been received unmodified by the target.
506 Baize & Pinkas Standards Track [Page 9]
508 RFC 2478 GSS-API Negotiation Mechanism December 1998
511 3.2.2. Processing of mechListMIC.
513 If the mechanism selected by the negotiation does not support
514 integrity, then no mechListMIC is included, otherwise a mechListMIC
515 must be used and validated as indicated below.
517 If the mechanism supports integrity and uses an even number of
518 messages, then the target must compute a MIC as described above, and
519 send this in the final NegTokenTarg along with the final mechToken.
520 The initiator when receiving the last token must require that the
521 mechListMIC field be present and valid. In the absence of a valid
522 mechListMIC, the negotiation must fail as if the last context
523 establishment token was invalid.
525 In the case that the chosen mechanism supports integrity and uses an
526 odd number of messages, the final mechanism token will be sent from
527 the initiator to the target. In this case, there is a tradeoff
528 between using the optimal number of messages, or using an additional
529 message from the target to the initiator in order to give the
530 initiator assurance that no modification of the initiator's mechanism
531 list occurred. The implementation can choose which tradeoff to make.
533 When generating the final NegTokenInit message, the NegTokenInit may
534 optionally include a mechListMIC which is the result of a GetMIC of
535 the MechTypes in the initial NegTokenInit and return GSS_S_COMPLETE.
536 The target must check the presence of the MIC computed over the
537 mechList sent in the initial NegTokenInit. Three cases may then be
540 1) If the mechListMIC is present and correct, then
541 GSS_S_COMPLETE is returned to the target with no token; the
542 context is established by the target.
544 2) If the mechListMIC is present but invalid, then the context
545 establishment must fail. An error major status code is
546 returned to the target.
548 3) If the mechListMIC is not included in the final NegTokenInit,
549 then GSS_S_COMPLETE must be returned to the target with a
550 token. This token must be a NegTokenTarg, with a MIC included
551 as described above, and no responseToken. The application will
552 then send this token back to the initiator, which must verify
553 that the mechListMIC field is present and valid.
562 Baize & Pinkas Standards Track [Page 10]
564 RFC 2478 GSS-API Negotiation Mechanism December 1998
567 Note: If the MIC was originally sent by the initiator, but
568 thenafter deleted by an attacker, the target will send
569 back a token according to the description above, but the
570 initiator will be unable to process that returned token
571 and the context establishment must then fail.
573 4. EXAMPLES : SECURITY MECHANISM NEGOTIATION
575 Here are some examples of security mechanism negotiation between an
576 initiator (I) and a target (T).
580 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
582 (I) invokes GSS_Init_sec_context() with :
585 mech_type = OID for negotiation mechanism or NULL, if the
586 negotiation mechanism is the default mechanism.
589 major_status = GSS_S_CONTINUE_NEEDED
590 output_token = negTokenInit
592 The negotiation token (negTokenInit) contains two security mechanisms
594 mechType = GSS-MECH1 or
597 (I) sends to (T) the negotiation token.
599 4.2 Successful negotiation steps
601 (T) supports GSS-MECH2
602 (T) receives the negotiation token (negTokenInit) from (I)
603 (T) invokes GSS_Accept_sec_context() with :
606 input_token = negTokenInit
609 major_status = GSS_S_CONTINUE_NEEDED
610 output_token = negTokenTarg
612 The negotiation token (negTokenTarg) contains :
613 negResult = accept (the negotiation result)
614 supportedMech : mechType = GSS-MECH2
618 Baize & Pinkas Standards Track [Page 11]
620 RFC 2478 GSS-API Negotiation Mechanism December 1998
623 (T) returns the negotiation token (negTokenTarg) to (I)
624 (I) invokes GSS_Init_sec_context() with :
627 input_token = negTokenTarg
630 major_status = GSS_S_COMPLETE
631 output_token = initialContextToken (initial context token
633 mech_type = GSS-MECH2
635 The subsequent steps are security mechanism specific, and work as
636 specified in [1]. The output tokens from the security mechanism are
637 encapsulated in a NegTokenTarg message (with the supportedMech field
638 omitted, and the mechListMIC included with the last token).
640 4.3. Failed negotiation steps
642 (T) supports GSS-MECH3.
643 (T) receives the negotiation token (negTokenInit) from (I)
644 (T) invokes GSS_Accept_sec_context() with :
647 input_token = negTokenInit
650 major_status = GSS_S_BAD_MECH
651 output_token = negTokenTarg
653 The negotiation token (negTokenTarg) contains :
655 negResult = reject (the negotiation result)
657 (T) returns the negotiation token (negTokenTarg) to (I)
658 (I) invokes GSS_Init_sec_context() with :
661 input_token = negTokenTarg
664 major_status = GSS_S_BAD_MECH
666 The security context establishment has failed.
674 Baize & Pinkas Standards Track [Page 12]
676 RFC 2478 GSS-API Negotiation Mechanism December 1998
679 4.4 Successful Negotiation with preferred mechanism info
681 (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2).
683 (I) invokes GSS_Init_sec_context() with :
686 mech_type = OID for negotiation mechanism or NULL, if the
687 negotiation mechanism is the default mechanism.
690 major_status = GSS_S_CONTINUE_NEEDED
691 output_token = negTokenInit
693 The negotiation token (negTokenInit) contains two security mechanisms
695 mechType = GSS-MECH1 or
698 mechToken = output_token from GSS_Init_sec_context
699 ( first mechType) as described in [1]
701 (I) sends to (T) the negotiation token.
703 (T) supports GSS-MECH1.
704 (T) receives the negotiation token (negTokenInit) from (I)
705 (T) invokes GSS_Accept_sec_context() with :
708 input_token = negTokenInit
711 major_status = GSS_S_CONTINUE_NEEDED
712 output_token = negTokenTarg
714 The negotiation token (negTokenTarg) contains :
715 negResult = accept (the negotiation result)
716 supportedMech : mechType = GSS-MECH1
718 mechToken = output_token from
719 GSS_Accept_sec_context(mechToken )
721 (T) returns the negotiation token (negTokenTarg) to (I)
722 (I) invokes GSS_Init_sec_context() with :
725 input_token = negTokenTarg
730 Baize & Pinkas Standards Track [Page 13]
732 RFC 2478 GSS-API Negotiation Mechanism December 1998
736 major_status = GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED as needed
737 output_token = ContextToken (initial or subsequent context token
739 mech_type = GSS-MECH1
741 Specific implementations of the protocol can support the optimistic
742 negotiation by completing the security context establishment using the
743 agreed upon mechanism as described in [1]. As described above in
744 section 5.2, the output tokens from the security mechanisms are
745 encapsulated in a NegTokenTarg message (with the negResult and
746 supportedMech fields omitted, and the mechListMIC included with the
749 5. SECURITY CONSIDERATIONS
751 When the mechanism selected by the target from the list supplied by
752 the initiator supports integrity protection, then the negotiation is
755 When one of the mechanisms proposed by the initiator does not support
756 integrity protection, then the negotiation is exposed to all threats
757 a non secured service is exposed. In particular, an active attacker
758 can force to use a security mechanism which is not the common
759 preferred one (when multiple security mechanisms are shared between
760 peers) but which is acceptable anyway to the target.
762 In any case, the communicating peers may be exposed to the denial of
767 Acknowledgments are due to Stephen Farrell of SSE, Marc Horowitz of
768 Stonecast, John Linn of RSA Laboratories, Piers McMahon of Platinum
769 Technology, Tom Parker of ICL and Doug Rosenthal of EINet, for
770 reviewing earlier versions of this document and for providing useful
771 inputs. Acknowledgments are also due to Peter Brundrett of Microsoft
772 for his proposal for an optimistic negotiation, and for Bill
773 Sommerfeld of Epilogue Technology for his proposal for protecting the
786 Baize & Pinkas Standards Track [Page 14]
788 RFC 2478 GSS-API Negotiation Mechanism December 1998
794 GSS-API NEGOTIATION SUPPORT API
796 In order to provide to a GSS-API caller (either the initiator or the
797 target or both) the ability to choose among the set of supported
798 mechanisms a reduced set of mechanisms for negotiation, two
799 additional APIs are defined:
801 GSS_Get_neg_mechs() indicates the set of security mechanisms
802 available on the local system to the caller for negotiation.
804 GSS_Set_neg_mechs() specifies the set of security mechanisms to be
805 used on the local system by the caller for negotiation.
807 A.1. GSS_Set_neg_mechs call
810 cred_handle CREDENTIAL HANDLE
811 - NULL specifies default credentials
812 mech_set SET OF OBJECT IDENTIFIER
815 major_status INTEGER,
816 minor_status INTEGER,
818 Return major_status codes :
819 GSS_S_COMPLETE indicates that the set of security mechanisms
820 available for negotiation has been set to mech_set. GSS_S_FAILURE
821 indicates that the requested operation could not be performed for
822 reasons unspecified at the GSS-API level.
824 Allows callers to specify the set of security mechanisms that may be
825 negotiated with the credential identified by cred_handle. This call
826 is intended for support of specialised callers who need to restrict
827 the set of negotiable security mechanisms from the set of all
828 security mechanisms available to the caller (based on available
829 credentials). Note that if more than one mechanism is specified in
830 mech_set, the order in which those mechanisms are specified implies a
831 relative mechanism preference for the target.
842 Baize & Pinkas Standards Track [Page 15]
844 RFC 2478 GSS-API Negotiation Mechanism December 1998
847 A.2. GSS_Get_neg_mechs call
850 cred_handle CREDENTIAL HANDLE
851 - NULL specifies default credentials
854 major_status INTEGER,
855 minor_status INTEGER,
856 mech_set SET OF OBJECT IDENTIFIER
858 Return major_status codes :
859 GSS_S_COMPLETE indicates that the set of security mechanisms
860 available for negotiation has been returned in
862 GSS_S_FAILURE indicates that the requested operation could not
863 be performed for reasons unspecified at the GSS-API level.
865 Allows callers to determine the set of security mechanisms available
866 for negotiation with the credential identified by cred_handle. This
867 call is intended for support of specialised callers who need to
868 reduce the set of negotiable security mechanisms from the set of
869 supported security mechanisms available to the caller (based on
870 available credentials).
872 Note: The GSS_Indicate_mechs() function indicates the full set of
873 mechanism types available on the local system. Since this call has no
874 input parameter, the returned set is not necessarily available for
879 [1] Linn, J., "Generic Security Service Application Program
880 Interface", RFC 2078, January 1997.
882 [2] Standard ECMA-206, "Association Context Management including
883 Security Context Management", December 1993. Available on
898 Baize & Pinkas Standards Track [Page 16]
900 RFC 2478 GSS-API Negotiation Mechanism December 1998
906 Bull - 300 Concord Road
907 Billerica, MA 01821 - USA
909 Phone: +1 978 294 61 37
910 Fax: +1 978 294 61 09
911 EMail: Eric.Baize@bull.com
918 78340 Les Clayes-sous-Bois - FRANCE
920 Phone: +33 1 30 80 34 87
921 Fax: +33 1 30 80 33 21
922 EMail: Denis.Pinkas@bull.net
954 Baize & Pinkas Standards Track [Page 17]
956 RFC 2478 GSS-API Negotiation Mechanism December 1998
959 Full Copyright Statement
961 Copyright (C) The Internet Society (1998). All Rights Reserved.
963 This document and translations of it may be copied and furnished to
964 others, and derivative works that comment on or otherwise explain it
965 or assist in its implementation may be prepared, copied, published
966 and distributed, in whole or in part, without restriction of any
967 kind, provided that the above copyright notice and this paragraph are
968 included on all such copies and derivative works. However, this
969 document itself may not be modified in any way, such as by removing
970 the copyright notice or references to the Internet Society or other
971 Internet organizations, except as needed for the purpose of
972 developing Internet standards in which case the procedures for
973 copyrights defined in the Internet Standards process must be
974 followed, or as required to translate it into languages other than
977 The limited permissions granted above are perpetual and will not be
978 revoked by the Internet Society or its successors or assigns.
980 This document and the information contained herein is provided on an
981 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
982 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
983 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
984 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
985 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1010 Baize & Pinkas Standards Track [Page 18]