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