idnits 2.17.1 draft-zhu-negoex-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 921. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 932. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 939. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 945. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4178, but the abstract doesn't seem to directly say this. It does mention RFC4178 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC4178, updated by this document, for RFC5378 checks: 2004-11-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 14, 2008) is 5765 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '32' on line 812 == Unused Reference: 'RFC4120' is defined on line 711, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP L. Zhu 3 Internet-Draft K. Damour 4 Updates: 4178 (if approved) D. McPherson 5 Intended status: Informational Microsoft Corporation 6 Expires: January 15, 2009 July 14, 2008 8 The Extended GSS-API Negotiation Mechanism (NEGOEX) 9 draft-zhu-negoex-01 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 15, 2009. 36 Abstract 38 This document defines the Extended Generic Security Service 39 Application Program Interface (GSS-API) Negotiation Mechanism 40 (NegoEx). NegoEx is a pseudo-security mechanism that logically 41 extends the SPNEGO protocol as defined in RFC4178. 43 The NegoEx protocol itself is a security mechanism negotiated by 44 SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY 45 adds a pair of meta-data messages for each negotiated security 46 mechanism. The meta-data exchange allows security mechanisms to 47 exchange auxiliary information such as trust configurations, thus 48 NegoEx provides additional flexibility than just exchanging object 49 identifiers in SPNEGO. 51 NegoEx preserves the optimistic token semantics of SPNEGO and applies 52 that recursively. Consequently a context establishment mechanism 53 token can be included in the initial NegoEx message, and NegoEx does 54 not require an extra round-trip when the initiator's optimistic token 55 is accepted by the target. 57 Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a 58 security mechanism MUST support in order to be negotiated by NegoEx. 59 This document defines these GSS-API extensions. 61 Unlike SPNEGO however, NegoEx defines its own way for signing the 62 protocol messages in order to protect the protocol negotiation. The 63 NegoEx message signing or verification can occur before the security 64 context for the negotiated real security mechanism is fully 65 established. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6 71 3. Presentation Language and Primitive Data Types . . . . . . . . 6 72 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . . 7 73 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 7 75 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 3.5. Enum Types . . . . . . . . . . . . . . . . . . . . . . . . 7 77 3.6. Typedef Declarations . . . . . . . . . . . . . . . . . . . 8 78 3.7. Array Types . . . . . . . . . . . . . . . . . . . . . . . 8 79 3.8. Vector Types . . . . . . . . . . . . . . . . . . . . . . . 8 80 3.9. Constructed Types . . . . . . . . . . . . . . . . . . . . 9 81 4. Cryptographic Computations . . . . . . . . . . . . . . . . . . 10 82 5. The NegoEx Protocol . . . . . . . . . . . . . . . . . . . . . 11 83 5.1. Generation of the Initiator Initial Token . . . . . . . . 11 84 5.2. Receipt of the Initial Initiator Token and Generation 85 of the Initial Acceptor Response . . . . . . . . . . . . . 13 86 5.3. Receipt of the Acceptor Initial Response and 87 Completion of Authentication after the Negotiation 88 Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 5.4. Finalizing Negotiation . . . . . . . . . . . . . . . . . . 15 90 5.5. High-level NegoEx Message Flow . . . . . . . . . . . . . . 15 91 6. Supporting GSS-API Extensions . . . . . . . . . . . . . . . . 16 92 6.1. GSS_Query_meta_data . . . . . . . . . . . . . . . . . . . 16 93 6.2. GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 16 94 6.3. GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 16 95 6.4. GSS_Query_context_attr . . . . . . . . . . . . . . . . . . 16 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 99 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17 100 Appendix A. Protocol Data Structures and Constant Values . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 102 Intellectual Property and Copyright Statements . . . . . . . . . . 22 104 1. Introduction 106 If more than one GSS-API mechanism is shared between the initator and 107 the acceptor, the Simple and Protected (GSS-API) Negotiation 108 Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose 109 a mutually preferred one. This pseudo mechanism does well in the 110 most basic scenarios but suffers from a couple of drawbacks, notably: 112 o First, the SPNEGO negotiation model is inefficient when 113 negotiating based on mechanism specific configuration information. 114 SPNEGO negotiation is based on exchanging object identifiers only, 115 and it does not allow exchange of auxiliary information in any 116 other from. This is inefficient and often impractical in that one 117 object identifier effectively conveys only one bit of information. 119 o Secondly, the SPNEGO negotiation model is inadequate when the 120 choice cannot be made by the acceptor in the initial response. In 121 SPNEGO, the negotiation information is sent one-way from the 122 initiator for the acceptor to make a choice, and the acceptor must 123 choose one when it makes the initial response. This negotiation 124 model is counter intuitive. The selection of a security mechanism 125 is typically the result of selecting one type of credentials from 126 the available set, and the initiator typically does not wish to 127 reveal credentials information often associated with user 128 identities. In practice, in order to operate in this model, the 129 Kerberos GSS-API mechanism [RFC4121] must acquire the context 130 establishment token in the initial call to GSS_Init_sec_context(). 131 If the initiator fails to acquire the initial Kerberos GSS-API 132 context token, it must not offer Kerberos; otherwise the SPNEGO 133 context negotiation will fail without being able to select the 134 next available mechanism that could work. Obtaining the initial 135 Kerberos GSS-API context token may require multiple round-trips of 136 network calls and the cost of the operation can be substantial. 137 It is suboptimal when multiple GSS-API mechanisms have to add the 138 extra cost that would not exist if the negotiated security 139 mechanism were selected based on configuration. 141 The Extended Generic Security Service Application Program Interface 142 (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these 143 concerns. NegoEx is a pseudo security mechanism that is negotiated 144 by SPNEGO, and when negotiated, it can recursively negotiate real 145 security mechanisms. 147 Any security mechanism negotiated by NegoEx MUST support integrity 148 protection. 150 The basic form of NegoEx works as follows: 152 1. The initiator proposes a list of mechanisms in decreasing 153 preference order. For each of these mechanism, NegoEx 154 OPTIOINALLY includes a mechanism specific meta-data token. GSS- 155 API extensions are defined later in this document for NegoEx to 156 query the meta-data token for inclusion in the NegoEx message. 158 2. The acceptor then passes the meta-data token from the initiator 159 to the intended security mechanism. A meta-data token for a 160 security mechanism not supported on the acceptor side is ignored. 161 New GSS-API extensions are defined later in this document for a 162 security mechanism to consume the meta-data token. When 163 processing the received meta-data tokens, a security mechanism 164 that reports a failure is removed from the set of mutually 165 supported mechanisms. The acceptor then responds with the list 166 of mutually supported mechanisms in decreasing preference order. 167 For each of these mechanism, NegoEx again OPTIOINALLY supplies a 168 mechanism specific meta-data token in the response. These meta- 169 data tokens are returned to NegoEx via new GSS-API extensions as 170 described in the initial step. 172 3. The initiator then passes the meta-data tokens to the intended 173 security mechanisms by invoking the new GSS-API extensions. When 174 processing the received meta-data token, a security mechanism 175 that reports a failure is removed from the set of mutually 176 supported mechanisms for this negotiation context. The initiator 177 then selects one from the set of mutually-supported mechanisms. 178 If more than one security mechanism is available, unless 179 otherwise specified, the preferred one in the acceptor's 180 preference order SHOULD be selected. Once the common security 181 mechanism is identified, the security mechanism may also 182 negotiate mechanism-specific options during its context 183 establishments. This will be inside the mechanism tokens, and 184 invisible to the NegoEx protocol. 186 4. The selected security mechanism provides keying materials to 187 NegoEx, and NegoEx then signs and verifies the negotiation NegoEx 188 messages to protect the negotiation. 190 5. The initiator and the acceptor proceed to exchange tokens until 191 the GSS-API context for selected security mechanism is 192 established. Once the security context is established, the per- 193 message tokens are generated and verified in accordance with the 194 selected security mechanism. 196 NegoEx does not work outside of SPNEGO. When negotiated by SPNEGO, 197 NegoEx uses the concepts developed in the GSS-API specification 198 [RFC2743]. The negotiation data is encapsulated in context-level 199 tokens. Therefore, callers of the GSS-API do not need to be aware of 200 the existence of the negotiation tokens but only of the SPENGO 201 pseudo-security mechanism. 203 In its basic form NegoEx requires at least one extra round-trip. 204 Network connection setup is a critical performance characteristic of 205 any network infrastructure and extra round trips over WAN links, 206 packet radio networks, etc. really make a difference. In order to 207 avoid such an extra round trip the initial security token of the 208 preferred mechanism for the initiator may be embedded in the initial 209 NegoEx token. The optimistic mechanism token may be accompanied by 210 the meta-data tokens and the optimistic mechanism token MUST be that 211 of the first mechanism in the list of the mechanisms proposed by the 212 initiator. The NegoEx message that contains signatures for 213 protecting the NegoEx negotiation can also be included along with the 214 mechanism token. If the target preferred mechanism matches the 215 initiator's preferred mechanism, and when the NegoEx negotiation 216 protection messages are included along with the mechanism token, no 217 additional round trips are incurred by using the NegoEx protocol with 218 SPNEGO. 220 NegoEx does not update the ASN.1 structures of SPNEGO in that a large 221 deployment of SPNEGO does not have the ASN.1 extensibility marker in 222 the message definition. There is no change to the SPNEGO messages. 224 NegoEx does not use ASN.1 encoding and it uses simple C structures 225 encoded in little endian for all its messages. 227 The rest of the document is organized as follows: Section 3 defines 228 the encoding of NegoEx data structures and all the primitive data 229 types. Section 4 describes the cryptographic framework required by 230 the NegoEx for protecting the NegoEx negotiation. Section 5 defines 231 the NegoEx messages and the NegoEx protocol. Section 6 defines the 232 new GSS-API extensions that a security mechanism MUST support in 233 order to be negotiated by NegoEx. These then are followed by the 234 security considerations section. Lastly Appendix A contains all the 235 protocol constructs and constants. 237 2. Requirements Terminology 239 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 240 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 241 document are to be interpreted as described in [RFC2119]. 243 3. Presentation Language and Primitive Data Types 245 The following very basic and somewhat casually defined presentation 246 syntax will be used in all NegoEx messages. Although it resembles 247 the programming language "C" in its syntax, it would be risky to draw 248 too many parallels. The purpose of this presentation language is to 249 document NegoEx only; it has no general application beyond that 250 particular goal. 252 This section also defines all the primitive data types. The 253 semantics of the data types is explained in the next section. 255 3.1. Basic Block Size 257 The representation of all data items is explicitly specified. The 258 basic data block size is one octet. Multiple octet data items are 259 concatenations of octets, from left to right, from top to bottom 260 Unless otherwise specific a multi-octet numeric is in little endian 261 order with the least significant octet first. 263 3.2. Miscellaneous 265 Comments start with "//"' and continue until the end of the line. 267 3.3. Constants 269 Constants are denoted using "#define" followed by the symbolic name 270 and then the constant value. 272 3.4. Numbers 274 UCHAR is the data type for a one-octet number. 276 ULONG is the data type for a 4-octet number encoded in little enidan. 278 USHORT is the data type for a 2-octet number encoded in little 279 endian. 281 ULONG64 is the data type for a 8-octet number encoded in little 282 endian. 284 GUID is the data type for a 16-octet number encoded in little endian. 286 3.5. Enum Types 288 An enum type is the data type for a number with a small number of 289 permissible values. An instance of an enum type is a 4-octet number 290 encoded in little endian. 292 The definition of an enum type follows the simple "C" convention. 294 MESSAGE_TYPE is an enum type defined as follows: 296 enum 297 { 298 MESSAGE_TYPE_INITIATOR_NEGO = 0, 299 MESSAGE_TYPE_ACCEPTOR_NEGO, 300 MESSAGE_TYPE_INITIATOR_META_DATA, 301 MESSAGE_TYPE_ACCEPTOR_META_DATA, 302 MESSAGE_TYPE_CHALLENGE, 303 // an exchange message from the acceptor 304 MESSAGE_TYPE_AP_REQUEST, 305 // an exchange message from the initiator 306 MESSAGE_TYPE_VERIFY, 307 MESSAGE_TYPE_ALERT, 308 } MESSAGE_TYPE; 310 MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT 311 has the value 7. 313 3.6. Typedef Declarations 315 A typedef creates a synonym for the type. This is used to create 316 more meaningful names for existing types. 318 The following two type synonyms are defined. 320 typedef GUID AUTH_SCHEME; 321 typedef GUID CONVERSATION_ID; 323 3.7. Array Types 325 Arrays are a data structure which holds multiple variables of the 326 same data type consecutively and the number of elements is fixed. An 327 array is declared using "C" convention. For example, the following 328 defines an array of 32 octets. 330 UCHAR Random[32]; 332 3.8. Vector Types 334 Vectors are a data structure which holds multiple variables of the 335 same data type consecutively and the number of elements is not fixed. 336 A vector contains a fixed length header followed by a variable length 337 payload. The header of a vector structure contains the count of 338 elements and the offset to the payload. In this document all the 339 offset fields start from the beginning of the containing NegoEx 340 message. The size of each element is specified by the vector type 341 definition. 343 The following vector types are defined. 345 struct 346 { 347 ULONG ByteArrayOffset; // each element contains an octet/byte 348 ULONG ByteArrayLength; 349 } BYTE_VECTOR; 351 BYTE_VECTOR encapsulates a variable length array of octets (or bytes) 352 that are stored consecutively. Each element in is a byte (8 bits). 354 struct 355 { 356 ULONG AuthSchemeArrayOffset; 357 // each element contains an AUTH_SCHEME 358 USHORT AuthSchemeCount; 359 } AUTH_SCHEME_VECTOR; 361 AUTH_SCHEME_VECTOR encapsulates a variable length array of 362 AUTH_SCHEMEs that are stored consecutively. Each element is a 363 structure of the type AUTH_SCHEME. 365 struct 366 { 367 ULONG ExtensionArrayOffset; 368 // each element contains an EXTENSION 369 USHORT ExtensionCount; 370 } EXTENSION_VECTOR; 372 EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs 373 that are stored consecutively. Each element is a structure of the 374 type EXTENSION. 376 3.9. Constructed Types 378 Structure types may be constructed from primitive types for 379 convenience. Each specification declares a new, unique type. The 380 syntax for definition is much like that of C. 382 struct { 383 T1 f1; 384 T2 f2; 385 ... 386 Tn fn; 387 } T; 389 Structure definitions may be embedded. 391 The following types are defined as constructed types: 393 struct 394 { 395 ULONG ExtensionType; // negative extensions are critical 396 BYTE_VECTOR ExtensionValue; 397 } EXTENSION; 399 An extension has two fields. The ExtensionType field indicates how 400 the extension data should be interpreted. The ExtensionValue field 401 contains the extension data. 403 // 404 // schemes defined for the checksum in the VERIFY message 405 // 407 struct 408 { 409 ULONG cbHeaderLength; 410 ULONG ChecksumScheme; 411 ULONG ChecksumType; // in the case of RFC3961 scheme, this is 412 // the RFC3961 checksum type 413 BYTE_VECTOR ChecksumValue; 414 } CHECKSUM; 416 The CHECKSUM structure contains 4 fields. The cbHeaderLength length 417 contains the length of the structure defintion in octets, and this 418 field has a value of 20. 420 The ChecksumScheme field describes how checksum is computed and 421 verified. Currently only one value is defined. 423 #define CHECKSUM_SCHEME_RFC3961 1 425 When the value of the ChecksumScheme field is 1 426 (CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a 427 sequence of octets computed according to [RFC3961] and the 428 ChecksumType field contains the checksum type value defined according 429 to [RFC3961]. 431 4. Cryptographic Computations 433 The message signing and verification in NegoEx is based on [RFC3961]. 434 [RFC3961] is used here as a generic framework and this application is 435 not Kerberos specific. 437 A security mechanism MUST support [RFC3961] in order to be negotiated 438 by NegoEx. 440 5. The NegoEx Protocol 442 This section describes the NegoEx protocol and it defines NegoEx 443 messages in the order that the messages can appear on the wire. The 444 enum type MESSAGE_TYPE defined in Section 3.5 lists all NegoEx 445 message types. A GSS-API context token for NegoEx consists of one or 446 more NegoEx messages. If there are more than one NegoEx message, 447 these messages are concatenated together. The smallest data unit for 448 NegoEx to compute the checksum for negotiation protection is a NegoEx 449 message. Note that NegoEx is not a GSS-API mechanism itself and the 450 initial NegoEx context establishment token does not follow the 451 mechanism-independent token format defined in Section 3.1 of 452 [RFC2743]. 454 A security mechanism negotiated by NegoEx is identified by a unique 455 identifier of the data type AUTH_SCHEME defined in Section 3.5. The 456 value of the security mechanism is returned to NegoEx via the 457 GSS_Query_mechanism_info() GSS-API extension as defined in Section 6. 459 The object identifier of the NegoEx within SPNEGO is iso(1) 460 identified-organization(3) dod(6) internet(1) private(4) 461 enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30). 462 Note that NegoEx does not work outside of SPNEGO and it is not GSS- 463 API mechanism. 465 5.1. Generation of the Initiator Initial Token 467 The GSS-API initiator makes the first call to GSS_Init_sec_context() 468 with no input token, and the output token starts as a NEGO_MESSAGE 469 message with the MESSAGE_TYPE_INITIATOR_NEGO message type. 471 struct 472 { 473 ULONG64 Signature; // contains MESSAGE_SIGNATURE 474 MESSAGE_TYPE MessageType; 475 ULONG SequenceNum; // the message sequence number of this, 476 // conversation, starting with 0 and sequentially 477 // incremented 478 ULONG cbHeaderLength; // the header length of this message, 479 // including the message specific header, excluding the 480 // payload 481 ULONG cbMessageLength; // the length of this message 482 CONVERSATION_ID ConversationId; 483 } MESSAGE_HEADER; 485 struct 486 { 487 MESSAGE_HEADER Header; 488 // MESSAGE_TYPE_INITIATOR_NEGO for the initiator, 489 // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor 490 UCHAR Random[32]; 491 ULONG64 ProtocolVersion; 492 // version of the protocol, this contains 0 493 AUTH_SCHEME_VECTOR AuthSchemes; 494 EXTENSION_VECTOR Extensions; 495 } NEGO_MESSAGE; 497 The initiator randomly generates a ConversationID and fills the 498 common header. The ConversationID in subsequent NegoEx messages MUST 499 remain the same. The initiator also fills the Random field using a 500 secure random number generator. The initiator fills the AuthSchemes 501 with available security mechanisms supported by the initiator in 502 decreasing preference order. 504 The extensions field contains NegoEx extensions for future 505 extensibility. There is no extension defined in this document. All 506 negative extension types (the highest bit is set to 1) are critical. 507 If the receiver does not understand a critical extension, the 508 authentication attempt must be rejected. 510 The initiator can OPTIONALLY include a meta-data token, one for each 511 available security mechanism. 513 A meta-data token is returned to NegoEx for a security mechanism 514 using GSS_Query_meta_data() extension as defined in Section 6. A 515 meta-data token is encapsulated in an EXCHANGE message with the 516 message type MESSAGE_TYPE_INITIATOR_META_DATA. 518 struct 519 { 520 MESSAGE_HEADER Header; 521 // MESSAGE_TYPE_CHALLENGE for the acceptor, 522 // or MESSAGE_TYPE_AP_REQUEST for the initiator 523 // MESSAGE_TYPE_INITIATOR_META_DATA for 524 // the initiator metadata 525 // MESSAGE_TYPE_ACCEPTOR_META_DATA for 526 // the acceptor metadata 527 AUTH_SCHEME AuthScheme; 528 BYTE_VECTOR Exchange; 529 // contains the opaque handshake message for the 530 // authentication scheme 531 } EXCHANGE_MESSAGE; 533 The AuthScheme field signifies the security mechanism for which the 534 EXCHANGE message is targeted. If a security mechanism fails to 535 produce the metadata token, it should be removed from the list of 536 supported security mechanism for this negotiation context. 538 If there are more than one exchange messages, the order in which the 539 exchange message is included bears no significance. In other words, 540 the exchange messages are in an unordered set. The NEGO_MESSAGE MAY 541 be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as 542 described above, in which case all the NegoEx messages concatenated 543 are returned as a single input token. 545 The first mechanism in the initiator proposed list can OPTIONALLY 546 include its initial context context in an AP_REQUEST message. 548 Both an AP_REQUSET(short for MESSAGE_TYPE_AP_REQUEST) message and a 549 INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA) 550 message are instances of the EXCHANGE_MESSAGE structure with 551 different message type values. An AP_REQUEST message contains the 552 type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message 553 contains the type MESSAGE_TYPE_INITIATOR_META_DATA. 555 5.2. Receipt of the Initial Initiator Token and Generation of the 556 Initial Acceptor Response 558 Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor 559 verifies the NEGO_MESSAGE to make sure it is well-formed. The 560 acceptor then computes the list of authentication schemes that are 561 mutually supported by examining the set of security mechanisms 562 proposed by the initiator and the meta-data tokens from the 563 initiator. The meta-data tokens are passed to the security mechanism 564 via GSS_Exchange_meta_data() as defined in Section 6. 566 The acceptor MUST examine the NegoEx extensions in the NEGO_MESSAGE. 567 If there is an unknown critical extension, the authentication must be 568 rejected. 570 The acceptor's response starts as a NEGO_MESSAGE but with the 571 MESSAGE_TYPE_ACCEPTOR_NEGO. The AuthSchemes field contains the list 572 of mutually supported security mechanism in decreasing preference 573 order of the acceptor. The acceptor does not need to honor the 574 preference order proposed by the initiator when computing its 575 preference list. 577 The acceptor can OPTIONALLY include a meta-data token, one for each 578 available security mechanism. 580 A meta-data token is returned to NegoEx for a security mechanism 581 using GSS_Query_meta_data() extension as defined in Section 6. A 582 meta-data token is encapsulated in an EXCHANGE message with the 583 message type MESSAGE_TYPE_ACCEPTOR_META_DATA. For a given security 584 mechanism if a meta-token is received from the initiator, 585 GSS_Query_meta_data() MUST be invoked on the acceptor side for that 586 security mechanism, and the output meta-data token, if present, MUST 587 be included in the NegoEx reply. 589 5.3. Receipt of the Acceptor Initial Response and Completion of 590 Authentication after the Negotiation Phrase 592 Upon receipt of the initial response from the acceptor, the initial 593 verifies the NEGO_MESSAGE to make sure it is well-formed. The 594 initiator then computes the list of authentication schemes that are 595 mutually supported by examining the set of security mechanisms 596 returned by the acceptor and the meta-data tokens from the acceptor 597 The meta-data tokens are passed to the security mechanism via 598 GSS_Exchange_meta_data() as defined in Section 6. 600 The initiator MUST examine the NegoEx extensions in the NEGO_MESSAGE. 601 If there is an unknown critical extension, the authentication must be 602 rejected. 604 After the initial exchange of NEGO_MESSAGE messages, the initiator 605 MUST choose the negotiated security mechanism. The negotiated 606 security mechanism cannot be changed once it is selected. 608 The initiator and the acceptor can then proceed to exchange handshake 609 messages as determined by the negotiated security mechanism until its 610 authentication context is established. The context tokens of the 611 negotiated security mechanism are encapsulated in an 612 EXCHANGE_MESSAGE. If the context token is from the initiator, the 613 EXCHANGE_MESSAGE message has the message type 614 MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is 615 MESSAGE_TYPE_CHALLENGE. 617 5.4. Finalizing Negotiation 619 Whenever there is a shared key established returned by 620 GSS_Query_context_attr(NEGOEX_SESSION_KEYS) as defined in Section 6,, 621 a VERIFY message is produced and included in the output token. The 622 returned protocol key is used as the base key in the parlance of 623 RFC3961 to sign all the NegoEx messages in the negotiation context. 625 A VERIFY message is a VERIFY_MESSAGE structure. The AuthScheme field 626 signifies from which security mechanism the protocol key was 627 obtained. The checksum is computed based on RFC3961 and the key 628 usage number is 23 for the message is signed by the initiator, 25 629 otherwise. The checksum is performed over all the previous NegoEx 630 messages in the context negotiation. 632 struct 633 { 634 MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY 635 AUTH_SCHEME AuthScheme; 636 CHECKSUM Checksum; 637 // contains the checksum of all the previously 638 // exchanged messages in the order they were sent. 639 } VERIFY_MESSAGE; 641 Note that the VERIFY_MESSAGE message can be included before the 642 security context for the negotiated security mechanism is fully 643 established. 645 5.5. High-level NegoEx Message Flow 647 The following text art summarizes the protocol message flow: 649 INITIATOR_NEGO 650 *INITIATOR_META_DATA 651 *AP_REQUEST 652 ---------> 653 ACCEPTOR_NEGO 654 ACCEPTOR_META_DATA*+ 655 --------- CHALLENGE* 657 . 658 . 659 *AP_REQUEST 660 VERIFY ---------> 661 CHALLENGE* 662 -------- VERIFY 663 * Indicates optional or situation-dependent messages that are 664 not always sent. 665 + Indicates there can be more than one instance. 667 6. Supporting GSS-API Extensions 669 This section defined all the required GSS-API extensions required by 670 NegoEx. 672 6.1. GSS_Query_meta_data 674 TBD. 676 6.2. GSS_Exchange_meta_data 678 TBD. 680 6.3. GSS_Query_mechanism_info 682 TBD. 684 6.4. GSS_Query_context_attr 686 TBD. 688 7. Security Considerations 690 TBD. 692 8. Acknowledgements 694 TBD. 696 9. IANA Considerations 698 There is no action required for IANA. 700 10. Normative References 702 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 703 Requirement Levels", BCP 14, RFC 2119, March 1997. 705 [RFC2743] Linn, J., "Generic Security Service Application Program 706 Interface Version 2, Update 1", RFC 2743, January 2000. 708 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for 709 Kerberos 5", RFC 3961, February 2005. 711 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 712 Kerberos Network Authentication Service (V5)", RFC 4120, 713 July 2005. 715 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 716 Version 5 Generic Security Service Application Program 717 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 718 July 2005. 720 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The 721 Simple and Protected Generic Security Service Application 722 Program Interface (GSS-API) Negotiation Mechanism", 723 RFC 4178, October 2005. 725 Appendix A. Protocol Data Structures and Constant Values 727 This section complies all the protocol data structures and constant 728 values. 730 #define MESSAGE_SIGNATURE 0x535458454f47454ei64 731 // "NEGOEXTS" 733 struct 734 { 735 ULONG ByteArrayOffset; // each element contains a byte 736 ULONG ByteArrayLength; 738 } BYTE_VECTOR; 740 struct 741 { 742 ULONG AuthSchemeArrayOffset; 743 // each element contains an AUTH_SCHEME 744 USHORT AuthSchemeCount; 745 } AUTH_SCHEME_VECTOR; 747 struct 748 { 749 ULONG ExtensionArrayOffset; 750 // each element contains an EXTENSION 751 USHORT ExtensionCount; 752 } EXTENSION_VECTOR; 754 struct 755 { 756 ULONG ExtensionType; // negative extensions are critical 757 BYTE_VECTOR ExtensionValue; 758 } EXTENSION; 760 // 761 // schemes defined for the checksum in the VERIFY message 762 // 764 #define CHECKSUM_SCHEME_RFC3961 1 766 struct 767 { 768 ULONG cbHeaderLength; 769 ULONG ChecksumScheme; 770 ULONG ChecksumType; // in the case of RFC3961 scheme, this is 771 // the RFC3961 checksum type 772 BYTE_VECTOR ChecksumValue; 773 } CHECKSUM; 775 typedef GUID AUTH_SCHEME; 776 typedef GUID CONVERSATION_ID; 778 enum 779 { 780 MESSAGE_TYPE_INITIATOR_NEGO = 0, 781 MESSAGE_TYPE_ACCEPTOR_NEGO, 782 MESSAGE_TYPE_INITIATOR_META_DATA, 783 MESSAGE_TYPE_ACCEPTOR_META_DATA, 784 MESSAGE_TYPE_CHALLENGE, 785 // an exchange message from the acceptor 787 MESSAGE_TYPE_AP_REQUEST, 788 // an exchange message from the initiator 789 MESSAGE_TYPE_VERIFY, 790 MESSAGE_TYPE_ALERT, 791 } MESSAGE_TYPE; 793 struct 794 { 795 ULONG64 Signature; // contains MESSAGE_SIGNATURE 796 MESSAGE_TYPE MessageType; 797 ULONG SequenceNum; // the message sequence number of this, 798 // conversation, starting with 0 and sequentially 799 // incremented 800 ULONG cbHeaderLength; // the header length of this message, 801 // including the message specific header, excluding the 802 // payload 803 ULONG cbMessageLength; // the length of this message 804 CONVERSATION_ID ConversationId; 805 } MESSAGE_HEADER; 807 struct 808 { 809 MESSAGE_HEADER Header; 810 // MESSAGE_TYPE_INITIATOR_NEGO for the initiator, 811 // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor 812 UCHAR Random[32]; 813 ULONG64 ProtocolVersion; 814 // version of the protocol, this contains 0 815 AUTH_SCHEME_VECTOR AuthSchemes; 816 EXTENSION_VECTOR Extensions; 817 } NEGO_MESSAGE; 819 struct 820 { 821 MESSAGE_HEADER Header; 822 // MESSAGE_TYPE_CHALLENGE for the acceptor, 823 // or MESSAGE_TYPE_AP_REQUEST for the initiator 824 // MESSAGE_TYPE_INITiATOR_META_DATA for 825 // the initiator metadata 826 // MESSAGE_TYPE_ACCEPTOR_META_DATA for 827 // the acceptor metadata 828 AUTH_SCHEME AuthScheme; 829 BYTE_VECTOR Exchange; 830 // contains the opaque handshake message for the 831 // authentication scheme 832 } EXCHANGE_MESSAGE; 834 struct 835 { 836 MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY 837 AUTH_SCHEME AuthScheme; 838 CHECKSUM Checksum; 839 // contains the checksum of all the previously 840 // exchanged messages in the order they were sent. 841 } VERIFY_MESSAGE; 843 struct 844 { 845 ULONG AlertType; 846 BYTE_VECTOR AlertValue; 847 } ALERT; 849 // 850 // alert types 851 // 853 #define ALERT_TYPE_PULSE 1 855 // 856 // reason codes for the heartbeat message 857 // 859 #define ALERT_VERIFY_NO_KEY 1 861 struct 862 { 863 ULONG cbHeaderLength; 864 ULONG Reason; 865 } ALERT_PULSE; 867 struct 868 { 869 ULONG AlertArrayOffset; // the element is an ALERT 870 USHORT AlertCount; // contains the number of alerts 871 } ALERT_VECTOR; 873 struct 874 { 875 MESSAGE_HEADER Header; 876 AUTH_SCHEME AuthScheme; 877 ULONG ErrorCode; // an NTSTATUS code 878 ALERT_VECTOR Alerts; 879 } ALERT_MESSAGE; 881 Authors' Addresses 883 Larry Zhu 884 Microsoft Corporation 885 One Microsoft Way 886 Redmond, WA 98052 887 US 889 Email: lzhu@microsoft.com 891 Kevin Damour 892 Microsoft Corporation 893 One Microsoft Way 894 Redmond, WA 98052 895 US 897 Email: kdamour@microsoft.com 899 Dave McPherson 900 Microsoft Corporation 901 One Microsoft Way 902 Redmond, WA 98052 903 US 905 Email: davemm@microsoft.com 907 Full Copyright Statement 909 Copyright (C) The IETF Trust (2008). 911 This document is subject to the rights, licenses and restrictions 912 contained in BCP 78, and except as set forth therein, the authors 913 retain all their rights. 915 This document and the information contained herein are provided on an 916 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 917 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 918 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 919 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 920 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 921 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 923 Intellectual Property 925 The IETF takes no position regarding the validity or scope of any 926 Intellectual Property Rights or other rights that might be claimed to 927 pertain to the implementation or use of the technology described in 928 this document or the extent to which any license under such rights 929 might or might not be available; nor does it represent that it has 930 made any independent effort to identify any such rights. Information 931 on the procedures with respect to rights in RFC documents can be 932 found in BCP 78 and BCP 79. 934 Copies of IPR disclosures made to the IETF Secretariat and any 935 assurances of licenses to be made available, or the result of an 936 attempt made to obtain a general license or permission for the use of 937 such proprietary rights by implementers or users of this 938 specification can be obtained from the IETF on-line IPR repository at 939 http://www.ietf.org/ipr. 941 The IETF invites any interested party to bring to its attention any 942 copyrights, patents or patent applications, or other proprietary 943 rights that may cover technology that may be required to implement 944 this standard. Please address the information to the IETF at 945 ietf-ipr@ietf.org.