1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
|
<Network Working Group> Larry Zhu
Internet Draft Karthik Jaganathan
Updates: 1964 Microsoft
Category: Standards Track Sam Hartman
draft-ietf-krb-wg-gssapi-cfx-02.txt MIT
September 29, 2003
Expires: March 29, 2004
The Kerberos Version 5 GSS-API Mechanism: Version 2
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC-2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo defines protocols, procedures, and conventions to be
employed by peers implementing the Generic Security Service
Application Program Interface (GSS-API as specified in [RFC-2743])
when using the Kerberos Version 5 mechanism (as specified in
[KRBCLAR]).
[RFC-1964] is updated and incremental changes are proposed in
response to recent developments such as the introduction of Kerberos
crypto framework [KCRYPTO]. These changes support the inclusion of
new cryptosystems based on crypto profiles [KCRYPTO], by defining
new per-message and context-deletion tokens along with their
encryption and checksum algorithms.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119].
1. Introduction
Zhu Internet Draft 1
Kerberos Version 5 GSS-API September 2003
[KCRYPTO] defines a generic framework for describing encryption and
checksum types to be used with the Kerberos protocol and associated
protocols.
[RFC-1964] describes the GSS-API mechanism for Kerberos Version 5.
It defines the format of context initiation, per-message and context
deletion tokens and uses algorithm identifiers for each cryptosystem
in per message and context deletion tokens.
The approach taken in this document obviates the need for algorithm
identifiers. This is accomplished by using the same encryption and
checksum algorithms specified by the crypto profile [KCRYPTO] for
the session key or subkey that is created during context
negotiation. Message layouts of the per-message and context
deletion tokens are therefore revised to remove algorithm indicators
and also to add extra information to support the generic crypto
framework [KCRYPTO].
Tokens transferred between GSS-API peers for security context
initiation are also described in this document. The data elements
exchanged between a GSS-API endpoint implementation and the Kerberos
KDC are not specific to GSS-API usage and are therefore defined
within [KRBCLAR] rather than within this specification.
The new token formats specified in this memo MUST be used with all
"newer" encryption types [KRBCLAR] and MAY be used with "older"
encryption types, provided that the initiator and acceptor know,
from the context establishment, that they can both process these new
token formats.
"Newer" encryption types are those which have been specified along
with or since the new Kerberos cryptosystem specification [KCRYPTO],
as defined in section 3.1.3 of [KRBCLAR].
Note that in this document, the term "little endian order" is used
for brevity to refer to the least-significant-byte-first encoding,
while the term "big endian order" is for the most-significant-byte-
first encoding.
2. Key Derivation for Per-Message and Context Deletion Tokens
To limit the exposure of a given key, [KCRYPTO] adopted "one-way"
"entropy-preserving" derived keys, for different purposes or key
usages, from a base key or protocol key. This document defines four
key usage values below for signing and sealing messages:
Name Value
-------------------------------------
KG-USAGE-ACCEPTOR-SEAL 22
KG-USAGE-ACCEPTOR-SIGN 23
KG-USAGE-INITIATOR-SEAL 24
KG-USAGE-INITIATOR-SIGN 25
Zhu Internet Draft 2
Kerberos Version 5 GSS-API September 2003
When the sender is the context acceptor, KG-USAGE-ACCEPTOR-SIGN is
used as the usage number in the key derivation function for deriving
keys to be used in MIC and context deletion tokens, and KG-USAGE-
ACCEPTOR-SEAL is used for Wrap tokens; similarly when the sender is
the context initiator, KG-USAGE-INITIATOR-SIGN is used as the usage
number in the key derivation function for MIC and context deletion
tokens, KG-USAGE-INITIATOR-SEAL is used for Wrap Tokens. Even if
the Wrap token does not provide for confidentiality the same usage
values specified above are used.
During context initiation, the acceptor MAY assert a subkey, and if
so, subsequent messages MUST use this subkey as the protocol key and
these messages MUST be flagged as "AcceptorSubkey" as described in
section 4.2.2.
3. Quality of Protection
The GSS-API specification [RFC-2743] provides for Quality of
Protection (QOP) values that can be used by applications to request
a certain type of encryption or signing. A zero QOP value is used
to indicate the "default" protection; applications which use the
default QOP are not guaranteed to be portable across implementations
or even inter-operate with different deployment configurations of
the same implementation. Using an algorithm that is different from
the one for which the key is defined may not be appropriate.
Therefore, when the new method in this document is used, the QOP
value is ignored.
The encryption and checksum algorithms in per-message and context
deletion tokens are now implicitly defined by the algorithms
associated with the session key or subkey. Algorithms identifiers
as described in [RFC-1964] are therefore no longer needed and
removed from the new token headers.
4. Definitions and Token Formats
This section provides terms and definitions, as well as descriptions
for tokens specific to the Kerberos Version 5 GSS-API mechanism.
4.1. Initial Context Tokens
Per [RFC-2743], all context initiation tokens emitted by the
Kerberos V5 GSS-API mechanism will have the framing shown below:
GSS-API DEFINITIONS ::=
BEGIN
MechType ::= OBJECT IDENTIFIER
-- representing Kerberos V5 mechanism
GSSAPI-Token ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
Zhu Internet Draft 3
Kerberos Version 5 GSS-API September 2003
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
END
The innerToken field starts with a two-byte token-identifier
(TOK_ID) expressed in big endian order, followed by a Kerberos
message.
Here are the TOK_ID values used in the initial tokens:
Token TOK_ID Value in Hex
-----------------------------------------
KRB_AP_REQUEST 01 00
KRB_AP_REPLY 02 00
KRB_ERROR 03 00
Where Kerberos message KRB_AP_REQUEST, KRB_AP_REPLY, and KRB_ERROR
are defined in [KRBCLAR].
If an unknown token ID is received in the first context token, the
receiver MUST return GSS_S_CONTINUE_NEEDED major status, and the
returned output token MUST contain a KRB_ERROR message with the
error code KRB_AP_ERR_MSG_TYPE [KRBCLAR].
4.1.1. Authenticator Checksum
The authenticator in the KRB_AP_REQ message MUST include the
optional sequence number and the checksum field. The checksum field
is used to convey service flags, channel bindings, and optional
delegation information. It MUST have a type of 0x8003. The length
of the checksum MUST be 24 bytes when delegation is not used. When
delegation is used, a ticket-granting ticket will be transferred in
a KRB_CRED message. The ticket SHOULD have its forwardable flag
set. The KRB_CRED message MUST be encrypted in the session key of
the ticket used to authenticate the context.
The format of the authenticator checksum field is as follows.
Byte Name Description
-----------------------------------------------------------------
0..3 Lgth Number of bytes in Bnd field; Currently contains
hex value 10 00 00 00 (16, represented in little-
endian order)
4..19 Bnd Channel binding information, as describe in
section 4.1.1.2.
20..23 Flags Four-byte context-establishment flags in little-
endian order as described in section 4.1.1.1.
24..25 DlgOpt The Delegation Option identifier (=1) [optional]
26..27 Dlgth The length of the Deleg field [optional]
Zhu Internet Draft 4
Kerberos Version 5 GSS-API September 2003
28..n Deleg A KRB_CRED message (n = Dlgth + 29) [optional]
4.1.1.1. Checksum Flags Field
The checksum "Flags" field is used to convey service options or
extension negotiation information. The following context
establishment flags are defined in [RFC-2744].
Flag Name Value
---------------------------------
GSS_C_DELEG_FLAG 1
GSS_C_MUTUAL_FLAG 2
GSS_C_REPLAY_FLAG 4
GSS_C_SEQUENCE_FLAG 8
GSS_C_CONF_FLAG 16
GSS_C_INTEG_FLAG 32
GSS_C_ANON_FLAG 64
Context establishment flags are exposed to the calling application.
If the calling application desires a particular service option then
it requests that option via GSS_Init_sec_context() [RFC-2743]. An
implementation that supports a particular option or extension SHOULD
then set the appropriate flag in the checksum Flags field.
The receiver MUST ignore unknown checksum flags.
4.1.1.2. Channel Binding Information
Channel bindings are user-specified tags to identify a given context
to the peer application. These tags are intended to be used to
identify the particular communications channel that carries the
context.
When using C language bindings, channel bindings are communicated to
the GSS-API using the following structure [RFC-2744]:
typedef struct gss_channel_bindings_struct {
OM_uint32 initiator_addrtype;
gss_buffer_desc initiator_address;
OM_uint32 acceptor_addrtype;
gss_buffer_desc acceptor_address;
gss_buffer_desc application_data;
} *gss_channel_bindings_t;
The member fields and constants used for different address types are
defined in [RFC-2744].
The "Bnd" field contains the MD5 hash of channel bindings, taken
over all non-null components of bindings, in order of declaration.
Integer fields within channel bindings are represented in little-
endian order for the purposes of the MD5 calculation.
In computing the contents of the Bnd field, the following detailed
points apply:
Zhu Internet Draft 5
Kerberos Version 5 GSS-API September 2003
(1) Each integer field shall be formatted into four bytes, using
little endian byte ordering, for purposes of MD5 hash computation.
(2) All input length fields within gss_buffer_desc elements of a
gss_channel_bindings_struct even those which are zero-valued, shall
be included in the hash calculation; the value elements of
gss_buffer_desc elements shall be dereferenced, and the resulting
data shall be included within the hash computation, only for the
case of gss_buffer_desc elements having non-zero length specifiers.
(3) If the caller passes the value GSS_C_NO_BINDINGS instead of a
valid channel binding structure, the Bnd field shall be set to 16
zero-valued bytes.
4.2. Per-Message and Context Deletion Tokens
Three classes of tokens are defined in this section: "MIC" tokens,
emitted by calls to GSS_GetMIC() and consumed by calls to
GSS_VerifyMIC(), "Wrap" tokens, emitted by calls to GSS_Wrap() and
consumed by calls to GSS_Unwrap(), and context deletion tokens,
emitted by calls to GSS_Delete_sec_context() and consumed by calls
to GSS_Process_context_token().
The new per-message and context deletion tokens introduced here do
not include the pseudo ASN.1 header used by the initial context
tokens. These new tokens are designed to be used with newer crypto
systems that can, for example, have variable-size checksums.
4.2.1. Sequence Number and Direction Indicator
To distinguish intentionally-repeated messages from maliciously-
replayed ones, per-message and context deletion tokens contain a
sequence number field, which is a 64 bit integer expressed in big
endian order. One separate bit is used as the direction-indicator
in the Flags field as described in section 4.2.2, thus preventing an
adversary from sending back the same message in the reverse
direction and having it accepted. Both the sequence number and the
direction-indicator are protected by the encryption and checksum
procedures specified in section 4.2.4.
After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
sequence numbers are incremented by one.
4.2.2. Flags Field
The "Flags" field is a one-byte integer used to indicate a set of
attributes. The meanings of bits in this field (the least
significant bit is bit 0) are as follows:
Bit Name Description
---------------------------------------------------------------
0 SentByAcceptor When set, this flag indicates the sender
is the context acceptor. When not set,
Zhu Internet Draft 6
Kerberos Version 5 GSS-API September 2003
it indicates the sender is the context
initiator.
1 Sealed When set in Wrap tokens, this flag
indicates confidentiality is provided
for. It SHALL NOT be set in MIC and
context deletion tokens.
2 AcceptorSubkey A subkey asserted by the context acceptor
is used to protect the message.
The rest of available bits are reserved for future use and MUST be
cleared. The receiver MUST ignore unknown flags.
4.2.3. EC Field
The "EC" (Extra Count) field is a two-byte integer field expressed
in big endian order.
In Wrap tokens with confidentiality, the EC field is used to encode
the number of bytes in the filler, as described in section 4.2.4.
In Wrap tokens without confidentiality, the EC field is used to
encode the number of bytes in the trailing checksum, as described in
section 4.2.4.
4.2.4. Encryption and Checksum Operations
The encryption algorithms defined by the crypto profiles provide for
integrity protection [KCRYPTO]. Therefore no separate checksum is
needed.
The result of decryption can be longer than the original plaintext
[KCRYPTO] and the extra trailing bytes are called "crypto-system
garbage". However, given the size of any plaintext data, one can
always find the next (possibly larger) size so that, when padding
the to-be-encrypted text to that size, there will be no crypto-
system garbage added [KCRYPTO].
In Wrap tokens that provide for confidentiality, the first 16 bytes
of the Wrap token (the "header") are appended to the plaintext data
before encryption. Filler bytes can be inserted between the
plaintext-data and the "header", and the values and size of the
filler octets are chosen by implementations, such that there is no
crypto-system garbage present after the decryption. The resulting
Wrap token is {"header" | encrypt(plaintext-data | filler |
"header")}, where encrypt() is the encryption operation (which
provides for integrity protection) defined in the crypto profile
[KCRYPTO], and the RRC field in the to-be-encrypted header contains
the hex value 00 00.
In Wrap tokens that do not provide for confidentiality, the checksum
is calculated first over the plaintext data, and then the first 16
bytes of the Wrap token (the "header"). Both the EC field and the
RRC field in the token header are filled with zeroes for the purpose
of calculating the checksum. The resulting Wrap token is {"header"
Zhu Internet Draft 7
Kerberos Version 5 GSS-API September 2003
| plaintext-data | get_mic(plaintext-data | "header")}, where
get_mic() is the checksum operation defined in the crypto profile
[KCRYPTO].
The parameters for the key and the cipher-state in the encrypt() and
get_mic() operations have been omitted for brevity.
For MIC tokens, the checksum is first calculated over the first 16
bytes of the MIC token and then the to-be-signed plaintext data.
The resulting Wrap and MIC tokens bind the data to the token header,
including the sequence number and the directional indicator.
For context deletion tokens, the checksum is calculated over the
first 16 bytes of the token message.
4.2.5. RRC Field
The "RRC" (Right Rotation Count) field in Wrap tokens is added to
allow the data to be encrypted in-place by existing [SSPI]
applications that do not provide an additional buffer for the
trailer (the cipher text after the in-place-encrypted data) in
addition to the buffer for the header (the cipher text before the
in-place-encrypted data). The resulting Wrap token in the previous
section, excluding the first 16 bytes of the token header, is
rotated to the right by "RRC" bytes. The net result is that "RRC"
bytes of trailing octets are moved toward the header. Consider the
following as an example of this rotation operation: Assume that the
RRC value is 3 and the token before the rotation is {"header" | aa |
bb | cc | dd | ee | ff | gg | hh}, the token after rotation would be
{"header" | ff | gg | hh | aa | bb | cc | dd | ee }, where {aa | bb
| cc |...| hh} is used to indicate the byte sequence.
The RRC field is expressed as a two-byte integer in big endian
order.
The rotation count value is chosen by the sender based on
implementation details, and the receiver MUST be able to interpret
all possible rotation count values.
4.2.6. Message Layouts
Per-message and context deletion token messages start with a two-
byte token identifier (TOK_ID) field, expressed in big endian order.
These tokens are defined separately in subsequent sub-sections.
4.2.6.1. MIC Tokens
Use of the GSS_GetMIC() call yields a token, separate from the user
data being protected, which can be used to verify the integrity of
that data as received. The token has the following format:
Zhu Internet Draft 8
Kerberos Version 5 GSS-API September 2003
Byte no Name Description
-----------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_GetMIC() contain the hex value 04 04
expressed in big endian order in this field.
2 Flags Attributes field, as described in section
4.2.2.
3..7 Filler Contains five bytes of hex value FF.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big endian order.
16..last SGN_CKSUM Checksum of byte 0..15 and the "to-be-
signed" data, where the checksum algorithm
is defined by the crypto profile for the
session key or subkey.
The Filler field is included in the checksum calculation for
simplicity. This is common to both MIC and context deletion token
checksum calculations.
4.2.6.2. Wrap Tokens
Use of the GSS_Wrap() call yields a token, which consists of a
descriptive header, followed by a body portion that contains either
the input user data in plaintext concatenated with the checksum, or
the input user data encrypted. The GSS_Wrap() token has the
following format:
Byte no Name Description
---------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_Wrap() contain the the hex value 05 04
expressed in big endian order in this field.
2 Flags Attributes field, as described in section
4.2.2.
3 Filler Contains the hex value FF.
4..5 EC Contains the "extra count" field, in big
endian order as described in section 4.2.3.
6..7 RRC Contains the "right rotation count" in big
endian order, as described in section 4.2.5.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big endian order.
16..last Data Encrypted data for Wrap tokens with
confidentiality, or plaintext data followed
by the checksum for Wrap tokens without
confidentiality, as described in section
4.2.4, where the encryption or checksum
algorithm is defined by the crypto profile
for the session key or subkey.
4.2.6.3. Context Deletion Tokens
The token emitted by GSS_Delete_sec_context() is based on the packet
format for tokens emitted by GSS_GetMIC(). The context-deletion
token has the following format:
Zhu Internet Draft 9
Kerberos Version 5 GSS-API September 2003
Byte no Name Description
-----------------------------------------------------------------
0..1 TOK_ID Identification field. Tokens emitted by
GSS_Delete_sec_context() contain the hex
value 04 05 expressed in big endian order in
this field.
2 Flags Attributes field, as described in section
4.2.2.
3..7 Filler Contains five bytes of hex value FF.
8..15 SND_SEQ Sequence number field in clear text,
expressed in big endian order.
16..N SGN_CKSUM Checksum of byte 0..15, where the checksum
algorithm is defined by the crypto profile
for the session key or subkey.
5. Parameter Definitions
This section defines parameter values used by the Kerberos V5 GSS-
API mechanism. It defines interface elements in support of
portability, and assumes use of C language bindings per [RFC-2744].
5.1. Minor Status Codes
This section recommends common symbolic names for minor_status
values to be returned by the Kerberos V5 GSS-API mechanism. Use of
these definitions will enable independent implementers to enhance
application portability across different implementations of the
mechanism defined in this specification. (In all cases,
implementations of GSS_Display_status() will enable callers to
convert minor_status indicators to text representations.) Each
implementation should make available, through include files or other
means, a facility to translate these symbolic names into the
concrete values which a particular GSS-API implementation uses to
represent the minor_status values specified in this section.
It is recognized that this list may grow over time, and that the
need for additional minor_status codes specific to particular
implementations may arise. It is recommended, however, that
implementations should return a minor_status value as defined on a
mechanism-wide basis within this section when that code is
accurately representative of reportable status rather than using a
separate, implementation-defined code.
5.1.1. Non-Kerberos-specific codes
GSS_KRB5_S_G_BAD_SERVICE_NAME
/* "No @ in SERVICE-NAME name string" */
GSS_KRB5_S_G_BAD_STRING_UID
/* "STRING-UID-NAME contains nondigits" */
GSS_KRB5_S_G_NOUSER
/* "UID does not resolve to username" */
GSS_KRB5_S_G_VALIDATE_FAILED
/* "Validation error" */
GSS_KRB5_S_G_BUFFER_ALLOC
/* "Couldn't allocate gss_buffer_t data" */
Zhu Internet Draft 10
Kerberos Version 5 GSS-API September 2003
GSS_KRB5_S_G_BAD_MSG_CTX
/* "Message context invalid" */
GSS_KRB5_S_G_WRONG_SIZE
/* "Buffer is the wrong size" */
GSS_KRB5_S_G_BAD_USAGE
/* "Credential usage type is unknown" */
GSS_KRB5_S_G_UNKNOWN_QOP
/* "Unknown quality of protection specified" */
5.1.2. Kerberos-specific-codes
GSS_KRB5_S_KG_CCACHE_NOMATCH
/* "Client principal in credentials does not match
specified name" */
GSS_KRB5_S_KG_KEYTAB_NOMATCH
/* "No key available for specified service principal" */
GSS_KRB5_S_KG_TGT_MISSING
/* "No Kerberos ticket-granting ticket available" */
GSS_KRB5_S_KG_NO_SUBKEY
/* "Authenticator has no subkey" */
GSS_KRB5_S_KG_CONTEXT_ESTABLISHED
/* "Context is already fully established" */
GSS_KRB5_S_KG_BAD_SIGN_TYPE
/* "Unknown signature type in token" */
GSS_KRB5_S_KG_BAD_LENGTH
/* "Invalid field length in token" */
GSS_KRB5_S_KG_CTX_INCOMPLETE
/* "Attempt to use incomplete security context" */
5.2. Buffer Sizes
All implementations of this specification shall be capable of
accepting buffers of at least 16K bytes as input to GSS_GetMIC(),
GSS_VerifyMIC(), and GSS_Wrap(), and shall be capable of accepting
the output_token generated by GSS_Wrap() for a 16K byte input buffer
as input to GSS_Unwrap(). Support for larger buffer sizes is
optional but recommended.
6. Backwards Compatibility Considerations
The new token formats defined in this document will only be
recognized by new implementations. To address this, implementations
can always use the explicit sign or seal algorithm in [RFC-1964]
when the key type corresponds to "older" enctypes. An alternative
approach might be to retry sending the message with the sign or seal
algorithm explicitly defined as in [RFC-1964]. However this would
require either the use of a mechanism such as [RFC-2478] to securely
negotiate the method or the use out of band mechanism to choose
appropriate mechanism. For this reason, it is RECOMMENDED that the
new token formats defined in this document SHOULD be used only if
both peers are known to support the new mechanism during context
negotiation, for example, either because of the use of "new"
enctypes or because of the use of Kerberos Version 5 extensions.
Zhu Internet Draft 11
Kerberos Version 5 GSS-API September 2003
7. Security Considerations
Under the current mechanism, no negotiation of algorithm types
occurs, so server-side (acceptor) implementations cannot request
that clients not use algorithm types not understood by the server.
However, administration of the server's Kerberos data (e.g., the
service key) has to be done in communication with the KDC, and it is
from the KDC that the client will request credentials. The KDC
could therefore be given the task of limiting session keys for a
given service to types actually supported by the Kerberos and GSSAPI
software on the server.
This does have a drawback for cases where a service principal name
is used both for GSSAPI-based and non-GSSAPI-based communication
(most notably the "host" service key), if the GSSAPI implementation
does not understand (for example) AES [AES-KRB5] but the Kerberos
implementation does. It means that AES session keys cannot be
issued for that service principal, which keeps the protection of
non-GSSAPI services weaker than necessary. KDC administrators
desiring to limit the session key types to support interoperability
with such GSSAPI implementations should carefully weigh the
reduction in protection offered by such mechanisms against the
benefits of interoperability.
8. Acknowledgments
The authors wish to acknowledge the contributions from the following
individuals:
Ken Raeburn and Nicolas Williams corrected many of our errors in the
use of generic profiles and were instrumental in the creation of this
draft.
The text for security considerations was contributed by Ken Raeburn.
Sam Hartman and Ken Raeburn suggested the "floating trailer" idea,
namely the encoding of the RRC field.
Sam Hartman and Nicolas Williams recommended the replacing our
earlier key derivation function for directional keys with different
key usage numbers for each direction as well as retaining the
directional bit for maximum compatibility.
Paul Leach provided numerous suggestions and comments.
Scott Field, Richard Ward, Dan Simon, and Kevin Damour also provided
valuable inputs on this draft.
Jeffrey Hutzelman provided comments on channel bindings and suggested
many editorial changes.
This document retains some of the text of RFC-1964 in relevant
sections.
Zhu Internet Draft 12
Kerberos Version 5 GSS-API September 2003
9. References
9.1. Normative References
[RFC-2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC-2744] Wray, J., "Generic Security Service API Version 2: C-
bindings", RFC 2744, January 2000.
[RFC-1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism",
RFC 1964, June 1996.
[KCRYPTO] Raeburn, K., "Encryption and Checksum Specifications for
Kerberos 5", draft-ietf-krb-wg-crypto-05.txt, June, 2003. Work in
progress.
[KRBCLAR] Neuman, C., Kohl, J., Ts'o T., Yu T., Hartman, S.,
Raeburn, K., "The Kerveros Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications-04.txt, February 2002.
Work in progress.
[AES-KRB5] Raeburn, K., "AES Encryption for Kerberos 5", draft-
raeburn-krb-rijndael-krb-05.txt, June 2003. Work in progress.
[RFC-2478] Baize, E., Pinkas D., "The Simple and Protected GSS-API
Negotiation Mechanism", RFC 2478, December 1998.
9.2. Informative References
[SSPI] Leach, P., "Security Service Provider Interface", Microsoft
Developer Network (MSDN), April 2003.
10. Author's Address
Larry Zhu
One Microsoft Way
Redmond, WA 98052 - USA
EMail: LZhu@microsoft.com
Karthik Jaganathan
One Microsoft Way
Redmond, WA 98052 - USA
EMail: karthikj@microsoft.com
Zhu Internet Draft 13
Kerberos Version 5 GSS-API September 2003
Sam Hartman
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge, MA 02139 - USA
Email: hartmans@MIT.EDU
Zhu Internet Draft 14
Kerberos Version 5 GSS-API September 2003
Full Copyright Statement
Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Zhu Internet Draft 15
|