3
NETWORK WORKING GROUP L. Zhu
4
Internet-Draft K. Damour
5
Updates: 4178 (if approved) D. McPherson
6
Intended status: Informational Microsoft Corporation
7
Expires: January 15, 2009 July 14, 2008
10
The Extended GSS-API Negotiation Mechanism (NEGOEX)
15
By submitting this Internet-Draft, each author represents that any
16
applicable patent or other IPR claims of which he or she is aware
17
have been or will be disclosed, and any of which he or she becomes
18
aware will be disclosed, in accordance with Section 6 of BCP 79.
20
Internet-Drafts are working documents of the Internet Engineering
21
Task Force (IETF), its areas, and its working groups. Note that
22
other groups may also distribute working documents as Internet-
25
Internet-Drafts are draft documents valid for a maximum of six months
26
and may be updated, replaced, or obsoleted by other documents at any
27
time. It is inappropriate to use Internet-Drafts as reference
28
material or to cite them other than as "work in progress."
30
The list of current Internet-Drafts can be accessed at
31
http://www.ietf.org/ietf/1id-abstracts.txt.
33
The list of Internet-Draft Shadow Directories can be accessed at
34
http://www.ietf.org/shadow.html.
36
This Internet-Draft will expire on January 15, 2009.
40
This document defines the Extended Generic Security Service
41
Application Program Interface (GSS-API) Negotiation Mechanism
42
(NegoEx). NegoEx is a pseudo-security mechanism that logically
43
extends the SPNEGO protocol as defined in RFC4178.
45
The NegoEx protocol itself is a security mechanism negotiated by
46
SPNEGO. When selected as the common mechanism, NegoEx OPTIONALLY
47
adds a pair of meta-data messages for each negotiated security
48
mechanism. The meta-data exchange allows security mechanisms to
49
exchange auxiliary information such as trust configurations, thus
50
NegoEx provides additional flexibility than just exchanging object
54
Zhu, et al. Expires January 15, 2009 [Page 1]
56
Internet-Draft NEGOEX July 2008
59
identifiers in SPNEGO.
61
NegoEx preserves the optimistic token semantics of SPNEGO and applies
62
that recursively. Consequently a context establishment mechanism
63
token can be included in the initial NegoEx message, and NegoEx does
64
not require an extra round-trip when the initiator's optimistic token
65
is accepted by the target.
67
Similar to SPNEGO, NegoEx defines a few new GSS-API extensions that a
68
security mechanism MUST support in order to be negotiated by NegoEx.
69
This document defines these GSS-API extensions.
71
Unlike SPNEGO however, NegoEx defines its own way for signing the
72
protocol messages in order to protect the protocol negotiation. The
73
NegoEx message signing or verification can occur before the security
74
context for the negotiated real security mechanism is fully
110
Zhu, et al. Expires January 15, 2009 [Page 2]
112
Internet-Draft NEGOEX July 2008
117
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
118
2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 6
119
3. Presentation Language and Primitive Data Types . . . . . . . . 6
120
3.1. Basic Block Size . . . . . . . . . . . . . . . . . . . . . 7
121
3.2. Miscellaneous . . . . . . . . . . . . . . . . . . . . . . 7
122
3.3. Constants . . . . . . . . . . . . . . . . . . . . . . . . 7
123
3.4. Numbers . . . . . . . . . . . . . . . . . . . . . . . . . 7
124
3.5. Enum Types . . . . . . . . . . . . . . . . . . . . . . . . 7
125
3.6. Typedef Declarations . . . . . . . . . . . . . . . . . . . 8
126
3.7. Array Types . . . . . . . . . . . . . . . . . . . . . . . 8
127
3.8. Vector Types . . . . . . . . . . . . . . . . . . . . . . . 8
128
3.9. Constructed Types . . . . . . . . . . . . . . . . . . . . 9
129
4. Cryptographic Computations . . . . . . . . . . . . . . . . . . 10
130
5. The NegoEx Protocol . . . . . . . . . . . . . . . . . . . . . 11
131
5.1. Generation of the Initiator Initial Token . . . . . . . . 11
132
5.2. Receipt of the Initial Initiator Token and Generation
133
of the Initial Acceptor Response . . . . . . . . . . . . . 13
134
5.3. Receipt of the Acceptor Initial Response and
135
Completion of Authentication after the Negotiation
136
Phrase . . . . . . . . . . . . . . . . . . . . . . . . . . 14
137
5.4. Finalizing Negotiation . . . . . . . . . . . . . . . . . . 15
138
5.5. High-level NegoEx Message Flow . . . . . . . . . . . . . . 15
139
6. Supporting GSS-API Extensions . . . . . . . . . . . . . . . . 16
140
6.1. GSS_Query_meta_data . . . . . . . . . . . . . . . . . . . 16
141
6.2. GSS_Exchange_meta_data . . . . . . . . . . . . . . . . . . 16
142
6.3. GSS_Query_mechanism_info . . . . . . . . . . . . . . . . . 16
143
6.4. GSS_Query_context_attr . . . . . . . . . . . . . . . . . . 16
144
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
145
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
146
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
147
10. Normative References . . . . . . . . . . . . . . . . . . . . . 17
148
Appendix A. Protocol Data Structures and Constant Values . . . . 17
149
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
150
Intellectual Property and Copyright Statements . . . . . . . . . . 22
166
Zhu, et al. Expires January 15, 2009 [Page 3]
168
Internet-Draft NEGOEX July 2008
173
If more than one GSS-API mechanism is shared between the initator and
174
the acceptor, the Simple and Protected (GSS-API) Negotiation
175
Mechanism (SPNEGO) as defined in [RFC4178] can be deployed to choose
176
a mutually preferred one. This pseudo mechanism does well in the
177
most basic scenarios but suffers from a couple of drawbacks, notably:
179
o First, the SPNEGO negotiation model is inefficient when
180
negotiating based on mechanism specific configuration information.
181
SPNEGO negotiation is based on exchanging object identifiers only,
182
and it does not allow exchange of auxiliary information in any
183
other from. This is inefficient and often impractical in that one
184
object identifier effectively conveys only one bit of information.
186
o Secondly, the SPNEGO negotiation model is inadequate when the
187
choice cannot be made by the acceptor in the initial response. In
188
SPNEGO, the negotiation information is sent one-way from the
189
initiator for the acceptor to make a choice, and the acceptor must
190
choose one when it makes the initial response. This negotiation
191
model is counter intuitive. The selection of a security mechanism
192
is typically the result of selecting one type of credentials from
193
the available set, and the initiator typically does not wish to
194
reveal credentials information often associated with user
195
identities. In practice, in order to operate in this model, the
196
Kerberos GSS-API mechanism [RFC4121] must acquire the context
197
establishment token in the initial call to GSS_Init_sec_context().
198
If the initiator fails to acquire the initial Kerberos GSS-API
199
context token, it must not offer Kerberos; otherwise the SPNEGO
200
context negotiation will fail without being able to select the
201
next available mechanism that could work. Obtaining the initial
202
Kerberos GSS-API context token may require multiple round-trips of
203
network calls and the cost of the operation can be substantial.
204
It is suboptimal when multiple GSS-API mechanisms have to add the
205
extra cost that would not exist if the negotiated security
206
mechanism were selected based on configuration.
208
The Extended Generic Security Service Application Program Interface
209
(GSS-API) Negotiation Mechanism (NegoEx) is defined to address these
210
concerns. NegoEx is a pseudo security mechanism that is negotiated
211
by SPNEGO, and when negotiated, it can recursively negotiate real
214
Any security mechanism negotiated by NegoEx MUST support integrity
217
The basic form of NegoEx works as follows:
222
Zhu, et al. Expires January 15, 2009 [Page 4]
224
Internet-Draft NEGOEX July 2008
227
1. The initiator proposes a list of mechanisms in decreasing
228
preference order. For each of these mechanism, NegoEx
229
OPTIOINALLY includes a mechanism specific meta-data token. GSS-
230
API extensions are defined later in this document for NegoEx to
231
query the meta-data token for inclusion in the NegoEx message.
233
2. The acceptor then passes the meta-data token from the initiator
234
to the intended security mechanism. A meta-data token for a
235
security mechanism not supported on the acceptor side is ignored.
236
New GSS-API extensions are defined later in this document for a
237
security mechanism to consume the meta-data token. When
238
processing the received meta-data tokens, a security mechanism
239
that reports a failure is removed from the set of mutually
240
supported mechanisms. The acceptor then responds with the list
241
of mutually supported mechanisms in decreasing preference order.
242
For each of these mechanism, NegoEx again OPTIOINALLY supplies a
243
mechanism specific meta-data token in the response. These meta-
244
data tokens are returned to NegoEx via new GSS-API extensions as
245
described in the initial step.
247
3. The initiator then passes the meta-data tokens to the intended
248
security mechanisms by invoking the new GSS-API extensions. When
249
processing the received meta-data token, a security mechanism
250
that reports a failure is removed from the set of mutually
251
supported mechanisms for this negotiation context. The initiator
252
then selects one from the set of mutually-supported mechanisms.
253
If more than one security mechanism is available, unless
254
otherwise specified, the preferred one in the acceptor's
255
preference order SHOULD be selected. Once the common security
256
mechanism is identified, the security mechanism may also
257
negotiate mechanism-specific options during its context
258
establishments. This will be inside the mechanism tokens, and
259
invisible to the NegoEx protocol.
261
4. The selected security mechanism provides keying materials to
262
NegoEx, and NegoEx then signs and verifies the negotiation NegoEx
263
messages to protect the negotiation.
265
5. The initiator and the acceptor proceed to exchange tokens until
266
the GSS-API context for selected security mechanism is
267
established. Once the security context is established, the per-
268
message tokens are generated and verified in accordance with the
269
selected security mechanism.
271
NegoEx does not work outside of SPNEGO. When negotiated by SPNEGO,
272
NegoEx uses the concepts developed in the GSS-API specification
273
[RFC2743]. The negotiation data is encapsulated in context-level
274
tokens. Therefore, callers of the GSS-API do not need to be aware of
278
Zhu, et al. Expires January 15, 2009 [Page 5]
280
Internet-Draft NEGOEX July 2008
283
the existence of the negotiation tokens but only of the SPENGO
284
pseudo-security mechanism.
286
In its basic form NegoEx requires at least one extra round-trip.
287
Network connection setup is a critical performance characteristic of
288
any network infrastructure and extra round trips over WAN links,
289
packet radio networks, etc. really make a difference. In order to
290
avoid such an extra round trip the initial security token of the
291
preferred mechanism for the initiator may be embedded in the initial
292
NegoEx token. The optimistic mechanism token may be accompanied by
293
the meta-data tokens and the optimistic mechanism token MUST be that
294
of the first mechanism in the list of the mechanisms proposed by the
295
initiator. The NegoEx message that contains signatures for
296
protecting the NegoEx negotiation can also be included along with the
297
mechanism token. If the target preferred mechanism matches the
298
initiator's preferred mechanism, and when the NegoEx negotiation
299
protection messages are included along with the mechanism token, no
300
additional round trips are incurred by using the NegoEx protocol with
303
NegoEx does not update the ASN.1 structures of SPNEGO in that a large
304
deployment of SPNEGO does not have the ASN.1 extensibility marker in
305
the message definition. There is no change to the SPNEGO messages.
307
NegoEx does not use ASN.1 encoding and it uses simple C structures
308
encoded in little endian for all its messages.
310
The rest of the document is organized as follows: Section 3 defines
311
the encoding of NegoEx data structures and all the primitive data
312
types. Section 4 describes the cryptographic framework required by
313
the NegoEx for protecting the NegoEx negotiation. Section 5 defines
314
the NegoEx messages and the NegoEx protocol. Section 6 defines the
315
new GSS-API extensions that a security mechanism MUST support in
316
order to be negotiated by NegoEx. These then are followed by the
317
security considerations section. Lastly Appendix A contains all the
318
protocol constructs and constants.
321
2. Requirements Terminology
323
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
324
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
325
document are to be interpreted as described in [RFC2119].
328
3. Presentation Language and Primitive Data Types
330
The following very basic and somewhat casually defined presentation
334
Zhu, et al. Expires January 15, 2009 [Page 6]
336
Internet-Draft NEGOEX July 2008
339
syntax will be used in all NegoEx messages. Although it resembles
340
the programming language "C" in its syntax, it would be risky to draw
341
too many parallels. The purpose of this presentation language is to
342
document NegoEx only; it has no general application beyond that
345
This section also defines all the primitive data types. The
346
semantics of the data types is explained in the next section.
348
3.1. Basic Block Size
350
The representation of all data items is explicitly specified. The
351
basic data block size is one octet. Multiple octet data items are
352
concatenations of octets, from left to right, from top to bottom
353
Unless otherwise specific a multi-octet numeric is in little endian
354
order with the least significant octet first.
358
Comments start with "//"' and continue until the end of the line.
362
Constants are denoted using "#define" followed by the symbolic name
363
and then the constant value.
367
UCHAR is the data type for a one-octet number.
369
ULONG is the data type for a 4-octet number encoded in little enidan.
371
USHORT is the data type for a 2-octet number encoded in little
374
ULONG64 is the data type for a 8-octet number encoded in little
377
GUID is the data type for a 16-octet number encoded in little endian.
381
An enum type is the data type for a number with a small number of
382
permissible values. An instance of an enum type is a 4-octet number
383
encoded in little endian.
385
The definition of an enum type follows the simple "C" convention.
390
Zhu, et al. Expires January 15, 2009 [Page 7]
392
Internet-Draft NEGOEX July 2008
395
MESSAGE_TYPE is an enum type defined as follows:
399
MESSAGE_TYPE_INITIATOR_NEGO = 0,
400
MESSAGE_TYPE_ACCEPTOR_NEGO,
401
MESSAGE_TYPE_INITIATOR_META_DATA,
402
MESSAGE_TYPE_ACCEPTOR_META_DATA,
403
MESSAGE_TYPE_CHALLENGE,
404
// an exchange message from the acceptor
405
MESSAGE_TYPE_AP_REQUEST,
406
// an exchange message from the initiator
411
MESSAGE_TYPE_INITIATOR_NEGO has the value 0, and MESSAGE_TYPE_ALERT
414
3.6. Typedef Declarations
416
A typedef creates a synonym for the type. This is used to create
417
more meaningful names for existing types.
419
The following two type synonyms are defined.
421
typedef GUID AUTH_SCHEME;
422
typedef GUID CONVERSATION_ID;
426
Arrays are a data structure which holds multiple variables of the
427
same data type consecutively and the number of elements is fixed. An
428
array is declared using "C" convention. For example, the following
429
defines an array of 32 octets.
435
Vectors are a data structure which holds multiple variables of the
436
same data type consecutively and the number of elements is not fixed.
437
A vector contains a fixed length header followed by a variable length
438
payload. The header of a vector structure contains the count of
439
elements and the offset to the payload. In this document all the
440
offset fields start from the beginning of the containing NegoEx
441
message. The size of each element is specified by the vector type
446
Zhu, et al. Expires January 15, 2009 [Page 8]
448
Internet-Draft NEGOEX July 2008
451
The following vector types are defined.
455
ULONG ByteArrayOffset; // each element contains an octet/byte
456
ULONG ByteArrayLength;
459
BYTE_VECTOR encapsulates a variable length array of octets (or bytes)
460
that are stored consecutively. Each element in is a byte (8 bits).
464
ULONG AuthSchemeArrayOffset;
465
// each element contains an AUTH_SCHEME
466
USHORT AuthSchemeCount;
467
} AUTH_SCHEME_VECTOR;
469
AUTH_SCHEME_VECTOR encapsulates a variable length array of
470
AUTH_SCHEMEs that are stored consecutively. Each element is a
471
structure of the type AUTH_SCHEME.
475
ULONG ExtensionArrayOffset;
476
// each element contains an EXTENSION
477
USHORT ExtensionCount;
480
EXTENSION_VECTOR encapsulates a variable length array of EXTENSIONs
481
that are stored consecutively. Each element is a structure of the
484
3.9. Constructed Types
486
Structure types may be constructed from primitive types for
487
convenience. Each specification declares a new, unique type. The
488
syntax for definition is much like that of C.
498
Structure definitions may be embedded.
502
Zhu, et al. Expires January 15, 2009 [Page 9]
504
Internet-Draft NEGOEX July 2008
507
The following types are defined as constructed types:
511
ULONG ExtensionType; // negative extensions are critical
512
BYTE_VECTOR ExtensionValue;
515
An extension has two fields. The ExtensionType field indicates how
516
the extension data should be interpreted. The ExtensionValue field
517
contains the extension data.
520
// schemes defined for the checksum in the VERIFY message
525
ULONG cbHeaderLength;
526
ULONG ChecksumScheme;
527
ULONG ChecksumType; // in the case of RFC3961 scheme, this is
528
// the RFC3961 checksum type
529
BYTE_VECTOR ChecksumValue;
532
The CHECKSUM structure contains 4 fields. The cbHeaderLength length
533
contains the length of the structure defintion in octets, and this
534
field has a value of 20.
536
The ChecksumScheme field describes how checksum is computed and
537
verified. Currently only one value is defined.
539
#define CHECKSUM_SCHEME_RFC3961 1
541
When the value of the ChecksumScheme field is 1
542
(CHECKSUM_SCHEME_RFC3961), the ChecksumValue field contains a
543
sequence of octets computed according to [RFC3961] and the
544
ChecksumType field contains the checksum type value defined according
548
4. Cryptographic Computations
550
The message signing and verification in NegoEx is based on [RFC3961].
551
[RFC3961] is used here as a generic framework and this application is
552
not Kerberos specific.
554
A security mechanism MUST support [RFC3961] in order to be negotiated
558
Zhu, et al. Expires January 15, 2009 [Page 10]
560
Internet-Draft NEGOEX July 2008
566
5. The NegoEx Protocol
568
This section describes the NegoEx protocol and it defines NegoEx
569
messages in the order that the messages can appear on the wire. The
570
enum type MESSAGE_TYPE defined in Section 3.5 lists all NegoEx
571
message types. A GSS-API context token for NegoEx consists of one or
572
more NegoEx messages. If there are more than one NegoEx message,
573
these messages are concatenated together. The smallest data unit for
574
NegoEx to compute the checksum for negotiation protection is a NegoEx
575
message. Note that NegoEx is not a GSS-API mechanism itself and the
576
initial NegoEx context establishment token does not follow the
577
mechanism-independent token format defined in Section 3.1 of
580
A security mechanism negotiated by NegoEx is identified by a unique
581
identifier of the data type AUTH_SCHEME defined in Section 3.5. The
582
value of the security mechanism is returned to NegoEx via the
583
GSS_Query_mechanism_info() GSS-API extension as defined in Section 6.
585
The object identifier of the NegoEx within SPNEGO is iso(1)
586
identified-organization(3) dod(6) internet(1) private(4)
587
enterprise(1) microsoft (311) security(2) mechanisms(2) negoex(30).
588
Note that NegoEx does not work outside of SPNEGO and it is not GSS-
591
5.1. Generation of the Initiator Initial Token
593
The GSS-API initiator makes the first call to GSS_Init_sec_context()
594
with no input token, and the output token starts as a NEGO_MESSAGE
595
message with the MESSAGE_TYPE_INITIATOR_NEGO message type.
614
Zhu, et al. Expires January 15, 2009 [Page 11]
616
Internet-Draft NEGOEX July 2008
621
ULONG64 Signature; // contains MESSAGE_SIGNATURE
622
MESSAGE_TYPE MessageType;
623
ULONG SequenceNum; // the message sequence number of this,
624
// conversation, starting with 0 and sequentially
626
ULONG cbHeaderLength; // the header length of this message,
627
// including the message specific header, excluding the
629
ULONG cbMessageLength; // the length of this message
630
CONVERSATION_ID ConversationId;
635
MESSAGE_HEADER Header;
636
// MESSAGE_TYPE_INITIATOR_NEGO for the initiator,
637
// MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor
639
ULONG64 ProtocolVersion;
640
// version of the protocol, this contains 0
641
AUTH_SCHEME_VECTOR AuthSchemes;
642
EXTENSION_VECTOR Extensions;
645
The initiator randomly generates a ConversationID and fills the
646
common header. The ConversationID in subsequent NegoEx messages MUST
647
remain the same. The initiator also fills the Random field using a
648
secure random number generator. The initiator fills the AuthSchemes
649
with available security mechanisms supported by the initiator in
650
decreasing preference order.
652
The extensions field contains NegoEx extensions for future
653
extensibility. There is no extension defined in this document. All
654
negative extension types (the highest bit is set to 1) are critical.
655
If the receiver does not understand a critical extension, the
656
authentication attempt must be rejected.
658
The initiator can OPTIONALLY include a meta-data token, one for each
659
available security mechanism.
661
A meta-data token is returned to NegoEx for a security mechanism
662
using GSS_Query_meta_data() extension as defined in Section 6. A
663
meta-data token is encapsulated in an EXCHANGE message with the
664
message type MESSAGE_TYPE_INITIATOR_META_DATA.
670
Zhu, et al. Expires January 15, 2009 [Page 12]
672
Internet-Draft NEGOEX July 2008
677
MESSAGE_HEADER Header;
678
// MESSAGE_TYPE_CHALLENGE for the acceptor,
679
// or MESSAGE_TYPE_AP_REQUEST for the initiator
680
// MESSAGE_TYPE_INITIATOR_META_DATA for
681
// the initiator metadata
682
// MESSAGE_TYPE_ACCEPTOR_META_DATA for
683
// the acceptor metadata
684
AUTH_SCHEME AuthScheme;
685
BYTE_VECTOR Exchange;
686
// contains the opaque handshake message for the
687
// authentication scheme
690
The AuthScheme field signifies the security mechanism for which the
691
EXCHANGE message is targeted. If a security mechanism fails to
692
produce the metadata token, it should be removed from the list of
693
supported security mechanism for this negotiation context.
695
If there are more than one exchange messages, the order in which the
696
exchange message is included bears no significance. In other words,
697
the exchange messages are in an unordered set. The NEGO_MESSAGE MAY
698
be followed by a set of MESSAGE_TYPE_INITIATOR_META_DATA messages as
699
described above, in which case all the NegoEx messages concatenated
700
are returned as a single input token.
702
The first mechanism in the initiator proposed list can OPTIONALLY
703
include its initial context context in an AP_REQUEST message.
705
Both an AP_REQUSET(short for MESSAGE_TYPE_AP_REQUEST) message and a
706
INITIATOR_META_DATA(short for MESSAGE_TYPE_INITIATOR_META_DATA)
707
message are instances of the EXCHANGE_MESSAGE structure with
708
different message type values. An AP_REQUEST message contains the
709
type MESSAGE_TYPE_AP_REQUEST while an INITIATOR_META_DATA message
710
contains the type MESSAGE_TYPE_INITIATOR_META_DATA.
712
5.2. Receipt of the Initial Initiator Token and Generation of the
713
Initial Acceptor Response
715
Upon receipt of the NEGO_MESSAGE from the initiator, the acceptor
716
verifies the NEGO_MESSAGE to make sure it is well-formed. The
717
acceptor then computes the list of authentication schemes that are
718
mutually supported by examining the set of security mechanisms
719
proposed by the initiator and the meta-data tokens from the
720
initiator. The meta-data tokens are passed to the security mechanism
721
via GSS_Exchange_meta_data() as defined in Section 6.
726
Zhu, et al. Expires January 15, 2009 [Page 13]
728
Internet-Draft NEGOEX July 2008
731
The acceptor MUST examine the NegoEx extensions in the NEGO_MESSAGE.
732
If there is an unknown critical extension, the authentication must be
735
The acceptor's response starts as a NEGO_MESSAGE but with the
736
MESSAGE_TYPE_ACCEPTOR_NEGO. The AuthSchemes field contains the list
737
of mutually supported security mechanism in decreasing preference
738
order of the acceptor. The acceptor does not need to honor the
739
preference order proposed by the initiator when computing its
742
The acceptor can OPTIONALLY include a meta-data token, one for each
743
available security mechanism.
745
A meta-data token is returned to NegoEx for a security mechanism
746
using GSS_Query_meta_data() extension as defined in Section 6. A
747
meta-data token is encapsulated in an EXCHANGE message with the
748
message type MESSAGE_TYPE_ACCEPTOR_META_DATA. For a given security
749
mechanism if a meta-token is received from the initiator,
750
GSS_Query_meta_data() MUST be invoked on the acceptor side for that
751
security mechanism, and the output meta-data token, if present, MUST
752
be included in the NegoEx reply.
754
5.3. Receipt of the Acceptor Initial Response and Completion of
755
Authentication after the Negotiation Phrase
757
Upon receipt of the initial response from the acceptor, the initial
758
verifies the NEGO_MESSAGE to make sure it is well-formed. The
759
initiator then computes the list of authentication schemes that are
760
mutually supported by examining the set of security mechanisms
761
returned by the acceptor and the meta-data tokens from the acceptor
762
The meta-data tokens are passed to the security mechanism via
763
GSS_Exchange_meta_data() as defined in Section 6.
765
The initiator MUST examine the NegoEx extensions in the NEGO_MESSAGE.
766
If there is an unknown critical extension, the authentication must be
769
After the initial exchange of NEGO_MESSAGE messages, the initiator
770
MUST choose the negotiated security mechanism. The negotiated
771
security mechanism cannot be changed once it is selected.
773
The initiator and the acceptor can then proceed to exchange handshake
774
messages as determined by the negotiated security mechanism until its
775
authentication context is established. The context tokens of the
776
negotiated security mechanism are encapsulated in an
777
EXCHANGE_MESSAGE. If the context token is from the initiator, the
778
EXCHANGE_MESSAGE message has the message type
782
Zhu, et al. Expires January 15, 2009 [Page 14]
784
Internet-Draft NEGOEX July 2008
787
MESSAGE_TYPE_AP_REQUEST; otherwise, the message type is
788
MESSAGE_TYPE_CHALLENGE.
790
5.4. Finalizing Negotiation
792
Whenever there is a shared key established returned by
793
GSS_Query_context_attr(NEGOEX_SESSION_KEYS) as defined in Section 6,,
794
a VERIFY message is produced and included in the output token. The
795
returned protocol key is used as the base key in the parlance of
796
RFC3961 to sign all the NegoEx messages in the negotiation context.
798
A VERIFY message is a VERIFY_MESSAGE structure. The AuthScheme field
799
signifies from which security mechanism the protocol key was
800
obtained. The checksum is computed based on RFC3961 and the key
801
usage number is 23 for the message is signed by the initiator, 25
802
otherwise. The checksum is performed over all the previous NegoEx
803
messages in the context negotiation.
807
MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY
808
AUTH_SCHEME AuthScheme;
810
// contains the checksum of all the previously
811
// exchanged messages in the order they were sent.
814
Note that the VERIFY_MESSAGE message can be included before the
815
security context for the negotiated security mechanism is fully
818
5.5. High-level NegoEx Message Flow
820
The following text art summarizes the protocol message flow:
838
Zhu, et al. Expires January 15, 2009 [Page 15]
840
Internet-Draft NEGOEX July 2008
857
* Indicates optional or situation-dependent messages that are
859
+ Indicates there can be more than one instance.
862
6. Supporting GSS-API Extensions
864
This section defined all the required GSS-API extensions required by
867
6.1. GSS_Query_meta_data
871
6.2. GSS_Exchange_meta_data
875
6.3. GSS_Query_mechanism_info
879
6.4. GSS_Query_context_attr
884
7. Security Considerations
894
Zhu, et al. Expires January 15, 2009 [Page 16]
896
Internet-Draft NEGOEX July 2008
904
9. IANA Considerations
906
There is no action required for IANA.
909
10. Normative References
911
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
912
Requirement Levels", BCP 14, RFC 2119, March 1997.
914
[RFC2743] Linn, J., "Generic Security Service Application Program
915
Interface Version 2, Update 1", RFC 2743, January 2000.
917
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for
918
Kerberos 5", RFC 3961, February 2005.
920
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
921
Kerberos Network Authentication Service (V5)", RFC 4120,
924
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
925
Version 5 Generic Security Service Application Program
926
Interface (GSS-API) Mechanism: Version 2", RFC 4121,
929
[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
930
Simple and Protected Generic Security Service Application
931
Program Interface (GSS-API) Negotiation Mechanism",
932
RFC 4178, October 2005.
935
Appendix A. Protocol Data Structures and Constant Values
937
This section complies all the protocol data structures and constant
940
#define MESSAGE_SIGNATURE 0x535458454f47454ei64
945
ULONG ByteArrayOffset; // each element contains a byte
946
ULONG ByteArrayLength;
950
Zhu, et al. Expires January 15, 2009 [Page 17]
952
Internet-Draft NEGOEX July 2008
959
ULONG AuthSchemeArrayOffset;
960
// each element contains an AUTH_SCHEME
961
USHORT AuthSchemeCount;
962
} AUTH_SCHEME_VECTOR;
966
ULONG ExtensionArrayOffset;
967
// each element contains an EXTENSION
968
USHORT ExtensionCount;
973
ULONG ExtensionType; // negative extensions are critical
974
BYTE_VECTOR ExtensionValue;
978
// schemes defined for the checksum in the VERIFY message
981
#define CHECKSUM_SCHEME_RFC3961 1
985
ULONG cbHeaderLength;
986
ULONG ChecksumScheme;
987
ULONG ChecksumType; // in the case of RFC3961 scheme, this is
988
// the RFC3961 checksum type
989
BYTE_VECTOR ChecksumValue;
992
typedef GUID AUTH_SCHEME;
993
typedef GUID CONVERSATION_ID;
997
MESSAGE_TYPE_INITIATOR_NEGO = 0,
998
MESSAGE_TYPE_ACCEPTOR_NEGO,
999
MESSAGE_TYPE_INITIATOR_META_DATA,
1000
MESSAGE_TYPE_ACCEPTOR_META_DATA,
1001
MESSAGE_TYPE_CHALLENGE,
1002
// an exchange message from the acceptor
1006
Zhu, et al. Expires January 15, 2009 [Page 18]
1008
Internet-Draft NEGOEX July 2008
1011
MESSAGE_TYPE_AP_REQUEST,
1012
// an exchange message from the initiator
1013
MESSAGE_TYPE_VERIFY,
1019
ULONG64 Signature; // contains MESSAGE_SIGNATURE
1020
MESSAGE_TYPE MessageType;
1021
ULONG SequenceNum; // the message sequence number of this,
1022
// conversation, starting with 0 and sequentially
1024
ULONG cbHeaderLength; // the header length of this message,
1025
// including the message specific header, excluding the
1027
ULONG cbMessageLength; // the length of this message
1028
CONVERSATION_ID ConversationId;
1033
MESSAGE_HEADER Header;
1034
// MESSAGE_TYPE_INITIATOR_NEGO for the initiator,
1035
// MESSAGE_TYPE_ACCEPTOR_NEGO for the acceptor
1037
ULONG64 ProtocolVersion;
1038
// version of the protocol, this contains 0
1039
AUTH_SCHEME_VECTOR AuthSchemes;
1040
EXTENSION_VECTOR Extensions;
1045
MESSAGE_HEADER Header;
1046
// MESSAGE_TYPE_CHALLENGE for the acceptor,
1047
// or MESSAGE_TYPE_AP_REQUEST for the initiator
1048
// MESSAGE_TYPE_INITiATOR_META_DATA for
1049
// the initiator metadata
1050
// MESSAGE_TYPE_ACCEPTOR_META_DATA for
1051
// the acceptor metadata
1052
AUTH_SCHEME AuthScheme;
1053
BYTE_VECTOR Exchange;
1054
// contains the opaque handshake message for the
1055
// authentication scheme
1062
Zhu, et al. Expires January 15, 2009 [Page 19]
1064
Internet-Draft NEGOEX July 2008
1068
MESSAGE_HEADER Header; // MESSAGE_TYPE_VERIFY
1069
AUTH_SCHEME AuthScheme;
1071
// contains the checksum of all the previously
1072
// exchanged messages in the order they were sent.
1078
BYTE_VECTOR AlertValue;
1085
#define ALERT_TYPE_PULSE 1
1088
// reason codes for the heartbeat message
1091
#define ALERT_VERIFY_NO_KEY 1
1095
ULONG cbHeaderLength;
1101
ULONG AlertArrayOffset; // the element is an ALERT
1102
USHORT AlertCount; // contains the number of alerts
1107
MESSAGE_HEADER Header;
1108
AUTH_SCHEME AuthScheme;
1109
ULONG ErrorCode; // an NTSTATUS code
1110
ALERT_VECTOR Alerts;
1118
Zhu, et al. Expires January 15, 2009 [Page 20]
1120
Internet-Draft NEGOEX July 2008
1126
Microsoft Corporation
1131
Email: lzhu@microsoft.com
1135
Microsoft Corporation
1140
Email: kdamour@microsoft.com
1144
Microsoft Corporation
1149
Email: davemm@microsoft.com
1174
Zhu, et al. Expires January 15, 2009 [Page 21]
1176
Internet-Draft NEGOEX July 2008
1179
Full Copyright Statement
1181
Copyright (C) The IETF Trust (2008).
1183
This document is subject to the rights, licenses and restrictions
1184
contained in BCP 78, and except as set forth therein, the authors
1185
retain all their rights.
1187
This document and the information contained herein are provided on an
1188
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1189
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
1190
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
1191
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
1192
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1193
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1196
Intellectual Property
1198
The IETF takes no position regarding the validity or scope of any
1199
Intellectual Property Rights or other rights that might be claimed to
1200
pertain to the implementation or use of the technology described in
1201
this document or the extent to which any license under such rights
1202
might or might not be available; nor does it represent that it has
1203
made any independent effort to identify any such rights. Information
1204
on the procedures with respect to rights in RFC documents can be
1205
found in BCP 78 and BCP 79.
1207
Copies of IPR disclosures made to the IETF Secretariat and any
1208
assurances of licenses to be made available, or the result of an
1209
attempt made to obtain a general license or permission for the use of
1210
such proprietary rights by implementers or users of this
1211
specification can be obtained from the IETF on-line IPR repository at
1212
http://www.ietf.org/ipr.
1214
The IETF invites any interested party to bring to its attention any
1215
copyrights, patents or patent applications, or other proprietary
1216
rights that may cover technology that may be required to implement
1217
this standard. Please address the information to the IETF at
1230
Zhu, et al. Expires January 15, 2009 [Page 22]
added
removed
doc/standardisation/draft-zhu-negoex-01.txt
