📄 rfc2478.txt
字号:
Network Working Group E. BaizeRequest for Comments: 2478 D. PinkasCategory: Standards Track Bull December 1998 The Simple and Protected GSS-API Negotiation MechanismStatus of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved.1. ABSTRACT This 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. This allows to negotiate different security mechanisms, different options within a given security mechanism or different options from several security mechanisms.Baize & Pinkas Standards Track [Page 1] RFC 2478 GSS-API Negotiation Mechanism December 1998 Once the common security mechanism is identified, the security mechanism may also negotiate mechanism-specific options during its context establishment. This will be inside the mechanism tokens, and invisible to the SPNEGO protocol. The simple and protected GSS-API mechanism negotiation is based on the following negotiation model : the initiator proposes one security mechanism or an ordered list of 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 then informs the initiator of its choice. 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. The Simple and Protected GSS-API Negotiation Mechanism uses the concepts developed in the GSS-API specification [1]. The negotiation data is encapsulated in context-level tokens. Therefore, 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.Baize & Pinkas Standards Track [Page 2] RFC 2478 GSS-API Negotiation Mechanism December 19982. NEGOTIATION MODEL2.1. Negotiation description The model for security mechanism negotiation reuses a subset of the concepts specified in [2]. Each OID represents one GSS-API mechanism or one variant of it. - When one security mechanism is proposed by the initiator, it represents the only security mechanism 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, a set of options (e.g. deleg, replay, conf flags) that should be supported by the selected mechanism 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_completed, accept_incomplete or reject) and, in case of accept, the agreed security mechanism. It may also include the response to the initial security token from the initiator, when the first proposed mechanism of the initiator has been selected. When the first mechanism is acceptable to the target,it should respond to the initial security token for the desired mechanism of the initiator when it is present. However, if this is not possible, the target can simply ignore it and omit the responseToken from the first reply. 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 policy by which the target chooses a mechanism is an implementation-specific local matter. In the absence of other policy, the target should chose the first mechanism in the list for which valid credentials are available. Once a mechanism has been selected, the tokens specific to the selected mechanism are carried within the negotiation tokens (in the mechToken for the initiator and in the responseToken for the target).Baize & Pinkas Standards Track [Page 3] RFC 2478 GSS-API Negotiation Mechanism December 19982.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 a list of supported security mechanisms for the credentials used for this context establishment, and optionally an initial security token for the first mechanism from that list (i.e. the preferred mechanism), and indicates GSS_S_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 mechanism selected by the target matches the preferred mechanism identified by the initiator and the initiator provides a mechToken, the negotiation token response may contain also an initial security token from that mechanism. If the preferred mechanism is accepted, GSS_Accept_sec_context() indicates GSS_S_COMPLETE when unilateral or mutual authentication has been performed and involves a single token in either direction. If a proposed mechanism is accepted, and it was not the preferred mechanism, or if the first negotiation token sent by the initiator did not included a mechToken, then the negotiation token response sent by the target may contain also a response token from that mechanism which transmits mechanism-specific information (e.g. to transmit a certificate). The initiator may ignore such an initial token if it is not prepared to process it. If a proposed mechanism other than the preferred mechanism is accepted, or the preferred mechanism is accepted but involves multiple exchanges (e.g. challenge-response authentication), then GSS_Accept_sec_context() indicates GSS_S_CONTINUE_NEEDED status.Baize & Pinkas Standards Track [Page 4] RFC 2478 GSS-API Negotiation Mechanism December 1998 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_S_CONTINUE_NEEDED, GSS_S_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. The GSS_S_BAD_MIC status is returned when the 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). Upon failure of the mechanism negotiation procedure, the mech_type output parameter value is the negotiation mechanism type. The GSS_S_CONTINUE_NEEDED status is returned when the negotiation token carries an accept result and further tokens must be transferred in order to complete context establishment for the selected mechanism. In that case GSS_Init_sec_context() returns an initial context token as output_token (with the selected mechanism's context token encapsulated within that 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_S_COMPLETE is returned for both the initiator and the target. When GSS_S_CONTINUE_NEEDED is returned, the mech_type output parameter is not yet valid. When GSS_S_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 is on the originallyBaize & Pinkas Standards Track [Page 5] RFC 2478 GSS-API Negotiation Mechanism December 1998 submitted list of mechanisms 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 need to know when the negotiation exchanges were protected or not. For this, when GSS_S_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_S_BAD_MECH 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).3. DATA ELEMENTS3.1. Mechanism Type MechType::= OBJECT IDENTIFIER mechType Each security mechanism is as defined in [1].3.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).Baize & Pinkas Standards Track [Page 6]⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -