File: rfc1964.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1123 lines) | stat: -rw-r--r-- 47,413 bytes parent folder | download | duplicates (8)
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
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123






Network Working Group                                            J. Linn
Request for Comments: 1964                       OpenVision Technologies
Category: Standards Track                                      June 1996


                The Kerberos Version 5 GSS-API Mechanism

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

ABSTRACT

   This specification defines protocols, procedures, and conventions to
   be employed by peers implementing the Generic Security Service
   Application Program Interface (as specified in RFCs 1508 and 1509)
   when using Kerberos Version 5 technology (as specified in RFC 1510).

ACKNOWLEDGMENTS

   Much of the material in this memo is based on working documents
   drafted by John Wray of Digital Equipment Corporation and on
   discussions, implementation activities, and interoperability testing
   involving Marc Horowitz, Ted Ts'o, and John Wray.  Particular thanks
   are due to each of these individuals for their contributions towards
   development and availability of GSS-API support within the Kerberos
   Version 5 code base.

1. Token Formats

   This section discusses protocol-visible characteristics of the GSS-
   API mechanism to be implemented atop Kerberos V5 security technology
   per RFC-1508 and RFC-1510; it defines elements of protocol for
   interoperability and is independent of language bindings per RFC-
   1509.

   Tokens transferred between GSS-API peers (for security context
   management and per-message protection purposes) are defined.  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 RFC-1510 rather than within this specification.






Linn                        Standards Track                     [Page 1]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   To support ongoing experimentation, testing, and evolution of the
   specification, the Kerberos V5 GSS-API mechanism as defined in this
   and any successor memos will be identified with the following Object
   Identifier, as defined in RFC-1510, until the specification is
   advanced to the level of Proposed Standard RFC:

   {iso(1), org(3), dod(5), internet(1), security(5), kerberosv5(2)}

   Upon advancement to the level of Proposed Standard RFC, the Kerberos
   V5 GSS-API mechanism will be identified by an Object Identifier
   having the value:

   {iso(1) member-body(2) United States(840) mit(113554) infosys(1)
   gssapi(2) krb5(2)}

1.1. Context Establishment Tokens

   Per RFC-1508, Appendix B, the initial context establishment token
   will be enclosed within framing as follows:

   InitialContextToken ::=
   [APPLICATION 0] IMPLICIT SEQUENCE {
           thisMech        MechType
                   -- MechType is OBJECT IDENTIFIER
                   -- representing "Kerberos V5"
           innerContextToken ANY DEFINED BY thisMech
                   -- contents mechanism-specific;
                   -- ASN.1 usage within innerContextToken
                   -- is not required
           }

   The innerContextToken of the initial context token will consist of a
   Kerberos V5 KRB_AP_REQ message, preceded by a two-byte token-id
   (TOK_ID) field, which shall contain the value 01 00.

   The above GSS-API framing shall be applied to all tokens emitted by
   the Kerberos V5 GSS-API mechanism, including KRB_AP_REP, KRB_ERROR,
   context-deletion, and per-message tokens, not just to the initial
   token in a context establishment sequence.  While not required by
   RFC-1508, this enables implementations to perform enhanced error-
   checking. The innerContextToken field of context establishment tokens
   for the Kerberos V5 GSS-API mechanism will contain a Kerberos message
   (KRB_AP_REQ, KRB_AP_REP or KRB_ERROR), preceded by a 2-byte TOK_ID
   field containing 01 00 for KRB_AP_REQ messages, 02 00 for KRB_AP_REP
   messages and 03 00 for KRB_ERROR messages.






Linn                        Standards Track                     [Page 2]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


1.1.1. Initial Token

   Relevant KRB_AP_REQ syntax (from RFC-1510) is as follows:

   AP-REQ ::= [APPLICATION 14] SEQUENCE {
           pvno [0]        INTEGER,        -- indicates Version 5
           msg-type [1]    INTEGER,        -- indicates KRB_AP_REQ
           ap-options[2]   APOptions,
           ticket[3]       Ticket,
           authenticator[4]        EncryptedData
   }

   APOptions ::= BIT STRING {
           reserved (0),
           use-session-key (1),
           mutual-required (2)
   }

   Ticket ::= [APPLICATION 1] SEQUENCE {
           tkt-vno [0]     INTEGER,        -- indicates Version 5
           realm [1]       Realm,
           sname [2]       PrincipalName,
           enc-part [3]    EncryptedData
   }

   -- Encrypted part of ticket
   EncTicketPart ::= [APPLICATION 3] SEQUENCE {
           flags[0]        TicketFlags,
           key[1]          EncryptionKey,
           crealm[2]       Realm,
           cname[3]        PrincipalName,
           transited[4]    TransitedEncoding,
           authtime[5]     KerberosTime,
           starttime[6]    KerberosTime OPTIONAL,
           endtime[7]      KerberosTime,
           renew-till[8]   KerberosTime OPTIONAL,
           caddr[9]        HostAddresses OPTIONAL,
           authorization-data[10]  AuthorizationData OPTIONAL
   }

   -- Unencrypted authenticator
   Authenticator ::= [APPLICATION 2] SEQUENCE  {
           authenticator-vno[0]    INTEGER,
           crealm[1]               Realm,
           cname[2]                PrincipalName,
           cksum[3]                Checksum OPTIONAL,
           cusec[4]                INTEGER,
           ctime[5]                KerberosTime,



Linn                        Standards Track                     [Page 3]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


           subkey[6]               EncryptionKey OPTIONAL,
           seq-number[7]           INTEGER OPTIONAL,
           authorization-data[8]   AuthorizationData OPTIONAL
   }

   For purposes of this specification, the authenticator shall include
   the optional sequence number, and the checksum field shall be used to
   convey channel binding, service flags, and optional delegation
   information.  The checksum will have a type of 0x8003 (a value being
   registered within the Kerberos protocol specification), and a value
   field of at least 24 bytes in length.  The length of the value field
   is extended beyond 24 bytes if and only if an optional facility to
   carry a Kerberos-defined KRB_CRED message for delegation purposes is
   supported by an implementation and active on a context. When
   delegation is active, a TGT with its FORWARDABLE flag set will be
   transferred within the KRB_CRED message.

   The checksum value field's format is as follows:

   Byte    Name    Description
   0..3    Lgth    Number of bytes in Bnd field;
                   Currently contains hex 10 00 00 00
                   (16, represented in little-endian form)
   4..19   Bnd     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.
   20..23  Flags   Bit vector of context-establishment flags,
                   with values consistent with RFC-1509, p. 41:
                           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
                   The resulting bit vector is encoded into bytes 20..23
                   in little-endian form.
   24..25  DlgOpt  The Delegation Option identifier (=1) [optional]
   26..27  Dlgth   The length of the Deleg field. [optional]
   28..n   Deleg   A KRB_CRED message (n = Dlgth + 29) [optional]

   In computing the contents of the "Bnd" field, the following detailed
   points apply:

        (1) Each integer field shall be formatted into four bytes, using
        little-endian byte ordering, for purposes of MD5 hash
        computation.



Linn                        Standards Track                     [Page 4]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


        (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 bindings structure, the Bnd field shall be set
        to 16 zero-valued bytes.

   In the initial Kerberos V5 GSS-API mechanism token (KRB_AP_REQ token)
   from initiator to target, the GSS_C_DELEG_FLAG, GSS_C_MUTUAL_FLAG,
   GSS_C_REPLAY_FLAG, and GSS_C_SEQUENCE_FLAG values shall each be set
   as the logical AND of the initiator's corresponding request flag to
   GSS_Init_sec_context() and a Boolean indicator of whether that
   optional service is available to GSS_Init_sec_context()'s caller.
   GSS_C_CONF_FLAG and GSS_C_INTEG_FLAG, for which no corresponding
   context-level input indicator flags to GSS_Init_sec_context() exist,
   shall each be set to indicate whether their respective per-message
   protection services are available for use on the context being
   established.

   When input source address channel binding values are provided by a
   caller (i.e., unless the input argument is GSS_C_NO_BINDINGS or the
   source address specifier value within the input structure is
   GSS_C_NULL_ADDRTYPE), and the corresponding token received from the
   context's peer bears address restrictions, it is recommended that an
   implementation of the Kerberos V5 GSS-API mechanism should check that
   the source address as provided by the caller matches that in the
   received token, and should return the GSS_S_BAD_BINDINGS major_status
   value if a mismatch is detected. Note: discussion is ongoing about
   the strength of recommendation to be made in this area, and on the
   circumstances under which such a recommendation should be applicable;
   implementors are therefore advised that changes on this matter may be
   included in subsequent versions of this specification.

1.1.2. Response Tokens

   A context establishment sequence based on the Kerberos V5 mechanism
   will perform one-way authentication (without confirmation or any
   return token from target to initiator in response to the initiator's
   KRB_AP_REQ) if the mutual_req bit is not set in the application's
   call to GSS_Init_sec_context().  Applications requiring confirmation
   that their authentication was successful should request mutual
   authentication, resulting in a "mutual-required" indication within
   KRB_AP_REQ APoptions and the setting of the mutual_req bit in the



Linn                        Standards Track                     [Page 5]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   flags field of the authenticator checksum.  In response to such a
   request, the context target will reply to the initiator with a token
   containing either a KRB_AP_REP or KRB_ERROR, completing the mutual
   context establishment exchange.

   Relevant KRB_AP_REP syntax is as follows:

   AP-REP ::= [APPLICATION 15] SEQUENCE {
           pvno [0]        INTEGER,        -- represents Kerberos V5
           msg-type [1]    INTEGER,        -- represents KRB_AP_REP
           enc-part [2]    EncryptedData
   }

   EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
           ctime [0]       KerberosTime,
           cusec [1]       INTEGER,
           subkey [2]      EncryptionKey OPTIONAL,
           seq-number [3]  INTEGER OPTIONAL
   }

   The optional seq-number element within the AP-REP's EncAPRepPart
   shall be included.

   The syntax of KRB_ERROR is as follows:

   KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
           pvno[0]         INTEGER,
           msg-type[1]     INTEGER,
           ctime[2]        KerberosTime OPTIONAL,
           cusec[3]        INTEGER OPTIONAL,
           stime[4]        KerberosTime,
           susec[5]        INTEGER,
           error-code[6]   INTEGER,
           crealm[7]       Realm OPTIONAL,
           cname[8]        PrincipalName OPTIONAL,
           realm[9]        Realm, -- Correct realm
           sname[10]       PrincipalName, -- Correct name
           e-text[11]      GeneralString OPTIONAL,
           e-data[12]      OCTET STRING OPTIONAL
   }

   Values to be transferred in the error-code field of a KRB-ERROR
   message are defined in [RFC-1510], not in this specification.








Linn                        Standards Track                     [Page 6]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


1.2. Per-Message and Context Deletion Tokens

   Three classes of tokens are defined in this section: "MIC" tokens,
   emitted by calls to GSS_GetMIC() (formerly GSS_Sign()) and consumed
   by calls to GSS_VerifyMIC() (formerly GSS_Verify()), "Wrap" tokens,
   emitted by calls to GSS_Wrap() (formerly GSS_Seal()) and consumed by
   calls to GSS_Unwrap() (formerly GSS_Unseal()), and context deletion
   tokens, emitted by calls to GSS_Delete_sec_context() and consumed by
   calls to GSS_Process_context_token().  Note: References to GSS-API
   per-message routines in the remainder of this specification will be
   based on those routines' newer recommended names rather than those
   names' predecessors.

   Several variants of cryptographic keys are used in generation and
   processing of per-message tokens:

        (1) context key: uses Kerberos session key (or subkey, if
        present in authenticator emitted by context initiator) directly

        (2) confidentiality key: forms variant of context key by
        exclusive-OR with the hexadecimal constant f0f0f0f0f0f0f0f0.

        (3) MD2.5 seed key: forms variant of context key by reversing
        the bytes of the context key (i.e. if the original key is the
        8-byte sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the seed key
        will be {hh, gg, ff, ee, dd, cc, bb, aa}).

1.2.1. Per-message Tokens - MIC

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:

   Byte no          Name           Description
    0..1           TOK_ID          Identification field.
                                   Tokens emitted by GSS_GetMIC() contain
                                   the hex value 01 01 in this field.
    2..3           SGN_ALG         Integrity algorithm indicator.
                                   00 00 - DES MAC MD5
                                   01 00 - MD2.5
                                   02 00 - DES MAC
    4..7           Filler          Contains ff ff ff ff
    8..15          SND_SEQ         Sequence number field.
    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
                                   calculated according to algorithm
                                   specified in SGN_ALG field.





Linn                        Standards Track                     [Page 7]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   GSS-API tokens must be encapsulated within the higher-level protocol
   by the application; no embedded length field is necessary.

1.2.1.1. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the data field, logically prepended by the first
   8 bytes of the plaintext packet header.  The resulting value binds
   the data to the packet type and signature algorithm identifier
   fields.

   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
   [RFC-1321] hash over the plaintext data, and then computing a DES-CBC
   MAC on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is
   computed per [FIPS-PUB-113], employing the context key and a zero IV.
   The 8-byte result is stored in the SGN_CKSUM field.

   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
   16-byte zero-block, using a zero IV and a key formed by reversing the
   bytes of the context key (i.e. if the original key is the 8-byte
   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
   {hh, gg, ff, ee, dd, cc, bb, aa}).   The resulting 16-byte value is
   logically prepended to the to-be-signed data.  A standard MD5
   checksum is calculated over the combined data, and the first 8 bytes
   of the result are stored in the SGN_CKSUM field.  Note 1: we refer to
   this algorithm informally as "MD2.5" to connote the fact that it uses
   half of the 128 bits generated by MD5; use of only a subset of the
   MD5 bits is intended to protect against the prospect that data could
   be postfixed to an existing message with corresponding modifications
   being made to the checksum.  Note 2: This algorithm is fairly novel
   and has received more limited evaluation than that to which other
   integrity algorithms have been subjected.  An initial, limited
   evaluation indicates that it may be significantly weaker than DES MAC
   MD5.

   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
   plaintext data per [FIPS-PUB-113], employing the context key and a
   zero IV. Padding procedures to accomodate plaintext data lengths
   which may not be integral multiples of 8 bytes are defined in [FIPS-
   PUB-113].  The result is an 8-byte value, which is stored in the
   SGN_CKSUM field.  Support for this algorithm may not be present in
   all implementations.

1.2.1.2. Sequence Number

   Sequence number field: The 8 byte plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four bytes of the sender's sequence number are named s0, s1, s2



Linn                        Standards Track                     [Page 8]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 0 - sender is the
   context initiator, Hex FF - sender is the context acceptor).  The
   field is then DES-CBC encrypted using the context key and an IV
   formed from the first 8 bytes of the previously calculated SGN_CKSUM
   field. After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
   sequence number is incremented by one.

   The receiver of the token will first verify the SGN_CKSUM field.  If
   valid, the sequence number field may be decrypted and compared to the
   expected sequence number.  The repetition of the (effectively 1-bit)
   direction indicator within the sequence number field provides
   redundancy so that the receiver may verify that the decryption
   succeeded.

   Since the checksum computation is used as an IV to the sequence
   number decryption, attempts to splice a checksum and sequence number
   from different messages will be detected.  The direction indicator
   will detect packets that have been maliciously reflected.

   The sequence number provides a basis for detection of replayed
   tokens.  Replay detection can be performed using state information
   retained on received sequence numbers, interpreted in conjunction
   with the security context on which they arrive.

   Provision of per-message replay and out-of-sequence detection
   services is optional for implementations of the Kerberos V5 GSS-API
   mechanism.  Further, it is recommended that implementations of the
   Kerberos V5 GSS-API mechanism which offer these services should honor
   a caller's request that the services be disabled on a context.
   Specifically, if replay_det_req_flag is input FALSE, replay_det_state
   should be returned FALSE and the GSS_DUPLICATE_TOKEN and
   GSS_OLD_TOKEN stati should not be indicated as a result of duplicate
   detection when tokens are processed; if sequence_req_flag is input
   FALSE, sequence_state should be returned FALSE and
   GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_TOKEN stati should
   not be indicated as a result of out-of-sequence detection when tokens
   are processed.

1.2.2. Per-message Tokens - Wrap

   Use of the GSS_Wrap() call yields a token which encapsulates the
   input user data (optionally encrypted) along with associated
   integrity check quantities. The token emitted by GSS_Wrap() consists
   of an integrity header whose format is identical to that emitted by
   GSS_GetMIC() (except that the TOK_ID field contains the value 02 01),
   followed by a body portion that contains either the plaintext data



Linn                        Standards Track                     [Page 9]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   (if SEAL_ALG = ff ff) or encrypted data for any other supported value
   of SEAL_ALG.  Currently, only SEAL_ALG = 00 00 is supported, and
   means that DES-CBC encryption is being used to protect the data.

   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 hex value 02 01 in this field.
    2..3           SGN_ALG         Checksum algorithm indicator.
                                   00 00 - DES MAC MD5
                                   01 00 - MD2.5
                                   02 00 - DES MAC
    4..5           SEAL_ALG        ff ff - none
                                   00 00 - DES
    6..7           Filler          Contains ff ff
    8..15          SND_SEQ         Encrypted sequence number field.
    16..23         SGN_CKSUM       Checksum of plaintext padded data,
                                   calculated according to algorithm
                                   specified in SGN_ALG field.
    24..last       Data            encrypted or plaintext padded data

   GSS-API tokens must be encapsulated within the higher-level protocol
   by the application; no embedded length field is necessary.

1.2.2.1. Checksum

   Checksum calculation procedure (common to all algorithms): Checksums
   are calculated over the plaintext padded data field, logically
   prepended by the first 8 bytes of the plaintext packet header.  The
   resulting signature binds the data to the packet type, protocol
   version, and signature algorithm identifier fields.

   DES MAC MD5 algorithm: The checksum is formed by computing an MD5
   hash over the plaintext padded data, and then computing a DES-CBC MAC
   on the 16-byte MD5 result.  A standard 64-bit DES-CBC MAC is computed
   per [FIPS-PUB-113], employing the context key and a zero IV. The 8-
   byte result is stored in the SGN_CKSUM field.

   MD2.5 algorithm: The checksum is formed by first DES-CBC encrypting a
   16-byte zero-block, using a zero IV and a key formed by reversing the
   bytes of the context key (i.e., if the original key is the 8-byte
   sequence {aa, bb, cc, dd, ee, ff, gg, hh}, the checksum key will be
   {hh, gg, ff, ee, dd, cc, bb, aa}). The resulting 16-byte value is
   logically pre-pended to the "to-be-signed data".  A standard MD5
   checksum is calculated over the combined data, and the first 8 bytes
   of the result are stored in the SGN_CKSUM field.



Linn                        Standards Track                    [Page 10]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   DES-MAC algorithm: A standard 64-bit DES-CBC MAC is computed on the
   plaintext padded data per [FIPS-PUB-113], employing the context key
   and a zero IV. The plaintext padded data is already assured to be an
   integral multiple of 8 bytes; no additional padding is required or
   applied in order to accomplish MAC calculation.  The result is an 8-
   byte value, which is stored in the SGN_CKSUM field.  Support for this
   lgorithm may not be present in all implementations.

1.2.2.2. Sequence Number

   Sequence number field: The 8 byte plaintext sequence number field is
   formed from the sender's four-byte sequence number as follows.  If
   the four bytes of the sender's sequence number are named s0, s1, s2
   and s3 (from least to most significant), the plaintext sequence
   number field is the 8 byte sequence: (s0, s1, s2, s3, di, di, di,
   di), where 'di' is the direction-indicator (Hex 0 - sender is the
   context initiator, Hex FF - sender is the context acceptor).

   The field is then DES-CBC encrypted using the context key and an IV
   formed from the first 8 bytes of the SEAL_CKSUM field.

   After sending a GSS_GetMIC() or GSS_Wrap() token, the sender's
   sequence numbers are incremented by one.

1.2.2.3. Padding

   Data padding: Before encryption and/or signature calculation,
   plaintext data is padded to the next highest multiple of 8 bytes, by
   appending between 1 and 8 bytes, the value of each such byte being
   the total number of pad bytes.  For example, given data of length 20
   bytes, four pad bytes will be appended, and each byte will contain
   the hex value 04.  An 8-byte random confounder is prepended to the
   data, and signatures are calculated over the resulting padded
   plaintext.

   After padding, the data is encrypted according to the algorithm
   specified in the SEAL_ALG field.  For SEAL_ALG=DES (the only non-null
   algorithm currently supported), the data is encrypted using DES-CBC,
   with an IV of zero.  The key used is derived from the established
   context key by XOR-ing the context key with the hexadecimal constant
   f0f0f0f0f0f0f0f0.

1.2.3. Context deletion token

   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:




Linn                        Standards Track                    [Page 11]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   Byte no          Name           Description
    0..1           TOK_ID          Identification field.
                                   Tokens emitted by
                                   GSS_Delete_sec_context() contain
                                   the hex value 01 02 in this field.
    2..3           SGN_ALG         Integrity algorithm indicator.
                                   00 00 - DES MAC MD5
                                   01 00 - MD2.5
                                   02 00 - DES MAC
    4..7           Filler          Contains ff ff ff ff
    8..15          SND_SEQ         Sequence number field.
    16..23         SGN_CKSUM       Checksum of "to-be-signed data",
                                   calculated according to algorithm
                                   specified in SGN_ALG field.

   SGN_ALG and SND_SEQ will be calculated as for tokens emitted by
   GSS_GetMIC().  The SGN_CKSUM will be calculated as for tokens emitted
   by GSS_GetMIC(), except that the user-data component of the "to-be-
   signed" data will be a zero-length string.

2. Name Types and Object Identifiers

   This section discusses the name types which may be passed as input to
   the Kerberos V5 GSS-API mechanism's GSS_Import_name() call, and their
   associated identifier values.  It defines interface elements in
   support of portability, and assumes use of C language bindings per
   RFC-1509.  In addition to specifying OID values for name type
   identifiers, symbolic names are included and recommended to GSS-API
   implementors in the interests of convenience to callers.  It is
   understood that not all implementations of the Kerberos V5 GSS-API
   mechanism need support all name types in this list, and that
   additional name forms will likely be added to this list over time.
   Further, the definitions of some or all name types may later migrate
   to other, mechanism-independent, specifications. The occurrence of a
   name type in this specification is specifically not intended to
   suggest that the type may be supported only by an implementation of
   the Kerberos V5 mechanism.   In particular, the occurrence of the
   string "_KRB5_" in the symbolic name strings constitutes a means to
   unambiguously register the name strings, avoiding collision with
   other documents; it is not meant to limit the name types' usage or
   applicability.

   For purposes of clarification to GSS-API implementors, this section's
   discussion of some name forms describes means through which those
   forms can be supported with existing Kerberos technology.  These
   discussions are not intended to preclude alternative implementation
   strategies for support of the name forms within Kerberos mechanisms
   or mechanisms based on other technologies.  To enhance application



Linn                        Standards Track                    [Page 12]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   portability, implementors of mechanisms are encouraged to support
   name forms as defined in this section, even if their mechanisms are
   independent of Kerberos V5.

2.1. Mandatory Name Forms

   This section discusses name forms which are to be supported by all
   conformant implementations of the Kerberos V5 GSS-API mechanism.

2.1.1. Kerberos Principal Name Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   krb5(2) krb5_name(1)}.  The recommended symbolic name for this type
   is "GSS_KRB5_NT_PRINCIPAL_NAME".

   This name type corresponds to the single-string representation of a
   Kerberos name.  (Within the MIT Kerberos V5 implementation, such
   names are parseable with the krb5_parse_name() function.)  The
   elements included within this name representation are as follows,
   proceeding from the beginning of the string:

        (1) One or more principal name components; if more than one
        principal name component is included, the components are
        separated by `/`.  Arbitrary octets may be included within
        principal name components, with the following constraints and
        special considerations:

           (1a) Any occurrence of the characters `@` or `/` within a
           name component must be immediately preceded by the `\`
           quoting character, to prevent interpretation as a component
           or realm separator.

           (1b) The ASCII newline, tab, backspace, and null characters
           may occur directly within the component or may be
           represented, respectively, by `\n`, `\t`, `\b`, or `\0`.

           (1c) If the `\` quoting character occurs outside the contexts
           described in (1a) and (1b) above, the following character is
           interpreted literally.  As a special case, this allows the
           doubled representation `\\` to represent a single occurrence
           of the quoting character.

           (1d) An occurrence of the `\` quoting character as the last
           character of a component is illegal.






Linn                        Standards Track                    [Page 13]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


        (2) Optionally, a `@` character, signifying that a realm name
        immediately follows. If no realm name element is included, the
        local realm name is assumed.  The `/` , `:`, and null characters
        may not occur within a realm name; the `@`, newline, tab, and
        backspace characters may be included using the quoting
        conventions described in (1a), (1b), and (1c) above.

2.1.2. Host-Based Service Name Form

   This name form has been incorporated at the mechanism-independent
   GSS-API level as of GSS-API, Version 2.  This subsection retains the
   Object Identifier and symbolic name assignments previously made at
   the Kerberos V5 GSS-API mechanism level, and adopts the definition as
   promoted to the mechanism-independent level.

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) service_name(4)}.  The previously recommended symbolic
   name for this type is "GSS_KRB5_NT_HOSTBASED_SERVICE_NAME".  The
   currently preferred symbolic name for this type is
   "GSS_C_NT_HOSTBASED_SERVICE".

   This name type is used to represent services associated with host
   computers.  This name form is constructed using two elements,
   "service" and "hostname", as follows:

      service@hostname

   When a reference to a name of this type is resolved, the "hostname"
   is canonicalized by attempting a DNS lookup and using the fully-
   qualified domain name which is returned, or by using the "hostname"
   as provided if the DNS lookup fails.  The canonicalization operation
   also maps the host's name into lower-case characters.

   The "hostname" element may be omitted. If no "@" separator is
   included, the entire name is interpreted as the service specifier,
   with the "hostname" defaulted to the canonicalized name of the local
   host.

   Values for the "service" element will be registered with the IANA.

2.1.3. Exported Name Object Form for Kerberos V5 Mechanism

   Support for this name form is not required for GSS-V1
   implementations, but will be required for use in conjunction with the
   GSS_Export_name() call planned for GSS-API Version 2.  Use of this
   name form will be signified by a "GSS-API Exported Name Object" OID
   value which will be defined at the mechanism-independent level for



Linn                        Standards Track                    [Page 14]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   GSS-API Version 2.

   This name type represents a self-describing object, whose framing
   structure will be defined at the mechanism-independent level for
   GSS-API Version 2.  When generated by the Kerberos V5 mechanism, the
   Mechanism OID within the exportable name shall be that of the
   Kerberos V5 mechanism.  The name component within the exportable name
   shall be a contiguous string with structure as defined for the
   Kerberos Principal Name Form.

   In order to achieve a distinguished encoding for comparison purposes,
   the following additional constraints are imposed on the export
   operation:

        (1) all occurrences of the characters `@`,  `/`, and `\` within
        principal components or realm names shall be quoted with an
        immediately-preceding `\`.

        (2) all occurrences of the null, backspace, tab, or newline
        characters within principal components or realm names will be
        represented, respectively, with `\0`, `\b`, `\t`, or `\n`.

        (3) the `\` quoting character shall not be emitted within an
        exported name except to accomodate cases (1) and (2).

2.2. Optional Name Forms

   This section discusses additional name forms which may optionally be
   supported by implementations of the Kerberos V5 GSS-API mechanism.
   It is recognized that some of the name forms cited here are derived
   from UNIX(tm) operating system platforms; some listed forms may be
   irrelevant to non-UNIX platforms, and definition of additional forms
   corresponding to such platforms may also be appropriate.  It is also
   recognized that OS-specific functions outside GSS-API are likely to
   exist in order to perform translations among these forms, and that
   GSS-API implementations supporting these forms may themselves be
   layered atop such OS-specific functions.  Inclusion of this support
   within GSS-API implementations is intended as a convenience to
   applications.

2.2.1. User Name Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) user_name(1)}.  The recommended symbolic name for this
   type is "GSS_KRB5_NT_USER_NAME".

   This name type is used to indicate a named user on a local system.



Linn                        Standards Track                    [Page 15]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   Its interpretation is OS-specific.  This name form is constructed as:

      username

   Assuming that users' principal names are the same as their local
   operating system names, an implementation of GSS_Import_name() based
   on Kerberos V5 technology can process names of this form by
   postfixing an "@" sign and the name of the local realm.

2.2.2. Machine UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) machine_uid_name(2)}.  The recommended symbolic name for
   this type is "GSS_KRB5_NT_MACHINE_UID_NAME".

   This name type is used to indicate a numeric user identifier
   corresponding to a user on a local system.  Its interpretation is
   OS-specific.  The gss_buffer_desc representing a name of this type
   should contain a locally-significant uid_t, represented in host byte
   order.  The GSS_Import_name() operation resolves this uid into a
   username, which is then treated as the User Name Form.

2.2.3. String UID Form

   This name form shall be represented by the Object Identifier {iso(1)
   member-body(2) United States(840) mit(113554) infosys(1) gssapi(2)
   generic(1) string_uid_name(3)}.  The recommended symbolic name for
   this type is "GSS_KRB5_NT_STRING_UID_NAME".

   This name type is used to indicate a string of digits representing
   the numeric user identifier of a user on a local system.  Its
   interpretation is OS-specific. This name type is similar to the
   Machine UID Form, except that the buffer contains a string
   representing the uid_t.

3. Credentials Management

   The Kerberos V5 protocol uses different credentials (in the GSSAPI
   sense) for initiating and accepting security contexts.  Normal
   clients receive a ticket-granting ticket (TGT) and an associated
   session key at "login" time; the pair of a TGT and its corresponding
   session key forms a credential which is suitable for initiating
   security contexts.  A ticket-granting ticket, its session key, and
   any other (ticket, key) pairs obtained through use of the ticket-
   granting-ticket, are typically stored in a Kerberos V5 credentials
   cache, sometimes known as a ticket file.




Linn                        Standards Track                    [Page 16]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   The encryption key used by the Kerberos server to seal tickets for a
   particular application service forms the credentials suitable for
   accepting security contexts.  These service keys are typically stored
   in a Kerberos V5 key table, or srvtab file.  In addition to their use
   as accepting credentials, these service keys may also be used to
   obtain initiating credentials for their service principal.

   The Kerberos V5 mechanism's credential handle may contain references
   to either or both types of credentials.  It is a local matter how the
   Kerberos V5 mechanism implementation finds the appropriate Kerberos
   V5 credentials cache or key table.

   However, when the Kerberos V5 mechanism attempts to obtain initiating
   credentials for a service principal which are not available in a
   credentials cache, and the key for that service principal is
   available in a Kerberos V5 key table, the mechanism should use the
   service key to obtain initiating credentials for that service.  This
   should be accomplished by requesting a ticket-granting-ticket from
   the Kerberos Key Distribution Center (KDC), and decrypting the KDC's
   reply using the service key.

4. 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-1509.

4.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 implementors 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.



Linn                        Standards Track                    [Page 17]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


4.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" */
   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" */

4.1.2. Kerberos-specific-codes

   GSS_KRB5_S_KG_CCACHE_NOMATCH
           /* "Principal in credential cache does not match desired name" */
   GSS_KRB5_S_KG_KEYTAB_NOMATCH
           /* "No principal in keytab matches desired name" */
   GSS_KRB5_S_KG_TGT_MISSING
           /* "Credential cache has no TGT" */
   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" */

4.2. Quality of Protection Values

   This section defines Quality of Protection (QOP) values to be used
   with the Kerberos V5 GSS-API mechanism as input to GSS_Wrap() and
   GSS_GetMIC() routines in order to select among alternate integrity
   and confidentiality algorithms. Additional QOP values may be added in
   future versions of this specification.  Non-overlapping bit positions
   are and will be employed in order that both integrity and



Linn                        Standards Track                    [Page 18]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


   confidentiality QOP may be selected within a single parameter, via
   inclusive-OR of the specified integrity and confidentiality values.

4.2.1. Integrity Algorithms

   The following Quality of Protection (QOP) values are currently
   defined for the Kerberos V5 GSS-API mechanism, and are used to select
   among alternate integrity checking algorithms.

   GSS_KRB5_INTEG_C_QOP_MD5        (numeric value: 1)
           /* Integrity using partial MD5 ("MD2.5") of plaintext */

   GSS_KRB5_INTEG_C_QOP_DES_MD5    (numeric value: 2)
           /* Integrity using DES MAC of MD5 of plaintext */

   GSS_KRB5_INTEG_C_QOP_DES_MAC    (numeric value: 3)
           /* Integrity using DES MAC of plaintext */

4.2.2. Confidentiality Algorithms

   Only one confidentiality QOP value is currently defined for the
   Kerberos V5 GSS-API mechanism:

   GSS_KRB5_CONF_C_QOP_DES         (numeric value: 0)
           /* Confidentiality with DES */

   Note: confidentiality QOP should be indicated only by GSS-API calls
   capable of providing confidentiality services. If non-zero
   confidentiality QOP values are defined in future to represent
   different algorithms, therefore, the bit positions containing those
   values should be cleared before being returned by implementations of
   GSS_GetMIC() and GSS_VerifyMIC().

4.3. Buffer Sizes

   All implementations of this specification shall be capable of
   accepting buffers of at least 16 Kbytes 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 16 Kbyte input buffer
   as input to GSS_Unwrap(). Support for larger buffer sizes is optional
   but recommended.










Linn                        Standards Track                    [Page 19]

RFC 1964               Kerberos Version 5 GSS-API              June 1996


5. Security Considerations

   Security issues are discussed throughout this memo.

6. References


   [RFC-1321]: Rivest, R., "The MD5 Message-Digest Algorithm", RFC
   1321, April 1992.

   [RFC-1508]: Linn, J., "Generic Security Service Application Program
   Interface", RFC 1508, September 1993.

   [RFC-1509]: Wray, J., "Generic Security Service Application Program
   Interface: C-bindings", RFC 1509, September 1993.

   [RFC-1510]: Kohl, J., and C. Neuman, "The Kerberos Network
   Authentication Service (V5)", RFC 1510, September 1993.

   [FIPS-PUB-113]: National Bureau of Standards, Federal Information
   Processing Standard 113, "Computer Data Authentication", May 1985.

AUTHOR'S ADDRESS

   John Linn
   OpenVision Technologies
   One Main St.
   Cambridge, MA  02142  USA

   Phone: +1 617.374.2245
   EMail: John.Linn@ov.com




















Linn                        Standards Track                    [Page 20]