Internet-Draft Eric Baize, Denis Pinkas IETF Common Authentication Technology WG Bull 22 April 1997 The Simple and Protected GSS-API Negotiation Mechanism STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Comments on this document should be sent to "cat-ietf@mit.edu", the IETF Common Authentication Technology WG discussion list. Distribution of this document is unlimited. 2. ABSTRACT This draft document specifies a Security Negotiation Mechanism for the Generic Security Service Application Program Interface (GSS-API) which is described in [1]. The GSS-API provides a generic interface which can be layered atop different security mechanisms such that if communicating peers acquire GSS-API credentials for the same security mechanism, then a security context may be established between them (subject to policy). However, GSS-API doesn't prescribe the method by which GSS-API peers can establish whether they have a common security mechanism. The Simple and Protected GSS-API Negotiation Mechanism defined here is a pseudo-security mechanism, represented by the object identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2) which enables GSS-API peers to determine in-band whether their credentials share common GSS-API security mechanism(s), and if so, to invoke normal security context establishment for a selected common security mechanism. This is most useful for applications that are based on GSS-API implementations which support multiple security mechanisms. Baize, Pinkas Document Expiration: 22 October 1997 [Page 1] Internet-Draft April 22, 1997 As most existing GSS-API security mechanisms can support different options (such as differing cryptographic algorithms due to policy or legislative constraints), the Simple and Protected GSS-API Negotiation Mechanism allows to negotiate security mechanisms including their options (i.e. variants). Mechanism options can be considered as providing a type of "quality of protection" for security contexts. To facilitate mechanism negotiation, the OID which currently defines a security mechanism is "extended" to be able to specify options within a security mechanism rather than simply the basic mechanism. When the OID specifies the mechanism only and no explicit option, then this means that the default option is used. The default option and the specific options for a given mechanism are as defined in the IETF GSS-API specification(s) for the mechanism. This allows to negotiate basic security mechanisms, different options within a given security mechanism or different options from several basic security mechanisms. In addition, a given security mechanism may still negotiate mechanism- specific options during the context establishment for that mechanism, i.e. after the mechanism has been selected by the negotiation process. The simple and protected GSS-API mechanism negotiation is based on the following negotiation model : the initiator proposes one or several security mechanisms, the target either accepts the proposed security mechanism, or chooses one from an offered set, or rejects the proposed value(s). The target informs the initiator of its choice and may also return mechanism specific information related to the chosen mechanism. In its basic form this protocol requires an extra-round trip. Network connection setup is a critical performance characteristic of any network infrastructure and extra round trips over WAN links, packet radio networks, etc. really make a difference. In order to avoid such an extra round trip the initial security token of the preferred mechanism for the initiator may be embedded in the initial token. If the target preferred mechanism matches the initiator's preferred mechanism, no additional round trips are incurred by using the negotiation protocol. The simple and protected GSS-API mechanism negotiation provides a technique to protect the negotiation that must be used when the underlying mechanism selected by the target is capable of integrity protection. When all the mechanisms proposed by the initiator support integrity protection or when the selected mechanism supports integrity protection, then the negotiation mechanism becomes protected since this guarantees that the appropriate mechanism supported by both peers has been selected. Baize, Pinkas Document Expiration: 22 October 1997 [Page 2] Internet-Draft April 22, 1997 The Simple and Protected GSS-API Negotiation Mechanism uses the concepts developed in GSS-API specification [1], and requires the use of new GSS-API context-level tokens : negotiation tokens. Callers of the GSS-API do not need to be aware of the existence of the negotiation tokens but only of the new pseudo-security mechanism. A failure in the negotiation phase causes a major status code to be returned: GSS_S_BAD_MECH. 3. NEGOTIATION MODEL 3.1. Negotiation description The model for security mechanism negotiation reuses a subset of the concepts specified in [2]. Each security mechanism represents one basic security mechanism along with one option for this security mechanism (when no option is present the default option is assumed). - When one security mechanism is proposed by the initiator, it represents the only security mechanism option supported or selected (when the additional APIs defined in the Annex A are used) by the initiator. - When several security mechanisms are proposed by the initiator, they represent a set of security mechanisms supported or selected (when the additional APIs defined in the Annex A are used) by the initiator. The first negotiation token sent by the initiator contains an ordered list of mechanisms and optionally the initial security token for the desired mechanism of the initiator (i.e. the first of the list). The first negotiation token sent by the target contains the result of the negotiation (accept or reject) and, in case of accept, the agreed security mechanism along with optional mechanism specific information. It may also include the response to the initial security token for the desired mechanism of the initiator, when the first proposed mechanism has been selected. Not all targets must be able to respond to the initial security token for the desired mechanism when it is present. The target can simply ignore it and complete the negotiation without it. Implementations that can piggyback the initial token will be rewarded by faster connection setup. In case of a successful negotiation, the security mechanism represents the value suitable for the target, and picked up from the list offered by the initiator. The target selects the value according to a simple selection criteria: it checks if the first entry from its own list is present in the set offered by the initiator. If the entry is present, then it is the agreed mechanism, if not then the second entry from its own ordered list is checked and the process continues until all entries have been checked. Thus, the target's mechanism preferences have precedence when more than one common mechanism is available between the target and initiator. Baize, Pinkas Document Expiration: 22 October 1997 [Page 3] Internet-Draft April 17, 1996 3.2. Negotiation procedure The negotiation procedure is summarised as follows: (a) the GSS-API initiator invokes GSS_Init_sec_context as normal, but requests (either explicitly, with the negotiation mechanism, or through accepting a default, when the default is the negotiation mechanism) that the Simple and Protected GSS-API Negotiation Mechanism be used; b) the initiator GSS-API implementation emits a negotiation token containing the set of supported security mechanism for the credentials used for this context establishment, and optionally the initial security token for the preferred mechanism, and indicates GSS_CONTINUE_NEEDED status; (c) The GSS-API initiator sends the token to the target application; (d) The GSS-API target deposits the token through invoking GSS_Accept_sec_context. The target GSS-API implementation emits a negotiation token containing which if any of the proposed mechanisms it supports (or has selected). If the preferred mechanism selected by the target matches the preferred mechanism identified by the initiator and the initiator provides a preferredToken, the negotiation token response may contain also the initial security token from that mechanism. If the preferred mechanism is accepted, GSS_Accept_sec_context() indicates GSS_COMPLETE when unilateral or mutual authentication has been performed and involves a single token in either direction. If the proposed mechanism(s) are accepted, or the preferred mechanism is accepted but involves multiple exchanges (e.g. challenge-response authentication), then GSS_Accept_sec_context()indicates GSS_CONTINUE_NEEDED status. If the proposed mechanism(s) are rejected, GSS_Accept_sec_context() indicates GSS_S_BAD_MECH status. The security context initialisation has failed. (e) The GSS-API target returns the token to the initiator application; (f) The GSS-API initiator deposits the token through invoking GSS_Init_sec_context. GSS_Init_sec_context() may then indicate GSS_CONTINUE_NEEDED, GSS_COMPLETE or GSS_S_BAD_MECH status. The GSS_S_BAD_MECH status is returned when the negotiation token carries a reject result or when the negotiation token carries an accept result and the mechanism selected by the target is not included in the initial list sent by the initiator or the Baize, Pinkas Document Expiration: 22 October 1997 [Page 4] Internet-Draft April 22, 1997 selected mechanism supports a MIC token but the MIC computed over the list of mechanisms sent by the initiator is missing or incorrect. If the negotiation token carries a reject result, the context establishment is impossible. For example, a rejection will occur if the target doesn't support the initiator's proposed mechanism type(s) and/or mechanism option(s). Upon failure of the mechanism negotiation procedure, the mech_type output parameter value is the negotiation mechanism type. The GSS_CONTINUE_NEEDED status is returned when the negotiation token carries an accept result. In that case GSS_Init_sec_context() returns an initial context token as output_token. The initiator then sends the output_token to the target. The security context initialisation is then continued according to the standard GSS-API conventions for the selected mechanism, where the tokens of the selected mechanism are encapsulated until the GSS_COMPLETE is returned for both the initiator and the target. When GSS_CONTINUE_NEEDED is returned, the mech_type output parameter is not yet valid. When GSS_COMPLETE is returned, the mech_type output parameter indicates the selected mechanism. When the final negotiation token does not contain a MIC, the initiator GSS-API implementation must check the returned/selected mechanism options with its originally submitted list of mechanism options and also verify that the selected mechanism is not able to support a MIC. When the final negotiation token contains a MIC over the initial mechanisms list sent by the initiator, the MIC must be verified. Note that the *_req_flag input parameters for context establishment are relative to the selected mechanism, as are the *_state output parameters. i.e., these parameters are not applicable to the negotiation process per se. The initiator GSS-API calling application may know when the negotiation exchanges were protected or not. For this, when GSS_COMPLETE is returned, it can simply test the integ_avail flag. When this flag is set it indicates that the negotiation was protected. On receipt of a negotiation token on the target side, a GSS-API implementation that does not support negotiation would indicate the GSS_FAILURE status as if a particular basic security mechanism had been requested but was not supported. When GSS_Acquire_cred is invoked with the negotiation mechanism as desired_mechs, an implementation-specific default credential is used to carry on the negotiation. A set of mechanisms as specified locally by the system administrator is then available for negotiation. If there is a desire for the caller to make its own choice, then an additional API has to be used (see Appendix A). Baize, Pinkas Document Expiration: 22 October 1997 [Page 5] Internet-Draft April 22, 1997 4. DATA ELEMENTS 4.1. Mechanism Type MechType::= OBJECT IDENTIFIER mechType The concept of mechType is extended to specify a basic security mechanism including its options. Each basic security mechanism is as defined in [1], and must provide a single default option which fully specifies the mechanism. The default option is represented by the OID of the mechanism itself (i.e. without any extension). The options are specified by extending the OID. This extension is defined in the same IETF GSS-API specification as the security mechanism context token specification. 4.2. Negotiation Tokens The syntax of the negotiation tokens follows the InitialContextToken syntax defined in [1]. The security mechanism of the initial negotiation token is identified by the Object Identifier iso.org.dod.internet.security.mechanism.snego (1.3.6.1.5.5.2). 4.2.1. Syntax This section specifies the syntax of the corresponding "innerContextToken" field for the first token and subsequent negotiation tokens. NegotiationToken ::= CHOICE { negTokenInit [0] NegTokenInit, negTokenTarg [1] NegTokenTarg } MechType ::= OBJECT IDENTIFIER MechTypeList ::= SEQUENCE OF MechType NegTokenInit ::= SEQUENCE { mechTypes [0] MechTypeList OPTIONAL preferredToken [1] OCTET STRING OPTIONAL } negTokenInit Negotiation token sent by the initiator to the target, which contains, for the first token sent, one or more security mechanisms supported by the initiator. The preferredToken is an optional field of the first token sent that all target implementations would not have to support. However for those targets that do support piggybacking the initial preferredToken, an optimistic negotiation response is possible. Baize, Pinkas Document Expiration: 22 October 1997 [Page 6] Internet-Draft April 22, 1997 NegTokenTarg ::= SEQUENCE { negResult [0] ENUMERATED { accept (0), reject (1) } OPTIONAL supportedMech [1] MechType OPTIONAL MechSpecInfo [2] OCTET STRING OPTIONAL preferredToken [3] OCTET STRING OPTIONAL mechListMIC [4] OCTET STRING OPTIONAL } negTokenTarg Negotiation token returned by the target to the initiator which contains, for the first token returned, a global negotiation result, the security mechanism selected (if any) and optional information specific to the security mechanism selected by the target. For those targets that support piggybacking the initial preferredToken, an optimistic negotiation response is possible and includes in that case a preferredToken which may continue the authentication exchange (e.g. when mutual authentication has been requested or when unilateral authentication requires several round trips). Otherwise the preferredToken is used to carry the tokens specific to the mechanism selected. For the last token returned by the target, the mechListMIC is a MIC computed over the MechTypes using the selected mechanism. negResult Result of the negotiation exchange, specified by the target. This can be either : accept The target accepts one of the proposed security mechanisms, or, reject The target rejects all the proposed security mechanisms. supportedMech This field has to be present when negResult is "accept". It is a choice from the mechanisms offered by the initiator. MechSpecInfo This field may be used to transmit mechanism specific information relative to the security mechanism selected by the target. preferredToken This field may be used either to transmit the response to the preferredToken when sent by the initiator and when the first mechanism from the list has been selected by the target or to carry the tokens specific to the selected security mechanism. mechListMIC If the selected mechanism is capable of integrity protection, this field must be present in the last message of the negotiation, (i.e., when the underlying mechanism returns a non-empty token Baize, Pinkas Document Expiration: 22 October 1997 [Page 7] Internet-Draft April 22, 1997 and a major status of GSS_COMPLETE); it contains the result of a GetMIC of the MechTypes field in the initial NegTokenInit. 4.2.2. Processing of mechListMIC. When the mechanism selected by the negotiation supports integrity protection as a service, the mechListMIC must be used and validated. In particular, the target that sends the last context establishment token must also include the result of a gss_get_mic() of the mechTypeList sent by the initiator in the first token; in addition, the initiator that receives the last token must require that the mechListMIC field be present and valid. In the absence of a valid mechListMIC, the negotiation must fail as if the last context establishment token was invalid. 5. EXAMPLES : SECURITY MECHANISM NEGOTIATION Follow some examples of security mechanism options negotiation between an initiator (I) and a target (T). 5.1. Initial steps (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. (I) invokes GSS_Init_sec_context() with : Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism. Output major_status = GSS_CONTINUE_NEEDED output_token = negTokenInit The negotiation token (negTokenInit) contains three security mechanisms with : mechType = GSS-MECH1 or mechType = GSS-MECH2-OPTION1 or mechType = GSS-MECH2-OPTION2 (I) sends to (T) the negotiation token. 5.2 Successful negotiation steps (T) supports GSS-MECH2-OPTION1. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with : Baize, Pinkas Document Expiration: 22 October 1997 [Page 8] Internet-Draft April 22, 1997 Input input_token = negTokenInit Output major_status = GSS_CONTINUE_NEEDED output_token = negTokenTarg The negotiation token (negTokenTarg) contains : negResult = accept (the negotiation result) supportedMech : mechType = GSS-MECH2-OPTION1 (T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with : Input input_token = negTokenTarg Output major_status = GSS_COMPLETE output_token = initialContextToken (initial context token for GSS-MECH2-OPTION1) mech_type = GSS-MECH2-OPTION1 The subsequent steps are security mechanism specific, and work as specified in [1]. The output tokens from the security mechanism are encapsulated in a NegTokenTarg message (with the supportedMech and MechSpecInfo fields omitted, and the mechListMIC included with the last token). 5.3. Failed negotiation steps (T) supports GSS-MECH3. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with : Input input_token = negTokenInit Output major_status = GSS_S_BAD_MECH output_token = negTokenTarg The negotiation token (negTokenTarg) contains : negResult = reject (the negotiation result) (T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with : Input input_token = negTokenTarg Baize, Pinkas Document Expiration: 22 October 1997 [Page 9] Internet-Draft April 22, 1997 Output major_status = GSS_S_BAD_MECH The security context establishment has failed. 5.4 Successful Negotiation with preferred mechanism info (I) supports two security mechanism types (GSS-MECH1 and GSS-MECH2), and two options for GSS-MECH2 : OPTION1, identified by GSS-MECH2- OPTION1 and OPTION2, identified by GSS-MECH2-OPTION2. (I) invokes GSS_Init_sec_context() with : Input mech_type = OID for negotiation mechanism or NULL, if the negotiation mechanism is the default mechanism. Output major_status = GSS_CONTINUE_NEEDED output_token = negTokenInit The negotiation token (negTokenInit) contains three security mechanisms with : mechType = GSS-MECH1 or mechType = GSS-MECH2-OPTION1 or mechType = GSS-MECH2-OPTION2 preferredToken = output_token from GSS_Init_sec_context ( first mechType) as described in [1] (I) sends to (T) the negotiation token. (T) supports GSS-MECH1. (T) receives the negotiation token (negTokenInit) from (I) (T) invokes GSS_Accept_sec_context() with : Input input_token = negTokenInit Output major_status = GSS_CONTINUE_NEEDED output_token = negTokenTarg The negotiation token (negTokenTarg) contains : negResult = accept (the negotiation result) supportedMech : mechType = GSS-MECH1 MechSpecInfo = mechanism specific information for the preferred mechanism preferredToken = output_token from GSS_Accept_sec_context(preferredToken ) Baize, Pinkas Document Expiration: 22 October 1997 [Page 10] Internet-Draft April 22, 1997 (T) returns the negotiation token (negTokenTarg) to (I) (I) invokes GSS_Init_sec_context() with : Input input_token = negTokenTarg Output major_status = GSS_COMPLETE or GSS_CONTINUE_NEEDED as needed output_token = ContextToken (initial or subsequent context token for GSS-MECH1) mech_type = GSS-MECH1 Specific implementations of the protocol can support the optimistic negotiation by completing the security context establishment using the agreed upon mechanism as described in [1]. As described above in section 5.2, the output tokens from the security mechanism are encapsulated in a NegTokenTarg message (with the negResult, supportedMech and MechSpecInfo fields omitted, and the mechListMIC included with the last token). 6. ACKNOWLEDGMENTS Acknowledgments are due to Piers McMahon and Tom Parker of ICL, Stephen Farrell of SSE, Doug Rosenthal of EINet and John Linn of Openvision for reviewing earlier versions of this document and for providing useful inputs. Acknowledgments are also due to Peter Brundrett of Microsoft for his proposal for an optimistic negotiation, and for Bill Sommerfeld of Hewlett-Packard for his proposal for protecting the negotiation. 7. SECURITY CONSIDERATIONS The purpose of the generic simple GSS-API mechanism negotiation mechanism is to enable peers to agree on the value for a security mechanism and security related options required for initialising security services. When the mechanism selected by the target from the list supplied by the initiator supports integrity protection, then the negotiation is protected. When one of the mechanisms proposed by the initiator does not support integrity protection, then the negotiation is exposed to all threats a non secured service is exposed. In particular, an active attacker can force to use a security mechanism which is not the common preferred one (when multiple security mechanisms are shared between peers) but which is acceptable anyway to the target. In any case, the communicating peers may be exposed to the denial of service threat. Baize, Pinkas Document Expiration: 22 October 1997 [Page 11] Internet-Draft April 22, 1997 APPENDIX A GSS-API NEGOTIATION SUPPORT API In order to provide to a GSS-API caller (either the initiator or the target or both) the ability to choose among the set of supported mechanisms a reduced set of mechanisms for negotiation, two additional APIs are defined: GSS_Get_neg_mechs() indicates the set of security mechanisms available on the local system to the caller for negotiation. GSS_Set_neg_mechs() specifies the set of security mechanisms to be used on the local system by the caller for negotiation. A.1. GSS_Get_neg_mechs call Input: cred_handle OCTET STRING - NULL specifies default credentials Outputs: major_status INTEGER, minor_status INTEGER, mech_option_set SET OF OBJECT IDENTIFIER Return major_status codes : GSS_COMPLETE indicates that the set of security mechanism options available for negotiation has been returned in mech_option_set. GSS_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level. Allows callers to determine the set of security mechanism options available for negotiation. This call is intended for support of specialised callers who need to reduce the set of negotiable security mechanism options from the set of supported security mechanisms available to the caller (based on available credentials). Note: The GSS_Indicate_mechs() function indicates the full set of mechanism types available on the local system. Since this call does not use a credential handle as an input parameter, the returned set is not necessarily available for all credentials. Baize, Pinkas Document Expiration: 22 October 1997 [Page 12] Internet-Draft April 22, 1997 A.2. GSS_Set_neg_mechs call Input: cred_handle OCTET STRING - NULL specifies default credentials mech_option_set SET OF OBJECT IDENTIFIER Outputs: major_status INTEGER, minor_status INTEGER, Return major_status codes : GSS_COMPLETE indicates that the set of security mechanisms available for negotiation has been set to mech_option_set. GSS_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level. Allows callers to specify the set of security mechanism options that may be negotiated with a particular credential: A NULL mech_option_set specifies that only the default mech_type with the default option is available for the GSS-API implementation. This call is intended for support of specialised callers who need to restrict the set of negotiable security mechanism options from the set of all security mechanism options available to the caller (based on available credentials). Note that if more than one mechanism is specified in mech_option_set, the order in which those mechanisms are specified implies a relative mechanism preference for the target. REFERENCES [1] Linn, J., "Generic Security Service Application Program Interface", RFC 2078, OpenVision, January 1997. Available on ftp://ds.internic.net/rfc/rfc2078.txt [2] Standard ECMA-206, "Association Context Management including Security Context Management", December 1993. Available on http://www.ecma.ch AUTHORS'S ADDRESSES Eric Baize Internet email: E.Baize@ma02.bull.com Bull HN - MA02/211S Phone: +1 508 294 61 37 Technology Park Fax: +1 508 294 61 09 Billerica, MA 01821 - USA Denis Pinkas Internet email: D.Pinkas@frcl.bull.fr Bull Phone: +33 1 30 80 34 87 Rue Jean-Jaures Fax: +33 1 30 80 33 21 BP 68 78340 Les Clayes-sous-Bois - FRANCE Baize, Pinkas Document Expiration: 22 October 1997 [Page 13]