+++ /dev/null
-\r
-\r
-NETWORK WORKING GROUP L. Zhu\r
-Internet-Draft K. Damour\r
-Updates: 4178 (if approved) D. McPherson\r
-Intended status: Informational Microsoft Corporation\r
-Expires: January 15, 2009 July 14, 2008\r
-\r
-\r
- The Extended GSS-API Negotiation Mechanism (NEGOEX)\r
- draft-zhu-negoex-01\r
-\r
-Status of this Memo\r
-\r
- By submitting this Internet-Draft, each author represents that any\r
- applicable patent or other IPR claims of which he or she is aware\r
- have been or will be disclosed, and any of which he or she becomes\r
- aware will be disclosed, in accordance with Section 6 of BCP 79.\r
-\r
- Internet-Drafts are working documents of the Internet Engineering\r
- Task Force (IETF), its areas, and its working groups. Note that\r
- other groups may also distribute working documents as Internet-\r
- Drafts.\r
-\r
- Internet-Drafts are draft documents valid for a maximum of six months\r
- and may be updated, replaced, or obsoleted by other documents at any\r
- time. It is inappropriate to use Internet-Drafts as reference\r
- material or to cite them other than as "work in progress."\r
-\r
- The list of current Internet-Drafts can be accessed at\r
- http://www.ietf.org/ietf/1id-abstracts.txt.\r
-\r
- The list of Internet-Draft Shadow Directories can be accessed at\r
- http://www.ietf.org/shadow.html.\r
-\r
- This Internet-Draft will expire on January 15, 2009.\r
-\r
-Abstract\r
-\r
- This document defines the Extended Generic Security Service\r
- Application Program Interface (GSS-API) Negotiation Mechanism\r
- (NegoEx). NegoEx is a pseudo-security mechanism that logically\r
- extends the SPNEGO protocol as defined in RFC4178.\r
-\r
- The NegoEx protocol itself is a security mechanism negotiated by\r
- SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY\r
- adds a pair of meta-data messages for each negotiated security\r
- mechanism. The meta-data exchange allows security mechanisms to\r
- exchange auxiliary information such as trust configurations, thus\r
- NegoEx provides additional flexibility than just exchanging object\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 1]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- identifiers in SPNEGO.\r
-\r
- NegoEx preserves the optimistic token semantics of SPNEGO and applies\r
- that recursively. Consequently a context establishment mechanism\r
- token can be included in the initial NegoEx message, and NegoEx does\r
- not require an extra round-trip when the initiator's optimistic token\r
- is accepted by the target.\r
-\r
- Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a\r
- security mechanism MUST support in order to be negotiated by NegoEx.\r
- This document defines these GSS-API extensions.\r
-\r
- Unlike SPNEGO however, NegoEx defines its own way for signing the\r
- protocol messages in order to protect the protocol negotiation. The\r
- NegoEx message signing or verification can occur before the security\r
- context for the negotiated real security mechanism is fully\r
- established.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 2]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
-Table of Contents\r
-\r
- 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4\r
- 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6\r
- 3. Presentation Language and Primitive Data Types . . . . . . . . 6\r
- 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . . 7\r
- 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 7\r
- 3.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 7\r
- 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 7\r
- 3.5. Enum Types . . . . . . . . . . . . . . . . . . . . . . . . 7\r
- 3.6. Typedef Declarations . . . . . . . . . . . . . . . . . . . 8\r
- 3.7. Array Types . . . . . . . . . . . . . . . . . . . . . . . 8\r
- 3.8. Vector Types . . . . . . . . . . . . . . . . . . . . . . . 8\r
- 3.9. Constructed Types . . . . . . . . . . . . . . . . . . . . 9\r
- 4. Cryptographic Computations . . . . . . . . . . . . . . . . . . 10\r
- 5. The NegoEx Protocol . . . . . . . . . . . . . . . . . . . . . 11\r
- 5.1. Generation of the Initiator Initial Token . . . . . . . . 11\r
- 5.2. Receipt of the Initial Initiator Token and Generation\r
- of the Initial Acceptor Response . . . . . . . . . . . . . 13\r
- 5.3. Receipt of the Acceptor Initial Response and\r
- Completion of Authentication after the Negotiation\r
- Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 14\r
- 5.4. Finalizing Negotiation . . . . . . . . . . . . . . . . . . 15\r
- 5.5. High-level NegoEx Message Flow . . . . . . . . . . . . . . 15\r
- 6. Supporting GSS-API Extensions . . . . . . . . . . . . . . . . 16\r
- 6.1. GSS_Query_meta_data . . . . . . . . . . . . . . . . . . . 16\r
- 6.2. GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 16\r
- 6.3. GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 16\r
- 6.4. GSS_Query_context_attr . . . . . . . . . . . . . . . . . . 16\r
- 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16\r
- 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17\r
- 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17\r
- 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17\r
- Appendix A. Protocol Data Structures and Constant Values . . . . 17\r
- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21\r
- Intellectual Property and Copyright Statements . . . . . . . . . . 22\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 3]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
-1. Introduction\r
-\r
- If more than one GSS-API mechanism is shared between the initator and\r
- the acceptor, the Simple and Protected (GSS-API) Negotiation\r
- Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose\r
- a mutually preferred one. This pseudo mechanism does well in the\r
- most basic scenarios but suffers from a couple of drawbacks, notably:\r
-\r
- o First, the SPNEGO negotiation model is inefficient when\r
- negotiating based on mechanism specific configuration information.\r
- SPNEGO negotiation is based on exchanging object identifiers only,\r
- and it does not allow exchange of auxiliary information in any\r
- other from. This is inefficient and often impractical in that one\r
- object identifier effectively conveys only one bit of information.\r
-\r
- o Secondly, the SPNEGO negotiation model is inadequate when the\r
- choice cannot be made by the acceptor in the initial response. In\r
- SPNEGO, the negotiation information is sent one-way from the\r
- initiator for the acceptor to make a choice, and the acceptor must\r
- choose one when it makes the initial response. This negotiation\r
- model is counter intuitive. The selection of a security mechanism\r
- is typically the result of selecting one type of credentials from\r
- the available set, and the initiator typically does not wish to\r
- reveal credentials information often associated with user\r
- identities. In practice, in order to operate in this model, the\r
- Kerberos GSS-API mechanism [RFC4121] must acquire the context\r
- establishment token in the initial call to GSS_Init_sec_context().\r
- If the initiator fails to acquire the initial Kerberos GSS-API\r
- context token, it must not offer Kerberos; otherwise the SPNEGO\r
- context negotiation will fail without being able to select the\r
- next available mechanism that could work. Obtaining the initial\r
- Kerberos GSS-API context token may require multiple round-trips of\r
- network calls and the cost of the operation can be substantial.\r
- It is suboptimal when multiple GSS-API mechanisms have to add the\r
- extra cost that would not exist if the negotiated security\r
- mechanism were selected based on configuration.\r
-\r
- The Extended Generic Security Service Application Program Interface\r
- (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these\r
- concerns. NegoEx is a pseudo security mechanism that is negotiated\r
- by SPNEGO, and when negotiated, it can recursively negotiate real\r
- security mechanisms.\r
-\r
- Any security mechanism negotiated by NegoEx MUST support integrity\r
- protection.\r
-\r
- The basic form of NegoEx works as follows:\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 4]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- 1. The initiator proposes a list of mechanisms in decreasing\r
- preference order. For each of these mechanism, NegoEx\r
- OPTIOINALLY includes a mechanism specific meta-data token. GSS-\r
- API extensions are defined later in this document for NegoEx to\r
- query the meta-data token for inclusion in the NegoEx message.\r
-\r
- 2. The acceptor then passes the meta-data token from the initiator\r
- to the intended security mechanism. A meta-data token for a\r
- security mechanism not supported on the acceptor side is ignored.\r
- New GSS-API extensions are defined later in this document for a\r
- security mechanism to consume the meta-data token. When\r
- processing the received meta-data tokens, a security mechanism\r
- that reports a failure is removed from the set of mutually\r
- supported mechanisms. The acceptor then responds with the list\r
- of mutually supported mechanisms in decreasing preference order.\r
- For each of these mechanism, NegoEx again OPTIOINALLY supplies a\r
- mechanism specific meta-data token in the response. These meta-\r
- data tokens are returned to NegoEx via new GSS-API extensions as\r
- described in the initial step.\r
-\r
- 3. The initiator then passes the meta-data tokens to the intended\r
- security mechanisms by invoking the new GSS-API extensions. When\r
- processing the received meta-data token, a security mechanism\r
- that reports a failure is removed from the set of mutually\r
- supported mechanisms for this negotiation context. The initiator\r
- then selects one from the set of mutually-supported mechanisms.\r
- If more than one security mechanism is available, unless\r
- otherwise specified, the preferred one in the acceptor's\r
- preference order SHOULD be selected. Once the common security\r
- mechanism is identified, the security mechanism may also\r
- negotiate mechanism-specific options during its context\r
- establishments. This will be inside the mechanism tokens, and\r
- invisible to the NegoEx protocol.\r
-\r
- 4. The selected security mechanism provides keying materials to\r
- NegoEx, and NegoEx then signs and verifies the negotiation NegoEx\r
- messages to protect the negotiation.\r
-\r
- 5. The initiator and the acceptor proceed to exchange tokens until\r
- the GSS-API context for selected security mechanism is\r
- established. Once the security context is established, the per-\r
- message tokens are generated and verified in accordance with the\r
- selected security mechanism.\r
-\r
- NegoEx does not work outside of SPNEGO. When negotiated by SPNEGO,\r
- NegoEx uses the concepts developed in the GSS-API specification\r
- [RFC2743]. The negotiation data is encapsulated in context-level\r
- tokens. Therefore, callers of the GSS-API do not need to be aware of\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 5]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- the existence of the negotiation tokens but only of the SPENGO\r
- pseudo-security mechanism.\r
-\r
- In its basic form NegoEx requires at least one extra round-trip.\r
- Network connection setup is a critical performance characteristic of\r
- any network infrastructure and extra round trips over WAN links,\r
- packet radio networks, etc. really make a difference. In order to\r
- avoid such an extra round trip the initial security token of the\r
- preferred mechanism for the initiator may be embedded in the initial\r
- NegoEx token. The optimistic mechanism token may be accompanied by\r
- the meta-data tokens and the optimistic mechanism token MUST be that\r
- of the first mechanism in the list of the mechanisms proposed by the\r
- initiator. The NegoEx message that contains signatures for\r
- protecting the NegoEx negotiation can also be included along with the\r
- mechanism token. If the target preferred mechanism matches the\r
- initiator's preferred mechanism, and when the NegoEx negotiation\r
- protection messages are included along with the mechanism token, no\r
- additional round trips are incurred by using the NegoEx protocol with\r
- SPNEGO.\r
-\r
- NegoEx does not update the ASN.1 structures of SPNEGO in that a large\r
- deployment of SPNEGO does not have the ASN.1 extensibility marker in\r
- the message definition. There is no change to the SPNEGO messages.\r
-\r
- NegoEx does not use ASN.1 encoding and it uses simple C structures\r
- encoded in little endian for all its messages.\r
-\r
- The rest of the document is organized as follows: Section 3 defines\r
- the encoding of NegoEx data structures and all the primitive data\r
- types. Section 4 describes the cryptographic framework required by\r
- the NegoEx for protecting the NegoEx negotiation. Section 5 defines\r
- the NegoEx messages and the NegoEx protocol. Section 6 defines the\r
- new GSS-API extensions that a security mechanism MUST support in\r
- order to be negotiated by NegoEx. These then are followed by the\r
- security considerations section. Lastly Appendix A contains all the\r
- protocol constructs and constants.\r
-\r
-\r
-2. Requirements Terminology\r
-\r
- The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
- "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
- document are to be interpreted as described in [RFC2119].\r
-\r
-\r
-3. Presentation Language and Primitive Data Types\r
-\r
- The following very basic and somewhat casually defined presentation\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 6]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- syntax will be used in all NegoEx messages. Although it resembles\r
- the programming language "C" in its syntax, it would be risky to draw\r
- too many parallels. The purpose of this presentation language is to\r
- document NegoEx only; it has no general application beyond that\r
- particular goal.\r
-\r
- This section also defines all the primitive data types. The\r
- semantics of the data types is explained in the next section.\r
-\r
-3.1. Basic Block Size\r
-\r
- The representation of all data items is explicitly specified. The\r
- basic data block size is one octet. Multiple octet data items are\r
- concatenations of octets, from left to right, from top to bottom\r
- Unless otherwise specific a multi-octet numeric is in little endian\r
- order with the least significant octet first.\r
-\r
-3.2. Miscellaneous\r
-\r
- Comments start with "//"' and continue until the end of the line.\r
-\r
-3.3. Constants\r
-\r
- Constants are denoted using "#define" followed by the symbolic name\r
- and then the constant value.\r
-\r
-3.4. Numbers\r
-\r
- UCHAR is the data type for a one-octet number.\r
-\r
- ULONG is the data type for a 4-octet number encoded in little enidan.\r
-\r
- USHORT is the data type for a 2-octet number encoded in little\r
- endian.\r
-\r
- ULONG64 is the data type for a 8-octet number encoded in little\r
- endian.\r
-\r
- GUID is the data type for a 16-octet number encoded in little endian.\r
-\r
-3.5. Enum Types\r
-\r
- An enum type is the data type for a number with a small number of\r
- permissible values. An instance of an enum type is a 4-octet number\r
- encoded in little endian.\r
-\r
- The definition of an enum type follows the simple "C" convention.\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 7]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- MESSAGE_TYPE is an enum type defined as follows:\r
-\r
- enum\r
- {\r
- MESSAGE_TYPE_INITIATOR_NEGO = 0,\r
- MESSAGE_TYPE_ACCEPTOR_NEGO,\r
- MESSAGE_TYPE_INITIATOR_META_DATA,\r
- MESSAGE_TYPE_ACCEPTOR_META_DATA,\r
- MESSAGE_TYPE_CHALLENGE,\r
- // an exchange message from the acceptor\r
- MESSAGE_TYPE_AP_REQUEST,\r
- // an exchange message from the initiator\r
- MESSAGE_TYPE_VERIFY,\r
- MESSAGE_TYPE_ALERT,\r
- } MESSAGE_TYPE;\r
-\r
- MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT\r
- has the value 7.\r
-\r
-3.6. Typedef Declarations\r
-\r
- A typedef creates a synonym for the type. This is used to create\r
- more meaningful names for existing types.\r
-\r
- The following two type synonyms are defined.\r
-\r
- typedef GUID AUTH_SCHEME;\r
- typedef GUID CONVERSATION_ID;\r
-\r
-3.7. Array Types\r
-\r
- Arrays are a data structure which holds multiple variables of the\r
- same data type consecutively and the number of elements is fixed. An\r
- array is declared using "C" convention. For example, the following\r
- defines an array of 32 octets.\r
-\r
- UCHAR Random[32];\r
-\r
-3.8. Vector Types\r
-\r
- Vectors are a data structure which holds multiple variables of the\r
- same data type consecutively and the number of elements is not fixed.\r
- A vector contains a fixed length header followed by a variable length\r
- payload. The header of a vector structure contains the count of\r
- elements and the offset to the payload. In this document all the\r
- offset fields start from the beginning of the containing NegoEx\r
- message. The size of each element is specified by the vector type\r
- definition.\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 8]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- The following vector types are defined.\r
-\r
- struct\r
- {\r
- ULONG ByteArrayOffset; // each element contains an octet/byte\r
- ULONG ByteArrayLength;\r
- } BYTE_VECTOR;\r
-\r
- BYTE_VECTOR encapsulates a variable length array of octets (or bytes)\r
- that are stored consecutively. Each element in is a byte (8 bits).\r
-\r
- struct\r
- {\r
- ULONG AuthSchemeArrayOffset;\r
- // each element contains an AUTH_SCHEME\r
- USHORT AuthSchemeCount;\r
- } AUTH_SCHEME_VECTOR;\r
-\r
- AUTH_SCHEME_VECTOR encapsulates a variable length array of\r
- AUTH_SCHEMEs that are stored consecutively. Each element is a\r
- structure of the type AUTH_SCHEME.\r
-\r
- struct\r
- {\r
- ULONG ExtensionArrayOffset;\r
- // each element contains an EXTENSION\r
- USHORT ExtensionCount;\r
- } EXTENSION_VECTOR;\r
-\r
- EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs\r
- that are stored consecutively. Each element is a structure of the\r
- type EXTENSION.\r
-\r
-3.9. Constructed Types\r
-\r
- Structure types may be constructed from primitive types for\r
- convenience. Each specification declares a new, unique type. The\r
- syntax for definition is much like that of C.\r
-\r
- struct {\r
- T1 f1;\r
- T2 f2;\r
- ...\r
- Tn fn;\r
- } T;\r
-\r
-\r
- Structure definitions may be embedded.\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 9]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- The following types are defined as constructed types:\r
-\r
- struct\r
- {\r
- ULONG ExtensionType; // negative extensions are critical\r
- BYTE_VECTOR ExtensionValue;\r
- } EXTENSION;\r
-\r
- An extension has two fields. The ExtensionType field indicates how\r
- the extension data should be interpreted. The ExtensionValue field\r
- contains the extension data.\r
-\r
- //\r
- // schemes defined for the checksum in the VERIFY message\r
- //\r
-\r
- struct\r
- {\r
- ULONG cbHeaderLength;\r
- ULONG ChecksumScheme;\r
- ULONG ChecksumType; // in the case of RFC3961 scheme, this is\r
- // the RFC3961 checksum type\r
- BYTE_VECTOR ChecksumValue;\r
- } CHECKSUM;\r
-\r
- The CHECKSUM structure contains 4 fields. The cbHeaderLength length\r
- contains the length of the structure defintion in octets, and this\r
- field has a value of 20.\r
-\r
- The ChecksumScheme field describes how checksum is computed and\r
- verified. Currently only one value is defined.\r
-\r
- #define CHECKSUM_SCHEME_RFC3961 1\r
-\r
- When the value of the ChecksumScheme field is 1\r
- (CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a\r
- sequence of octets computed according to [RFC3961] and the\r
- ChecksumType field contains the checksum type value defined according\r
- to [RFC3961].\r
-\r
-\r
-4. Cryptographic Computations\r
-\r
- The message signing and verification in NegoEx is based on [RFC3961].\r
- [RFC3961] is used here as a generic framework and this application is\r
- not Kerberos specific.\r
-\r
- A security mechanism MUST support [RFC3961] in order to be negotiated\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 10]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- by NegoEx.\r
-\r
-\r
-5. The NegoEx Protocol\r
-\r
- This section describes the NegoEx protocol and it defines NegoEx\r
- messages in the order that the messages can appear on the wire. The\r
- enum type MESSAGE_TYPE defined in Section 3.5 lists all NegoEx\r
- message types. A GSS-API context token for NegoEx consists of one or\r
- more NegoEx messages. If there are more than one NegoEx message,\r
- these messages are concatenated together. The smallest data unit for\r
- NegoEx to compute the checksum for negotiation protection is a NegoEx\r
- message. Note that NegoEx is not a GSS-API mechanism itself and the\r
- initial NegoEx context establishment token does not follow the\r
- mechanism-independent token format defined in Section 3.1 of\r
- [RFC2743].\r
-\r
- A security mechanism negotiated by NegoEx is identified by a unique\r
- identifier of the data type AUTH_SCHEME defined in Section 3.5. The\r
- value of the security mechanism is returned to NegoEx via the\r
- GSS_Query_mechanism_info() GSS-API extension as defined in Section 6.\r
-\r
- The object identifier of the NegoEx within SPNEGO is iso(1)\r
- identified-organization(3) dod(6) internet(1) private(4)\r
- enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30).\r
- Note that NegoEx does not work outside of SPNEGO and it is not GSS-\r
- API mechanism.\r
-\r
-5.1. Generation of the Initiator Initial Token\r
-\r
- The GSS-API initiator makes the first call to GSS_Init_sec_context()\r
- with no input token, and the output token starts as a NEGO_MESSAGE\r
- message with the MESSAGE_TYPE_INITIATOR_NEGO message type.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 11]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- struct\r
- {\r
- ULONG64 Signature; // contains MESSAGE_SIGNATURE\r
- MESSAGE_TYPE MessageType;\r
- ULONG SequenceNum; // the message sequence number of this,\r
- // conversation, starting with 0 and sequentially\r
- // incremented\r
- ULONG cbHeaderLength; // the header length of this message,\r
- // including the message specific header, excluding the\r
- // payload\r
- ULONG cbMessageLength; // the length of this message\r
- CONVERSATION_ID ConversationId;\r
- } MESSAGE_HEADER;\r
-\r
- struct\r
- {\r
- MESSAGE_HEADER Header;\r
- // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,\r
- // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor\r
- UCHAR Random[32];\r
- ULONG64 ProtocolVersion;\r
- // version of the protocol, this contains 0\r
- AUTH_SCHEME_VECTOR AuthSchemes;\r
- EXTENSION_VECTOR Extensions;\r
- } NEGO_MESSAGE;\r
-\r
- The initiator randomly generates a ConversationID and fills the\r
- common header. The ConversationID in subsequent NegoEx messages MUST\r
- remain the same. The initiator also fills the Random field using a\r
- secure random number generator. The initiator fills the AuthSchemes\r
- with available security mechanisms supported by the initiator in\r
- decreasing preference order.\r
-\r
- The extensions field contains NegoEx extensions for future\r
- extensibility. There is no extension defined in this document. All\r
- negative extension types (the highest bit is set to 1) are critical.\r
- If the receiver does not understand a critical extension, the\r
- authentication attempt must be rejected.\r
-\r
- The initiator can OPTIONALLY include a meta-data token, one for each\r
- available security mechanism.\r
-\r
- A meta-data token is returned to NegoEx for a security mechanism\r
- using GSS_Query_meta_data() extension as defined in Section 6. A\r
- meta-data token is encapsulated in an EXCHANGE message with the\r
- message type MESSAGE_TYPE_INITIATOR_META_DATA.\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 12]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- struct\r
- {\r
- MESSAGE_HEADER Header;\r
- // MESSAGE_TYPE_CHALLENGE for the acceptor,\r
- // or MESSAGE_TYPE_AP_REQUEST for the initiator\r
- // MESSAGE_TYPE_INITIATOR_META_DATA for\r
- // the initiator metadata\r
- // MESSAGE_TYPE_ACCEPTOR_META_DATA for\r
- // the acceptor metadata\r
- AUTH_SCHEME AuthScheme;\r
- BYTE_VECTOR Exchange;\r
- // contains the opaque handshake message for the\r
- // authentication scheme\r
- } EXCHANGE_MESSAGE;\r
-\r
- The AuthScheme field signifies the security mechanism for which the\r
- EXCHANGE message is targeted. If a security mechanism fails to\r
- produce the metadata token, it should be removed from the list of\r
- supported security mechanism for this negotiation context.\r
-\r
- If there are more than one exchange messages, the order in which the\r
- exchange message is included bears no significance. In other words,\r
- the exchange messages are in an unordered set. The NEGO_MESSAGE MAY\r
- be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as\r
- described above, in which case all the NegoEx messages concatenated\r
- are returned as a single input token.\r
-\r
- The first mechanism in the initiator proposed list can OPTIONALLY\r
- include its initial context context in an AP_REQUEST message.\r
-\r
- Both an AP_REQUSET(short for MESSAGE_TYPE_AP_REQUEST) message and a\r
- INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA)\r
- message are instances of the EXCHANGE_MESSAGE structure with\r
- different message type values. An AP_REQUEST message contains the\r
- type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message\r
- contains the type MESSAGE_TYPE_INITIATOR_META_DATA.\r
-\r
-5.2. Receipt of the Initial Initiator Token and Generation of the\r
- Initial Acceptor Response\r
-\r
- Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor\r
- verifies the NEGO_MESSAGE to make sure it is well-formed. The\r
- acceptor then computes the list of authentication schemes that are\r
- mutually supported by examining the set of security mechanisms\r
- proposed by the initiator and the meta-data tokens from the\r
- initiator. The meta-data tokens are passed to the security mechanism\r
- via GSS_Exchange_meta_data() as defined in Section 6.\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 13]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- The acceptor MUST examine the NegoEx extensions in the NEGO_MESSAGE.\r
- If there is an unknown critical extension, the authentication must be\r
- rejected.\r
-\r
- The acceptor's response starts as a NEGO_MESSAGE but with the\r
- MESSAGE_TYPE_ACCEPTOR_NEGO. The AuthSchemes field contains the list\r
- of mutually supported security mechanism in decreasing preference\r
- order of the acceptor. The acceptor does not need to honor the\r
- preference order proposed by the initiator when computing its\r
- preference list.\r
-\r
- The acceptor can OPTIONALLY include a meta-data token, one for each\r
- available security mechanism.\r
-\r
- A meta-data token is returned to NegoEx for a security mechanism\r
- using GSS_Query_meta_data() extension as defined in Section 6. A\r
- meta-data token is encapsulated in an EXCHANGE message with the\r
- message type MESSAGE_TYPE_ACCEPTOR_META_DATA. For a given security\r
- mechanism if a meta-token is received from the initiator,\r
- GSS_Query_meta_data() MUST be invoked on the acceptor side for that\r
- security mechanism, and the output meta-data token, if present, MUST\r
- be included in the NegoEx reply.\r
-\r
-5.3. Receipt of the Acceptor Initial Response and Completion of\r
- Authentication after the Negotiation Phrase\r
-\r
- Upon receipt of the initial response from the acceptor, the initial\r
- verifies the NEGO_MESSAGE to make sure it is well-formed. The\r
- initiator then computes the list of authentication schemes that are\r
- mutually supported by examining the set of security mechanisms\r
- returned by the acceptor and the meta-data tokens from the acceptor\r
- The meta-data tokens are passed to the security mechanism via\r
- GSS_Exchange_meta_data() as defined in Section 6.\r
-\r
- The initiator MUST examine the NegoEx extensions in the NEGO_MESSAGE.\r
- If there is an unknown critical extension, the authentication must be\r
- rejected.\r
-\r
- After the initial exchange of NEGO_MESSAGE messages, the initiator\r
- MUST choose the negotiated security mechanism. The negotiated\r
- security mechanism cannot be changed once it is selected.\r
-\r
- The initiator and the acceptor can then proceed to exchange handshake\r
- messages as determined by the negotiated security mechanism until its\r
- authentication context is established. The context tokens of the\r
- negotiated security mechanism are encapsulated in an\r
- EXCHANGE_MESSAGE. If the context token is from the initiator, the\r
- EXCHANGE_MESSAGE message has the message type\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 14]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is\r
- MESSAGE_TYPE_CHALLENGE.\r
-\r
-5.4. Finalizing Negotiation\r
-\r
- Whenever there is a shared key established returned by\r
- GSS_Query_context_attr(NEGOEX_SESSION_KEYS) as defined in Section 6,,\r
- a VERIFY message is produced and included in the output token. The\r
- returned protocol key is used as the base key in the parlance of\r
- RFC3961 to sign all the NegoEx messages in the negotiation context.\r
-\r
- A VERIFY message is a VERIFY_MESSAGE structure. The AuthScheme field\r
- signifies from which security mechanism the protocol key was\r
- obtained. The checksum is computed based on RFC3961 and the key\r
- usage number is 23 for the message is signed by the initiator, 25\r
- otherwise. The checksum is performed over all the previous NegoEx\r
- messages in the context negotiation.\r
-\r
- struct\r
- {\r
- MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY\r
- AUTH_SCHEME AuthScheme;\r
- CHECKSUM Checksum;\r
- // contains the checksum of all the previously\r
- // exchanged messages in the order they were sent.\r
- } VERIFY_MESSAGE;\r
-\r
- Note that the VERIFY_MESSAGE message can be included before the\r
- security context for the negotiated security mechanism is fully\r
- established.\r
-\r
-5.5. High-level NegoEx Message Flow\r
-\r
- The following text art summarizes the protocol message flow:\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 15]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- INITIATOR_NEGO\r
- *INITIATOR_META_DATA\r
- *AP_REQUEST\r
- --------->\r
- ACCEPTOR_NEGO\r
- ACCEPTOR_META_DATA*+\r
- --------- CHALLENGE*\r
-\r
- .\r
- .\r
- *AP_REQUEST\r
- VERIFY --------->\r
- CHALLENGE*\r
- -------- VERIFY\r
- * Indicates optional or situation-dependent messages that are\r
- not always sent.\r
- + Indicates there can be more than one instance.\r
-\r
-\r
-6. Supporting GSS-API Extensions\r
-\r
- This section defined all the required GSS-API extensions required by\r
- NegoEx.\r
-\r
-6.1. GSS_Query_meta_data\r
-\r
- TBD.\r
-\r
-6.2. GSS_Exchange_meta_data\r
-\r
- TBD.\r
-\r
-6.3. GSS_Query_mechanism_info\r
-\r
- TBD.\r
-\r
-6.4. GSS_Query_context_attr\r
-\r
- TBD.\r
-\r
-\r
-7. Security Considerations\r
-\r
- TBD.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 16]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
-8. Acknowledgements\r
-\r
- TBD.\r
-\r
-\r
-9. IANA Considerations\r
-\r
- There is no action required for IANA.\r
-\r
-\r
-10. Normative References\r
-\r
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
- Requirement Levels", BCP 14, RFC 2119, March 1997.\r
-\r
- [RFC2743] Linn, J., "Generic Security Service Application Program\r
- Interface Version 2, Update 1", RFC 2743, January 2000.\r
-\r
- [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for\r
- Kerberos 5", RFC 3961, February 2005.\r
-\r
- [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The\r
- Kerberos Network Authentication Service (V5)", RFC 4120,\r
- July 2005.\r
-\r
- [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos\r
- Version 5 Generic Security Service Application Program\r
- Interface (GSS-API) Mechanism: Version 2", RFC 4121,\r
- July 2005.\r
-\r
- [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The\r
- Simple and Protected Generic Security Service Application\r
- Program Interface (GSS-API) Negotiation Mechanism",\r
- RFC 4178, October 2005.\r
-\r
-\r
-Appendix A. Protocol Data Structures and Constant Values\r
-\r
- This section complies all the protocol data structures and constant\r
- values.\r
-\r
- #define MESSAGE_SIGNATURE 0x535458454f47454ei64\r
- // "NEGOEXTS"\r
-\r
- struct\r
- {\r
- ULONG ByteArrayOffset; // each element contains a byte\r
- ULONG ByteArrayLength;\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 17]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- } BYTE_VECTOR;\r
-\r
- struct\r
- {\r
- ULONG AuthSchemeArrayOffset;\r
- // each element contains an AUTH_SCHEME\r
- USHORT AuthSchemeCount;\r
- } AUTH_SCHEME_VECTOR;\r
-\r
- struct\r
- {\r
- ULONG ExtensionArrayOffset;\r
- // each element contains an EXTENSION\r
- USHORT ExtensionCount;\r
- } EXTENSION_VECTOR;\r
-\r
- struct\r
- {\r
- ULONG ExtensionType; // negative extensions are critical\r
- BYTE_VECTOR ExtensionValue;\r
- } EXTENSION;\r
-\r
- //\r
- // schemes defined for the checksum in the VERIFY message\r
- //\r
-\r
- #define CHECKSUM_SCHEME_RFC3961 1\r
-\r
- struct\r
- {\r
- ULONG cbHeaderLength;\r
- ULONG ChecksumScheme;\r
- ULONG ChecksumType; // in the case of RFC3961 scheme, this is\r
- // the RFC3961 checksum type\r
- BYTE_VECTOR ChecksumValue;\r
- } CHECKSUM;\r
-\r
- typedef GUID AUTH_SCHEME;\r
- typedef GUID CONVERSATION_ID;\r
-\r
- enum\r
- {\r
- MESSAGE_TYPE_INITIATOR_NEGO = 0,\r
- MESSAGE_TYPE_ACCEPTOR_NEGO,\r
- MESSAGE_TYPE_INITIATOR_META_DATA,\r
- MESSAGE_TYPE_ACCEPTOR_META_DATA,\r
- MESSAGE_TYPE_CHALLENGE,\r
- // an exchange message from the acceptor\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 18]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- MESSAGE_TYPE_AP_REQUEST,\r
- // an exchange message from the initiator\r
- MESSAGE_TYPE_VERIFY,\r
- MESSAGE_TYPE_ALERT,\r
- } MESSAGE_TYPE;\r
-\r
- struct\r
- {\r
- ULONG64 Signature; // contains MESSAGE_SIGNATURE\r
- MESSAGE_TYPE MessageType;\r
- ULONG SequenceNum; // the message sequence number of this,\r
- // conversation, starting with 0 and sequentially\r
- // incremented\r
- ULONG cbHeaderLength; // the header length of this message,\r
- // including the message specific header, excluding the\r
- // payload\r
- ULONG cbMessageLength; // the length of this message\r
- CONVERSATION_ID ConversationId;\r
- } MESSAGE_HEADER;\r
-\r
- struct\r
- {\r
- MESSAGE_HEADER Header;\r
- // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,\r
- // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor\r
- UCHAR Random[32];\r
- ULONG64 ProtocolVersion;\r
- // version of the protocol, this contains 0\r
- AUTH_SCHEME_VECTOR AuthSchemes;\r
- EXTENSION_VECTOR Extensions;\r
- } NEGO_MESSAGE;\r
-\r
- struct\r
- {\r
- MESSAGE_HEADER Header;\r
- // MESSAGE_TYPE_CHALLENGE for the acceptor,\r
- // or MESSAGE_TYPE_AP_REQUEST for the initiator\r
- // MESSAGE_TYPE_INITiATOR_META_DATA for\r
- // the initiator metadata\r
- // MESSAGE_TYPE_ACCEPTOR_META_DATA for\r
- // the acceptor metadata\r
- AUTH_SCHEME AuthScheme;\r
- BYTE_VECTOR Exchange;\r
- // contains the opaque handshake message for the\r
- // authentication scheme\r
- } EXCHANGE_MESSAGE;\r
-\r
- struct\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 19]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
- {\r
- MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY\r
- AUTH_SCHEME AuthScheme;\r
- CHECKSUM Checksum;\r
- // contains the checksum of all the previously\r
- // exchanged messages in the order they were sent.\r
- } VERIFY_MESSAGE;\r
-\r
- struct\r
- {\r
- ULONG AlertType;\r
- BYTE_VECTOR AlertValue;\r
- } ALERT;\r
-\r
- //\r
- // alert types\r
- //\r
-\r
- #define ALERT_TYPE_PULSE 1\r
-\r
- //\r
- // reason codes for the heartbeat message\r
- //\r
-\r
- #define ALERT_VERIFY_NO_KEY 1\r
-\r
- struct\r
- {\r
- ULONG cbHeaderLength;\r
- ULONG Reason;\r
- } ALERT_PULSE;\r
-\r
- struct\r
- {\r
- ULONG AlertArrayOffset; // the element is an ALERT\r
- USHORT AlertCount; // contains the number of alerts\r
- } ALERT_VECTOR;\r
-\r
- struct\r
- {\r
- MESSAGE_HEADER Header;\r
- AUTH_SCHEME AuthScheme;\r
- ULONG ErrorCode; // an NTSTATUS code\r
- ALERT_VECTOR Alerts;\r
- } ALERT_MESSAGE;\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 20]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
-Authors' Addresses\r
-\r
- Larry Zhu\r
- Microsoft Corporation\r
- One Microsoft Way\r
- Redmond, WA 98052\r
- US\r
-\r
- Email: lzhu@microsoft.com\r
-\r
-\r
- Kevin Damour\r
- Microsoft Corporation\r
- One Microsoft Way\r
- Redmond, WA 98052\r
- US\r
-\r
- Email: kdamour@microsoft.com\r
-\r
-\r
- Dave McPherson\r
- Microsoft Corporation\r
- One Microsoft Way\r
- Redmond, WA 98052\r
- US\r
-\r
- Email: davemm@microsoft.com\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 21]\r
-\f\r
-Internet-Draft NEGOEX July 2008\r
-\r
-\r
-Full Copyright Statement\r
-\r
- Copyright (C) The IETF Trust (2008).\r
-\r
- This document is subject to the rights, licenses and restrictions\r
- contained in BCP 78, and except as set forth therein, the authors\r
- retain all their rights.\r
-\r
- This document and the information contained herein are provided on an\r
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND\r
- THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS\r
- OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF\r
- THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
-\r
-\r
-Intellectual Property\r
-\r
- The IETF takes no position regarding the validity or scope of any\r
- Intellectual Property Rights or other rights that might be claimed to\r
- pertain to the implementation or use of the technology described in\r
- this document or the extent to which any license under such rights\r
- might or might not be available; nor does it represent that it has\r
- made any independent effort to identify any such rights. Information\r
- on the procedures with respect to rights in RFC documents can be\r
- found in BCP 78 and BCP 79.\r
-\r
- Copies of IPR disclosures made to the IETF Secretariat and any\r
- assurances of licenses to be made available, or the result of an\r
- attempt made to obtain a general license or permission for the use of\r
- such proprietary rights by implementers or users of this\r
- specification can be obtained from the IETF on-line IPR repository at\r
- http://www.ietf.org/ipr.\r
-\r
- The IETF invites any interested party to bring to its attention any\r
- copyrights, patents or patent applications, or other proprietary\r
- rights that may cover technology that may be required to implement\r
- this standard. Please address the information to the IETF at\r
- ietf-ipr@ietf.org.\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-\r
-Zhu, et al. Expires January 15, 2009 [Page 22]\r
-\f\r
-\r
git.samba.org / samba.git / blobdiff