| blob | 21620a89662ab79e1f69c68f6d021668f777048a |
1 \r
2 \r
3 NETWORK WORKING GROUP L. Zhu\r
4 Internet-Draft K. Damour\r
5 Updates: 4178 (if approved) D. McPherson\r
6 Intended status: Informational Microsoft Corporation\r
7 Expires: January 15, 2009 July 14, 2008\r
8 \r
9 \r
10 The Extended GSS-API Negotiation Mechanism (NEGOEX)\r
11 draft-zhu-negoex-01\r
12 \r
13 Status of this Memo\r
14 \r
15 By submitting this Internet-Draft, each author represents that any\r
16 applicable patent or other IPR claims of which he or she is aware\r
17 have been or will be disclosed, and any of which he or she becomes\r
18 aware will be disclosed, in accordance with Section 6 of BCP 79.\r
19 \r
20 Internet-Drafts are working documents of the Internet Engineering\r
21 Task Force (IETF), its areas, and its working groups. Note that\r
22 other groups may also distribute working documents as Internet-\r
23 Drafts.\r
24 \r
25 Internet-Drafts are draft documents valid for a maximum of six months\r
26 and may be updated, replaced, or obsoleted by other documents at any\r
27 time. It is inappropriate to use Internet-Drafts as reference\r
28 material or to cite them other than as "work in progress."\r
29 \r
30 The list of current Internet-Drafts can be accessed at\r
31 http://www.ietf.org/ietf/1id-abstracts.txt.\r
32 \r
33 The list of Internet-Draft Shadow Directories can be accessed at\r
34 http://www.ietf.org/shadow.html.\r
35 \r
36 This Internet-Draft will expire on January 15, 2009.\r
37 \r
38 Abstract\r
39 \r
40 This document defines the Extended Generic Security Service\r
41 Application Program Interface (GSS-API) Negotiation Mechanism\r
42 (NegoEx). NegoEx is a pseudo-security mechanism that logically\r
43 extends the SPNEGO protocol as defined in RFC4178.\r
44 \r
45 The NegoEx protocol itself is a security mechanism negotiated by\r
46 SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY\r
47 adds a pair of meta-data messages for each negotiated security\r
48 mechanism. The meta-data exchange allows security mechanisms to\r
49 exchange auxiliary information such as trust configurations, thus\r
50 NegoEx provides additional flexibility than just exchanging object\r
51 \r
52 \r
53 \r
54 Zhu, et al. Expires January 15, 2009 [Page 1]\r
56 Internet-Draft NEGOEX July 2008\r
57 \r
58 \r
59 identifiers in SPNEGO.\r
60 \r
61 NegoEx preserves the optimistic token semantics of SPNEGO and applies\r
62 that recursively. Consequently a context establishment mechanism\r
63 token can be included in the initial NegoEx message, and NegoEx does\r
64 not require an extra round-trip when the initiator's optimistic token\r
65 is accepted by the target.\r
66 \r
67 Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a\r
68 security mechanism MUST support in order to be negotiated by NegoEx.\r
69 This document defines these GSS-API extensions.\r
70 \r
71 Unlike SPNEGO however, NegoEx defines its own way for signing the\r
72 protocol messages in order to protect the protocol negotiation. The\r
73 NegoEx message signing or verification can occur before the security\r
74 context for the negotiated real security mechanism is fully\r
75 established.\r
76 \r
77 \r
78 \r
79 \r
80 \r
81 \r
82 \r
83 \r
84 \r
85 \r
86 \r
87 \r
88 \r
89 \r
90 \r
91 \r
92 \r
93 \r
94 \r
95 \r
96 \r
97 \r
98 \r
99 \r
100 \r
101 \r
102 \r
103 \r
104 \r
105 \r
106 \r
107 \r
108 \r
109 \r
110 Zhu, et al. Expires January 15, 2009 [Page 2]\r
112 Internet-Draft NEGOEX July 2008\r
113 \r
114 \r
115 Table of Contents\r
116 \r
117 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4\r
118 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6\r
119 3. Presentation Language and Primitive Data Types . . . . . . . . 6\r
120 3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . . 7\r
121 3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 7\r
122 3.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 7\r
123 3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 7\r
124 3.5. Enum Types . . . . . . . . . . . . . . . . . . . . . . . . 7\r
125 3.6. Typedef Declarations . . . . . . . . . . . . . . . . . . . 8\r
126 3.7. Array Types . . . . . . . . . . . . . . . . . . . . . . . 8\r
127 3.8. Vector Types . . . . . . . . . . . . . . . . . . . . . . . 8\r
128 3.9. Constructed Types . . . . . . . . . . . . . . . . . . . . 9\r
129 4. Cryptographic Computations . . . . . . . . . . . . . . . . . . 10\r
130 5. The NegoEx Protocol . . . . . . . . . . . . . . . . . . . . . 11\r
131 5.1. Generation of the Initiator Initial Token . . . . . . . . 11\r
132 5.2. Receipt of the Initial Initiator Token and Generation\r
133 of the Initial Acceptor Response . . . . . . . . . . . . . 13\r
134 5.3. Receipt of the Acceptor Initial Response and\r
135 Completion of Authentication after the Negotiation\r
136 Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 14\r
137 5.4. Finalizing Negotiation . . . . . . . . . . . . . . . . . . 15\r
138 5.5. High-level NegoEx Message Flow . . . . . . . . . . . . . . 15\r
139 6. Supporting GSS-API Extensions . . . . . . . . . . . . . . . . 16\r
140 6.1. GSS_Query_meta_data . . . . . . . . . . . . . . . . . . . 16\r
141 6.2. GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 16\r
142 6.3. GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 16\r
143 6.4. GSS_Query_context_attr . . . . . . . . . . . . . . . . . . 16\r
144 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16\r
145 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17\r
146 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17\r
147 10. Normative References . . . . . . . . . . . . . . . . . . . . . 17\r
148 Appendix A. Protocol Data Structures and Constant Values . . . . 17\r
149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21\r
150 Intellectual Property and Copyright Statements . . . . . . . . . . 22\r
151 \r
152 \r
153 \r
154 \r
155 \r
156 \r
157 \r
158 \r
159 \r
160 \r
161 \r
162 \r
163 \r
164 \r
165 \r
166 Zhu, et al. Expires January 15, 2009 [Page 3]\r
168 Internet-Draft NEGOEX July 2008\r
169 \r
170 \r
171 1. Introduction\r
172 \r
173 If more than one GSS-API mechanism is shared between the initator and\r
174 the acceptor, the Simple and Protected (GSS-API) Negotiation\r
175 Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose\r
176 a mutually preferred one. This pseudo mechanism does well in the\r
177 most basic scenarios but suffers from a couple of drawbacks, notably:\r
178 \r
179 o First, the SPNEGO negotiation model is inefficient when\r
180 negotiating based on mechanism specific configuration information.\r
181 SPNEGO negotiation is based on exchanging object identifiers only,\r
182 and it does not allow exchange of auxiliary information in any\r
183 other from. This is inefficient and often impractical in that one\r
184 object identifier effectively conveys only one bit of information.\r
185 \r
186 o Secondly, the SPNEGO negotiation model is inadequate when the\r
187 choice cannot be made by the acceptor in the initial response. In\r
188 SPNEGO, the negotiation information is sent one-way from the\r
189 initiator for the acceptor to make a choice, and the acceptor must\r
190 choose one when it makes the initial response. This negotiation\r
191 model is counter intuitive. The selection of a security mechanism\r
192 is typically the result of selecting one type of credentials from\r
193 the available set, and the initiator typically does not wish to\r
194 reveal credentials information often associated with user\r
195 identities. In practice, in order to operate in this model, the\r
196 Kerberos GSS-API mechanism [RFC4121] must acquire the context\r
197 establishment token in the initial call to GSS_Init_sec_context().\r
198 If the initiator fails to acquire the initial Kerberos GSS-API\r
199 context token, it must not offer Kerberos; otherwise the SPNEGO\r
200 context negotiation will fail without being able to select the\r
201 next available mechanism that could work. Obtaining the initial\r
202 Kerberos GSS-API context token may require multiple round-trips of\r
203 network calls and the cost of the operation can be substantial.\r
204 It is suboptimal when multiple GSS-API mechanisms have to add the\r
205 extra cost that would not exist if the negotiated security\r
206 mechanism were selected based on configuration.\r
207 \r
208 The Extended Generic Security Service Application Program Interface\r
209 (GSS-API) Negotiation Mechanism (NegoEx) is defined to address these\r
210 concerns. NegoEx is a pseudo security mechanism that is negotiated\r
211 by SPNEGO, and when negotiated, it can recursively negotiate real\r
212 security mechanisms.\r
213 \r
214 Any security mechanism negotiated by NegoEx MUST support integrity\r
215 protection.\r
216 \r
217 The basic form of NegoEx works as follows:\r
218 \r
219 \r
220 \r
221 \r
222 Zhu, et al. Expires January 15, 2009 [Page 4]\r
224 Internet-Draft NEGOEX July 2008\r
225 \r
226 \r
227 1. The initiator proposes a list of mechanisms in decreasing\r
228 preference order. For each of these mechanism, NegoEx\r
229 OPTIOINALLY includes a mechanism specific meta-data token. GSS-\r
230 API extensions are defined later in this document for NegoEx to\r
231 query the meta-data token for inclusion in the NegoEx message.\r
232 \r
233 2. The acceptor then passes the meta-data token from the initiator\r
234 to the intended security mechanism. A meta-data token for a\r
235 security mechanism not supported on the acceptor side is ignored.\r
236 New GSS-API extensions are defined later in this document for a\r
237 security mechanism to consume the meta-data token. When\r
238 processing the received meta-data tokens, a security mechanism\r
239 that reports a failure is removed from the set of mutually\r
240 supported mechanisms. The acceptor then responds with the list\r
241 of mutually supported mechanisms in decreasing preference order.\r
242 For each of these mechanism, NegoEx again OPTIOINALLY supplies a\r
243 mechanism specific meta-data token in the response. These meta-\r
244 data tokens are returned to NegoEx via new GSS-API extensions as\r
245 described in the initial step.\r
246 \r
247 3. The initiator then passes the meta-data tokens to the intended\r
248 security mechanisms by invoking the new GSS-API extensions. When\r
249 processing the received meta-data token, a security mechanism\r
250 that reports a failure is removed from the set of mutually\r
251 supported mechanisms for this negotiation context. The initiator\r
252 then selects one from the set of mutually-supported mechanisms.\r
253 If more than one security mechanism is available, unless\r
254 otherwise specified, the preferred one in the acceptor's\r
255 preference order SHOULD be selected. Once the common security\r
256 mechanism is identified, the security mechanism may also\r
257 negotiate mechanism-specific options during its context\r
258 establishments. This will be inside the mechanism tokens, and\r
259 invisible to the NegoEx protocol.\r
260 \r
261 4. The selected security mechanism provides keying materials to\r
262 NegoEx, and NegoEx then signs and verifies the negotiation NegoEx\r
263 messages to protect the negotiation.\r
264 \r
265 5. The initiator and the acceptor proceed to exchange tokens until\r
266 the GSS-API context for selected security mechanism is\r
267 established. Once the security context is established, the per-\r
268 message tokens are generated and verified in accordance with the\r
269 selected security mechanism.\r
270 \r
271 NegoEx does not work outside of SPNEGO. When negotiated by SPNEGO,\r
272 NegoEx uses the concepts developed in the GSS-API specification\r
273 [RFC2743]. The negotiation data is encapsulated in context-level\r
274 tokens. Therefore, callers of the GSS-API do not need to be aware of\r
275 \r
276 \r
277 \r
278 Zhu, et al. Expires January 15, 2009 [Page 5]\r
280 Internet-Draft NEGOEX July 2008\r
281 \r
282 \r
283 the existence of the negotiation tokens but only of the SPENGO\r
284 pseudo-security mechanism.\r
285 \r
286 In its basic form NegoEx requires at least one extra round-trip.\r
287 Network connection setup is a critical performance characteristic of\r
288 any network infrastructure and extra round trips over WAN links,\r
289 packet radio networks, etc. really make a difference. In order to\r
290 avoid such an extra round trip the initial security token of the\r
291 preferred mechanism for the initiator may be embedded in the initial\r
292 NegoEx token. The optimistic mechanism token may be accompanied by\r
293 the meta-data tokens and the optimistic mechanism token MUST be that\r
294 of the first mechanism in the list of the mechanisms proposed by the\r
295 initiator. The NegoEx message that contains signatures for\r
296 protecting the NegoEx negotiation can also be included along with the\r
297 mechanism token. If the target preferred mechanism matches the\r
298 initiator's preferred mechanism, and when the NegoEx negotiation\r
299 protection messages are included along with the mechanism token, no\r
300 additional round trips are incurred by using the NegoEx protocol with\r
301 SPNEGO.\r
302 \r
303 NegoEx does not update the ASN.1 structures of SPNEGO in that a large\r
304 deployment of SPNEGO does not have the ASN.1 extensibility marker in\r
305 the message definition. There is no change to the SPNEGO messages.\r
306 \r
307 NegoEx does not use ASN.1 encoding and it uses simple C structures\r
308 encoded in little endian for all its messages.\r
309 \r
310 The rest of the document is organized as follows: Section 3 defines\r
311 the encoding of NegoEx data structures and all the primitive data\r
312 types. Section 4 describes the cryptographic framework required by\r
313 the NegoEx for protecting the NegoEx negotiation. Section 5 defines\r
314 the NegoEx messages and the NegoEx protocol. Section 6 defines the\r
315 new GSS-API extensions that a security mechanism MUST support in\r
316 order to be negotiated by NegoEx. These then are followed by the\r
317 security considerations section. Lastly Appendix A contains all the\r
318 protocol constructs and constants.\r
319 \r
320 \r
321 2. Requirements Terminology\r
322 \r
323 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\r
324 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this\r
325 document are to be interpreted as described in [RFC2119].\r
326 \r
327 \r
328 3. Presentation Language and Primitive Data Types\r
329 \r
330 The following very basic and somewhat casually defined presentation\r
331 \r
332 \r
333 \r
334 Zhu, et al. Expires January 15, 2009 [Page 6]\r
336 Internet-Draft NEGOEX July 2008\r
337 \r
338 \r
339 syntax will be used in all NegoEx messages. Although it resembles\r
340 the programming language "C" in its syntax, it would be risky to draw\r
341 too many parallels. The purpose of this presentation language is to\r
342 document NegoEx only; it has no general application beyond that\r
343 particular goal.\r
344 \r
345 This section also defines all the primitive data types. The\r
346 semantics of the data types is explained in the next section.\r
347 \r
348 3.1. Basic Block Size\r
349 \r
350 The representation of all data items is explicitly specified. The\r
351 basic data block size is one octet. Multiple octet data items are\r
352 concatenations of octets, from left to right, from top to bottom\r
353 Unless otherwise specific a multi-octet numeric is in little endian\r
354 order with the least significant octet first.\r
355 \r
356 3.2. Miscellaneous\r
357 \r
358 Comments start with "//"' and continue until the end of the line.\r
359 \r
360 3.3. Constants\r
361 \r
362 Constants are denoted using "#define" followed by the symbolic name\r
363 and then the constant value.\r
364 \r
365 3.4. Numbers\r
366 \r
367 UCHAR is the data type for a one-octet number.\r
368 \r
369 ULONG is the data type for a 4-octet number encoded in little enidan.\r
370 \r
371 USHORT is the data type for a 2-octet number encoded in little\r
372 endian.\r
373 \r
374 ULONG64 is the data type for a 8-octet number encoded in little\r
375 endian.\r
376 \r
377 GUID is the data type for a 16-octet number encoded in little endian.\r
378 \r
379 3.5. Enum Types\r
380 \r
381 An enum type is the data type for a number with a small number of\r
382 permissible values. An instance of an enum type is a 4-octet number\r
383 encoded in little endian.\r
384 \r
385 The definition of an enum type follows the simple "C" convention.\r
386 \r
387 \r
388 \r
389 \r
390 Zhu, et al. Expires January 15, 2009 [Page 7]\r
392 Internet-Draft NEGOEX July 2008\r
393 \r
394 \r
395 MESSAGE_TYPE is an enum type defined as follows:\r
396 \r
397 enum\r
398 {\r
399 MESSAGE_TYPE_INITIATOR_NEGO = 0,\r
400 MESSAGE_TYPE_ACCEPTOR_NEGO,\r
401 MESSAGE_TYPE_INITIATOR_META_DATA,\r
402 MESSAGE_TYPE_ACCEPTOR_META_DATA,\r
403 MESSAGE_TYPE_CHALLENGE,\r
404 // an exchange message from the acceptor\r
405 MESSAGE_TYPE_AP_REQUEST,\r
406 // an exchange message from the initiator\r
407 MESSAGE_TYPE_VERIFY,\r
408 MESSAGE_TYPE_ALERT,\r
409 } MESSAGE_TYPE;\r
410 \r
411 MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT\r
412 has the value 7.\r
413 \r
414 3.6. Typedef Declarations\r
415 \r
416 A typedef creates a synonym for the type. This is used to create\r
417 more meaningful names for existing types.\r
418 \r
419 The following two type synonyms are defined.\r
420 \r
421 typedef GUID AUTH_SCHEME;\r
422 typedef GUID CONVERSATION_ID;\r
423 \r
424 3.7. Array Types\r
425 \r
426 Arrays are a data structure which holds multiple variables of the\r
427 same data type consecutively and the number of elements is fixed. An\r
428 array is declared using "C" convention. For example, the following\r
429 defines an array of 32 octets.\r
430 \r
431 UCHAR Random[32];\r
432 \r
433 3.8. Vector Types\r
434 \r
435 Vectors are a data structure which holds multiple variables of the\r
436 same data type consecutively and the number of elements is not fixed.\r
437 A vector contains a fixed length header followed by a variable length\r
438 payload. The header of a vector structure contains the count of\r
439 elements and the offset to the payload. In this document all the\r
440 offset fields start from the beginning of the containing NegoEx\r
441 message. The size of each element is specified by the vector type\r
442 definition.\r
443 \r
444 \r
445 \r
446 Zhu, et al. Expires January 15, 2009 [Page 8]\r
448 Internet-Draft NEGOEX July 2008\r
449 \r
450 \r
451 The following vector types are defined.\r
452 \r
453 struct\r
454 {\r
455 ULONG ByteArrayOffset; // each element contains an octet/byte\r
456 ULONG ByteArrayLength;\r
457 } BYTE_VECTOR;\r
458 \r
459 BYTE_VECTOR encapsulates a variable length array of octets (or bytes)\r
460 that are stored consecutively. Each element in is a byte (8 bits).\r
461 \r
462 struct\r
463 {\r
464 ULONG AuthSchemeArrayOffset;\r
465 // each element contains an AUTH_SCHEME\r
466 USHORT AuthSchemeCount;\r
467 } AUTH_SCHEME_VECTOR;\r
468 \r
469 AUTH_SCHEME_VECTOR encapsulates a variable length array of\r
470 AUTH_SCHEMEs that are stored consecutively. Each element is a\r
471 structure of the type AUTH_SCHEME.\r
472 \r
473 struct\r
474 {\r
475 ULONG ExtensionArrayOffset;\r
476 // each element contains an EXTENSION\r
477 USHORT ExtensionCount;\r
478 } EXTENSION_VECTOR;\r
479 \r
480 EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs\r
481 that are stored consecutively. Each element is a structure of the\r
482 type EXTENSION.\r
483 \r
484 3.9. Constructed Types\r
485 \r
486 Structure types may be constructed from primitive types for\r
487 convenience. Each specification declares a new, unique type. The\r
488 syntax for definition is much like that of C.\r
489 \r
490 struct {\r
491 T1 f1;\r
492 T2 f2;\r
493 ...\r
494 Tn fn;\r
495 } T;\r
496 \r
497 \r
498 Structure definitions may be embedded.\r
499 \r
500 \r
501 \r
502 Zhu, et al. Expires January 15, 2009 [Page 9]\r
504 Internet-Draft NEGOEX July 2008\r
505 \r
506 \r
507 The following types are defined as constructed types:\r
508 \r
509 struct\r
510 {\r
511 ULONG ExtensionType; // negative extensions are critical\r
512 BYTE_VECTOR ExtensionValue;\r
513 } EXTENSION;\r
514 \r
515 An extension has two fields. The ExtensionType field indicates how\r
516 the extension data should be interpreted. The ExtensionValue field\r
517 contains the extension data.\r
518 \r
519 //\r
520 // schemes defined for the checksum in the VERIFY message\r
521 //\r
522 \r
523 struct\r
524 {\r
525 ULONG cbHeaderLength;\r
526 ULONG ChecksumScheme;\r
527 ULONG ChecksumType; // in the case of RFC3961 scheme, this is\r
528 // the RFC3961 checksum type\r
529 BYTE_VECTOR ChecksumValue;\r
530 } CHECKSUM;\r
531 \r
532 The CHECKSUM structure contains 4 fields. The cbHeaderLength length\r
533 contains the length of the structure defintion in octets, and this\r
534 field has a value of 20.\r
535 \r
536 The ChecksumScheme field describes how checksum is computed and\r
537 verified. Currently only one value is defined.\r
538 \r
539 #define CHECKSUM_SCHEME_RFC3961 1\r
540 \r
541 When the value of the ChecksumScheme field is 1\r
542 (CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a\r
543 sequence of octets computed according to [RFC3961] and the\r
544 ChecksumType field contains the checksum type value defined according\r
545 to [RFC3961].\r
546 \r
547 \r
548 4. Cryptographic Computations\r
549 \r
550 The message signing and verification in NegoEx is based on [RFC3961].\r
551 [RFC3961] is used here as a generic framework and this application is\r
552 not Kerberos specific.\r
553 \r
554 A security mechanism MUST support [RFC3961] in order to be negotiated\r
555 \r
556 \r
557 \r
558 Zhu, et al. Expires January 15, 2009 [Page 10]\r
560 Internet-Draft NEGOEX July 2008\r
561 \r
562 \r
563 by NegoEx.\r
564 \r
565 \r
566 5. The NegoEx Protocol\r
567 \r
568 This section describes the NegoEx protocol and it defines NegoEx\r
569 messages in the order that the messages can appear on the wire. The\r
570 enum type MESSAGE_TYPE defined in Section 3.5 lists all NegoEx\r
571 message types. A GSS-API context token for NegoEx consists of one or\r
572 more NegoEx messages. If there are more than one NegoEx message,\r
573 these messages are concatenated together. The smallest data unit for\r
574 NegoEx to compute the checksum for negotiation protection is a NegoEx\r
575 message. Note that NegoEx is not a GSS-API mechanism itself and the\r
576 initial NegoEx context establishment token does not follow the\r
577 mechanism-independent token format defined in Section 3.1 of\r
578 [RFC2743].\r
579 \r
580 A security mechanism negotiated by NegoEx is identified by a unique\r
581 identifier of the data type AUTH_SCHEME defined in Section 3.5. The\r
582 value of the security mechanism is returned to NegoEx via the\r
583 GSS_Query_mechanism_info() GSS-API extension as defined in Section 6.\r
584 \r
585 The object identifier of the NegoEx within SPNEGO is iso(1)\r
586 identified-organization(3) dod(6) internet(1) private(4)\r
587 enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30).\r
588 Note that NegoEx does not work outside of SPNEGO and it is not GSS-\r
589 API mechanism.\r
590 \r
591 5.1. Generation of the Initiator Initial Token\r
592 \r
593 The GSS-API initiator makes the first call to GSS_Init_sec_context()\r
594 with no input token, and the output token starts as a NEGO_MESSAGE\r
595 message with the MESSAGE_TYPE_INITIATOR_NEGO message type.\r
596 \r
597 \r
598 \r
599 \r
600 \r
601 \r
602 \r
603 \r
604 \r
605 \r
606 \r
607 \r
608 \r
609 \r
610 \r
611 \r
612 \r
613 \r
614 Zhu, et al. Expires January 15, 2009 [Page 11]\r
616 Internet-Draft NEGOEX July 2008\r
617 \r
618 \r
619 struct\r
620 {\r
621 ULONG64 Signature; // contains MESSAGE_SIGNATURE\r
622 MESSAGE_TYPE MessageType;\r
623 ULONG SequenceNum; // the message sequence number of this,\r
624 // conversation, starting with 0 and sequentially\r
625 // incremented\r
626 ULONG cbHeaderLength; // the header length of this message,\r
627 // including the message specific header, excluding the\r
628 // payload\r
629 ULONG cbMessageLength; // the length of this message\r
630 CONVERSATION_ID ConversationId;\r
631 } MESSAGE_HEADER;\r
632 \r
633 struct\r
634 {\r
635 MESSAGE_HEADER Header;\r
636 // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,\r
637 // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor\r
638 UCHAR Random[32];\r
639 ULONG64 ProtocolVersion;\r
640 // version of the protocol, this contains 0\r
641 AUTH_SCHEME_VECTOR AuthSchemes;\r
642 EXTENSION_VECTOR Extensions;\r
643 } NEGO_MESSAGE;\r
644 \r
645 The initiator randomly generates a ConversationID and fills the\r
646 common header. The ConversationID in subsequent NegoEx messages MUST\r
647 remain the same. The initiator also fills the Random field using a\r
648 secure random number generator. The initiator fills the AuthSchemes\r
649 with available security mechanisms supported by the initiator in\r
650 decreasing preference order.\r
651 \r
652 The extensions field contains NegoEx extensions for future\r
653 extensibility. There is no extension defined in this document. All\r
654 negative extension types (the highest bit is set to 1) are critical.\r
655 If the receiver does not understand a critical extension, the\r
656 authentication attempt must be rejected.\r
657 \r
658 The initiator can OPTIONALLY include a meta-data token, one for each\r
659 available security mechanism.\r
660 \r
661 A meta-data token is returned to NegoEx for a security mechanism\r
662 using GSS_Query_meta_data() extension as defined in Section 6. A\r
663 meta-data token is encapsulated in an EXCHANGE message with the\r
664 message type MESSAGE_TYPE_INITIATOR_META_DATA.\r
665 \r
666 \r
667 \r
668 \r
669 \r
670 Zhu, et al. Expires January 15, 2009 [Page 12]\r
672 Internet-Draft NEGOEX July 2008\r
673 \r
674 \r
675 struct\r
676 {\r
677 MESSAGE_HEADER Header;\r
678 // MESSAGE_TYPE_CHALLENGE for the acceptor,\r
679 // or MESSAGE_TYPE_AP_REQUEST for the initiator\r
680 // MESSAGE_TYPE_INITIATOR_META_DATA for\r
681 // the initiator metadata\r
682 // MESSAGE_TYPE_ACCEPTOR_META_DATA for\r
683 // the acceptor metadata\r
684 AUTH_SCHEME AuthScheme;\r
685 BYTE_VECTOR Exchange;\r
686 // contains the opaque handshake message for the\r
687 // authentication scheme\r
688 } EXCHANGE_MESSAGE;\r
689 \r
690 The AuthScheme field signifies the security mechanism for which the\r
691 EXCHANGE message is targeted. If a security mechanism fails to\r
692 produce the metadata token, it should be removed from the list of\r
693 supported security mechanism for this negotiation context.\r
694 \r
695 If there are more than one exchange messages, the order in which the\r
696 exchange message is included bears no significance. In other words,\r
697 the exchange messages are in an unordered set. The NEGO_MESSAGE MAY\r
698 be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as\r
699 described above, in which case all the NegoEx messages concatenated\r
700 are returned as a single input token.\r
701 \r
702 The first mechanism in the initiator proposed list can OPTIONALLY\r
703 include its initial context context in an AP_REQUEST message.\r
704 \r
705 Both an AP_REQUSET(short for MESSAGE_TYPE_AP_REQUEST) message and a\r
706 INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA)\r
707 message are instances of the EXCHANGE_MESSAGE structure with\r
708 different message type values. An AP_REQUEST message contains the\r
709 type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message\r
710 contains the type MESSAGE_TYPE_INITIATOR_META_DATA.\r
711 \r
712 5.2. Receipt of the Initial Initiator Token and Generation of the\r
713 Initial Acceptor Response\r
714 \r
715 Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor\r
716 verifies the NEGO_MESSAGE to make sure it is well-formed. The\r
717 acceptor then computes the list of authentication schemes that are\r
718 mutually supported by examining the set of security mechanisms\r
719 proposed by the initiator and the meta-data tokens from the\r
720 initiator. The meta-data tokens are passed to the security mechanism\r
721 via GSS_Exchange_meta_data() as defined in Section 6.\r
722 \r
723 \r
724 \r
725 \r
726 Zhu, et al. Expires January 15, 2009 [Page 13]\r
728 Internet-Draft NEGOEX July 2008\r
729 \r
730 \r
731 The acceptor MUST examine the NegoEx extensions in the NEGO_MESSAGE.\r
732 If there is an unknown critical extension, the authentication must be\r
733 rejected.\r
734 \r
735 The acceptor's response starts as a NEGO_MESSAGE but with the\r
736 MESSAGE_TYPE_ACCEPTOR_NEGO. The AuthSchemes field contains the list\r
737 of mutually supported security mechanism in decreasing preference\r
738 order of the acceptor. The acceptor does not need to honor the\r
739 preference order proposed by the initiator when computing its\r
740 preference list.\r
741 \r
742 The acceptor can OPTIONALLY include a meta-data token, one for each\r
743 available security mechanism.\r
744 \r
745 A meta-data token is returned to NegoEx for a security mechanism\r
746 using GSS_Query_meta_data() extension as defined in Section 6. A\r
747 meta-data token is encapsulated in an EXCHANGE message with the\r
748 message type MESSAGE_TYPE_ACCEPTOR_META_DATA. For a given security\r
749 mechanism if a meta-token is received from the initiator,\r
750 GSS_Query_meta_data() MUST be invoked on the acceptor side for that\r
751 security mechanism, and the output meta-data token, if present, MUST\r
752 be included in the NegoEx reply.\r
753 \r
754 5.3. Receipt of the Acceptor Initial Response and Completion of\r
755 Authentication after the Negotiation Phrase\r
756 \r
757 Upon receipt of the initial response from the acceptor, the initial\r
758 verifies the NEGO_MESSAGE to make sure it is well-formed. The\r
759 initiator then computes the list of authentication schemes that are\r
760 mutually supported by examining the set of security mechanisms\r
761 returned by the acceptor and the meta-data tokens from the acceptor\r
762 The meta-data tokens are passed to the security mechanism via\r
763 GSS_Exchange_meta_data() as defined in Section 6.\r
764 \r
765 The initiator MUST examine the NegoEx extensions in the NEGO_MESSAGE.\r
766 If there is an unknown critical extension, the authentication must be\r
767 rejected.\r
768 \r
769 After the initial exchange of NEGO_MESSAGE messages, the initiator\r
770 MUST choose the negotiated security mechanism. The negotiated\r
771 security mechanism cannot be changed once it is selected.\r
772 \r
773 The initiator and the acceptor can then proceed to exchange handshake\r
774 messages as determined by the negotiated security mechanism until its\r
775 authentication context is established. The context tokens of the\r
776 negotiated security mechanism are encapsulated in an\r
777 EXCHANGE_MESSAGE. If the context token is from the initiator, the\r
778 EXCHANGE_MESSAGE message has the message type\r
779 \r
780 \r
781 \r
782 Zhu, et al. Expires January 15, 2009 [Page 14]\r
784 Internet-Draft NEGOEX July 2008\r
785 \r
786 \r
787 MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is\r
788 MESSAGE_TYPE_CHALLENGE.\r
789 \r
790 5.4. Finalizing Negotiation\r
791 \r
792 Whenever there is a shared key established returned by\r
793 GSS_Query_context_attr(NEGOEX_SESSION_KEYS) as defined in Section 6,,\r
794 a VERIFY message is produced and included in the output token. The\r
795 returned protocol key is used as the base key in the parlance of\r
796 RFC3961 to sign all the NegoEx messages in the negotiation context.\r
797 \r
798 A VERIFY message is a VERIFY_MESSAGE structure. The AuthScheme field\r
799 signifies from which security mechanism the protocol key was\r
800 obtained. The checksum is computed based on RFC3961 and the key\r
801 usage number is 23 for the message is signed by the initiator, 25\r
802 otherwise. The checksum is performed over all the previous NegoEx\r
803 messages in the context negotiation.\r
804 \r
805 struct\r
806 {\r
807 MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY\r
808 AUTH_SCHEME AuthScheme;\r
809 CHECKSUM Checksum;\r
810 // contains the checksum of all the previously\r
811 // exchanged messages in the order they were sent.\r
812 } VERIFY_MESSAGE;\r
813 \r
814 Note that the VERIFY_MESSAGE message can be included before the\r
815 security context for the negotiated security mechanism is fully\r
816 established.\r
817 \r
818 5.5. High-level NegoEx Message Flow\r
819 \r
820 The following text art summarizes the protocol message flow:\r
821 \r
822 \r
823 \r
824 \r
825 \r
826 \r
827 \r
828 \r
829 \r
830 \r
831 \r
832 \r
833 \r
834 \r
835 \r
836 \r
837 \r
838 Zhu, et al. Expires January 15, 2009 [Page 15]\r
840 Internet-Draft NEGOEX July 2008\r
841 \r
842 \r
843 INITIATOR_NEGO\r
844 *INITIATOR_META_DATA\r
845 *AP_REQUEST\r
846 --------->\r
847 ACCEPTOR_NEGO\r
848 ACCEPTOR_META_DATA*+\r
849 --------- CHALLENGE*\r
850 \r
851 .\r
852 .\r
853 *AP_REQUEST\r
854 VERIFY --------->\r
855 CHALLENGE*\r
856 -------- VERIFY\r
857 * Indicates optional or situation-dependent messages that are\r
858 not always sent.\r
859 + Indicates there can be more than one instance.\r
860 \r
861 \r
862 6. Supporting GSS-API Extensions\r
863 \r
864 This section defined all the required GSS-API extensions required by\r
865 NegoEx.\r
866 \r
867 6.1. GSS_Query_meta_data\r
868 \r
869 TBD.\r
870 \r
871 6.2. GSS_Exchange_meta_data\r
872 \r
873 TBD.\r
874 \r
875 6.3. GSS_Query_mechanism_info\r
876 \r
877 TBD.\r
878 \r
879 6.4. GSS_Query_context_attr\r
880 \r
881 TBD.\r
882 \r
883 \r
884 7. Security Considerations\r
885 \r
886 TBD.\r
887 \r
888 \r
889 \r
890 \r
891 \r
892 \r
893 \r
894 Zhu, et al. Expires January 15, 2009 [Page 16]\r
896 Internet-Draft NEGOEX July 2008\r
897 \r
898 \r
899 8. Acknowledgements\r
900 \r
901 TBD.\r
902 \r
903 \r
904 9. IANA Considerations\r
905 \r
906 There is no action required for IANA.\r
907 \r
908 \r
909 10. Normative References\r
910 \r
911 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate\r
912 Requirement Levels", BCP 14, RFC 2119, March 1997.\r
913 \r
914 [RFC2743] Linn, J., "Generic Security Service Application Program\r
915 Interface Version 2, Update 1", RFC 2743, January 2000.\r
916 \r
917 [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for\r
918 Kerberos 5", RFC 3961, February 2005.\r
919 \r
920 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The\r
921 Kerberos Network Authentication Service (V5)", RFC 4120,\r
922 July 2005.\r
923 \r
924 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos\r
925 Version 5 Generic Security Service Application Program\r
926 Interface (GSS-API) Mechanism: Version 2", RFC 4121,\r
927 July 2005.\r
928 \r
929 [RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The\r
930 Simple and Protected Generic Security Service Application\r
931 Program Interface (GSS-API) Negotiation Mechanism",\r
932 RFC 4178, October 2005.\r
933 \r
934 \r
935 Appendix A. Protocol Data Structures and Constant Values\r
936 \r
937 This section complies all the protocol data structures and constant\r
938 values.\r
939 \r
940 #define MESSAGE_SIGNATURE 0x535458454f47454ei64\r
941 // "NEGOEXTS"\r
942 \r
943 struct\r
944 {\r
945 ULONG ByteArrayOffset; // each element contains a byte\r
946 ULONG ByteArrayLength;\r
947 \r
948 \r
949 \r
950 Zhu, et al. Expires January 15, 2009 [Page 17]\r
952 Internet-Draft NEGOEX July 2008\r
953 \r
954 \r
955 } BYTE_VECTOR;\r
956 \r
957 struct\r
958 {\r
959 ULONG AuthSchemeArrayOffset;\r
960 // each element contains an AUTH_SCHEME\r
961 USHORT AuthSchemeCount;\r
962 } AUTH_SCHEME_VECTOR;\r
963 \r
964 struct\r
965 {\r
966 ULONG ExtensionArrayOffset;\r
967 // each element contains an EXTENSION\r
968 USHORT ExtensionCount;\r
969 } EXTENSION_VECTOR;\r
970 \r
971 struct\r
972 {\r
973 ULONG ExtensionType; // negative extensions are critical\r
974 BYTE_VECTOR ExtensionValue;\r
975 } EXTENSION;\r
976 \r
977 //\r
978 // schemes defined for the checksum in the VERIFY message\r
979 //\r
980 \r
981 #define CHECKSUM_SCHEME_RFC3961 1\r
982 \r
983 struct\r
984 {\r
985 ULONG cbHeaderLength;\r
986 ULONG ChecksumScheme;\r
987 ULONG ChecksumType; // in the case of RFC3961 scheme, this is\r
988 // the RFC3961 checksum type\r
989 BYTE_VECTOR ChecksumValue;\r
990 } CHECKSUM;\r
991 \r
992 typedef GUID AUTH_SCHEME;\r
993 typedef GUID CONVERSATION_ID;\r
994 \r
995 enum\r
996 {\r
997 MESSAGE_TYPE_INITIATOR_NEGO = 0,\r
998 MESSAGE_TYPE_ACCEPTOR_NEGO,\r
999 MESSAGE_TYPE_INITIATOR_META_DATA,\r
1000 MESSAGE_TYPE_ACCEPTOR_META_DATA,\r
1001 MESSAGE_TYPE_CHALLENGE,\r
1002 // an exchange message from the acceptor\r
1003 \r
1004 \r
1005 \r
1006 Zhu, et al. Expires January 15, 2009 [Page 18]\r
1008 Internet-Draft NEGOEX July 2008\r
1009 \r
1010 \r
1011 MESSAGE_TYPE_AP_REQUEST,\r
1012 // an exchange message from the initiator\r
1013 MESSAGE_TYPE_VERIFY,\r
1014 MESSAGE_TYPE_ALERT,\r
1015 } MESSAGE_TYPE;\r
1016 \r
1017 struct\r
1018 {\r
1019 ULONG64 Signature; // contains MESSAGE_SIGNATURE\r
1020 MESSAGE_TYPE MessageType;\r
1021 ULONG SequenceNum; // the message sequence number of this,\r
1022 // conversation, starting with 0 and sequentially\r
1023 // incremented\r
1024 ULONG cbHeaderLength; // the header length of this message,\r
1025 // including the message specific header, excluding the\r
1026 // payload\r
1027 ULONG cbMessageLength; // the length of this message\r
1028 CONVERSATION_ID ConversationId;\r
1029 } MESSAGE_HEADER;\r
1030 \r
1031 struct\r
1032 {\r
1033 MESSAGE_HEADER Header;\r
1034 // MESSAGE_TYPE_INITIATOR_NEGO for the initiator,\r
1035 // MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor\r
1036 UCHAR Random[32];\r
1037 ULONG64 ProtocolVersion;\r
1038 // version of the protocol, this contains 0\r
1039 AUTH_SCHEME_VECTOR AuthSchemes;\r
1040 EXTENSION_VECTOR Extensions;\r
1041 } NEGO_MESSAGE;\r
1042 \r
1043 struct\r
1044 {\r
1045 MESSAGE_HEADER Header;\r
1046 // MESSAGE_TYPE_CHALLENGE for the acceptor,\r
1047 // or MESSAGE_TYPE_AP_REQUEST for the initiator\r
1048 // MESSAGE_TYPE_INITiATOR_META_DATA for\r
1049 // the initiator metadata\r
1050 // MESSAGE_TYPE_ACCEPTOR_META_DATA for\r
1051 // the acceptor metadata\r
1052 AUTH_SCHEME AuthScheme;\r
1053 BYTE_VECTOR Exchange;\r
1054 // contains the opaque handshake message for the\r
1055 // authentication scheme\r
1056 } EXCHANGE_MESSAGE;\r
1057 \r
1058 struct\r
1059 \r
1060 \r
1061 \r
1062 Zhu, et al. Expires January 15, 2009 [Page 19]\r
1064 Internet-Draft NEGOEX July 2008\r
1065 \r
1066 \r
1067 {\r
1068 MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY\r
1069 AUTH_SCHEME AuthScheme;\r
1070 CHECKSUM Checksum;\r
1071 // contains the checksum of all the previously\r
1072 // exchanged messages in the order they were sent.\r
1073 } VERIFY_MESSAGE;\r
1074 \r
1075 struct\r
1076 {\r
1077 ULONG AlertType;\r
1078 BYTE_VECTOR AlertValue;\r
1079 } ALERT;\r
1080 \r
1081 //\r
1082 // alert types\r
1083 //\r
1084 \r
1085 #define ALERT_TYPE_PULSE 1\r
1086 \r
1087 //\r
1088 // reason codes for the heartbeat message\r
1089 //\r
1090 \r
1091 #define ALERT_VERIFY_NO_KEY 1\r
1092 \r
1093 struct\r
1094 {\r
1095 ULONG cbHeaderLength;\r
1096 ULONG Reason;\r
1097 } ALERT_PULSE;\r
1098 \r
1099 struct\r
1100 {\r
1101 ULONG AlertArrayOffset; // the element is an ALERT\r
1102 USHORT AlertCount; // contains the number of alerts\r
1103 } ALERT_VECTOR;\r
1104 \r
1105 struct\r
1106 {\r
1107 MESSAGE_HEADER Header;\r
1108 AUTH_SCHEME AuthScheme;\r
1109 ULONG ErrorCode; // an NTSTATUS code\r
1110 ALERT_VECTOR Alerts;\r
1111 } ALERT_MESSAGE;\r
1112 \r
1113 \r
1114 \r
1115 \r
1116 \r
1117 \r
1118 Zhu, et al. Expires January 15, 2009 [Page 20]\r
1120 Internet-Draft NEGOEX July 2008\r
1121 \r
1122 \r
1123 Authors' Addresses\r
1124 \r
1125 Larry Zhu\r
1126 Microsoft Corporation\r
1127 One Microsoft Way\r
1128 Redmond, WA 98052\r
1129 US\r
1130 \r
1131 Email: lzhu@microsoft.com\r
1132 \r
1133 \r
1134 Kevin Damour\r
1135 Microsoft Corporation\r
1136 One Microsoft Way\r
1137 Redmond, WA 98052\r
1138 US\r
1139 \r
1140 Email: kdamour@microsoft.com\r
1141 \r
1142 \r
1143 Dave McPherson\r
1144 Microsoft Corporation\r
1145 One Microsoft Way\r
1146 Redmond, WA 98052\r
1147 US\r
1148 \r
1149 Email: davemm@microsoft.com\r
1150 \r
1151 \r
1152 \r
1153 \r
1154 \r
1155 \r
1156 \r
1157 \r
1158 \r
1159 \r
1160 \r
1161 \r
1162 \r
1163 \r
1164 \r
1165 \r
1166 \r
1167 \r
1168 \r
1169 \r
1170 \r
1171 \r
1172 \r
1173 \r
1174 Zhu, et al. Expires January 15, 2009 [Page 21]\r
1176 Internet-Draft NEGOEX July 2008\r
1177 \r
1178 \r
1179 Full Copyright Statement\r
1180 \r
1181 Copyright (C) The IETF Trust (2008).\r
1182 \r
1183 This document is subject to the rights, licenses and restrictions\r
1184 contained in BCP 78, and except as set forth therein, the authors\r
1185 retain all their rights.\r
1186 \r
1187 This document and the information contained herein are provided on an\r
1188 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS\r
1189 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND\r
1190 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS\r
1191 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF\r
1192 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED\r
1193 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
1194 \r
1195 \r
1196 Intellectual Property\r
1197 \r
1198 The IETF takes no position regarding the validity or scope of any\r
1199 Intellectual Property Rights or other rights that might be claimed to\r
1200 pertain to the implementation or use of the technology described in\r
1201 this document or the extent to which any license under such rights\r
1202 might or might not be available; nor does it represent that it has\r
1203 made any independent effort to identify any such rights. Information\r
1204 on the procedures with respect to rights in RFC documents can be\r
1205 found in BCP 78 and BCP 79.\r
1206 \r
1207 Copies of IPR disclosures made to the IETF Secretariat and any\r
1208 assurances of licenses to be made available, or the result of an\r
1209 attempt made to obtain a general license or permission for the use of\r
1210 such proprietary rights by implementers or users of this\r
1211 specification can be obtained from the IETF on-line IPR repository at\r
1212 http://www.ietf.org/ipr.\r
1213 \r
1214 The IETF invites any interested party to bring to its attention any\r
1215 copyrights, patents or patent applications, or other proprietary\r
1216 rights that may cover technology that may be required to implement\r
1217 this standard. Please address the information to the IETF at\r
1218 ietf-ipr@ietf.org.\r
1219 \r
1220 \r
1221 \r
1222 \r
1223 \r
1224 \r
1225 \r
1226 \r
1227 \r
1228 \r
1229 \r
1230 Zhu, et al. Expires January 15, 2009 [Page 22]\r
1232 \r