1
2
3NETWORK WORKING GROUP                                        N. Williams
4Internet-Draft                                                       Sun
5Expires: July 26, 2005                                  January 25, 2005
6
7
8                         Guide to the GSS-APIv3
9              draft-ietf-kitten-gssapi-v3-guide-to-00.txt
10
11Status of this Memo
12
13   By submitting this Internet-Draft, I certify that any applicable
14   patent or other IPR claims of which I am aware have been disclosed,
15   and any of which I become aware will be disclosed, in accordance with
16   RFC 3668.
17
18   Internet-Drafts are working documents of the Internet Engineering
19   Task Force (IETF), its areas, and its working groups.  Note that
20   other groups may also distribute working documents as
21   Internet-Drafts.
22
23   Internet-Drafts are draft documents valid for a maximum of six months
24   and may be updated, replaced, or obsoleted by other documents at any
25   time.  It is inappropriate to use Internet-Drafts as reference
26   material or to cite them other than as "work in progress."
27
28   The list of current Internet-Drafts can be accessed at
29   http://www.ietf.org/ietf/1id-abstracts.txt.
30
31   The list of Internet-Draft Shadow Directories can be accessed at
32   http://www.ietf.org/shadow.html.
33
34   This Internet-Draft will expire on July 26, 2005.
35
36Copyright Notice
37
38   Copyright (C) The Internet Society (2005).  All Rights Reserved.
39
40Abstract
41
42   Extensions to the GSS-APIv2 are needed for a number of reasons.  This
43   documents describes the extensions being proposed, the resons,
44   possible future directions, and portability, IANA and security
45   considerations.  This document does not define any protocol or
46   interface and is purely informational.
47
48
49
50
51
52
53
54
55Williams                 Expires July 26, 2005                  [Page 1]
56
57Internet-Draft           Guide to the GSS-APIv3             January 2005
58
59
60Table of Contents
61
62   1.  Conventions used in this document  . . . . . . . . . . . . . .  3
63   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
64   3.  A Pseudo-Mechanism OID for the GSS-API Itself  . . . . . . . .  5
65   4.  Mechanism Attribute Inquiry Facilities . . . . . . . . . . . .  6
66   5.  Security Context Extensibility Extensions  . . . . . . . . . .  7
67   6.  Credential Extensibility Extensions  . . . . . . . . . . . . .  8
68   7.  Credential Export/Import . . . . . . . . . . . . . . . . . . .  9
69   8.  GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10
70   9.  Pseudo-Mechanism Stacking  . . . . . . . . . . . . . . . . . . 11
71   10. Naming Extensions  . . . . . . . . . . . . . . . . . . . . . . 12
72   11. Additional Name Types  . . . . . . . . . . . . . . . . . . . . 13
73   12. GSS_Pseudo_random()  . . . . . . . . . . . . . . . . . . . . . 14
74   13. Channel Bindings Specifications  . . . . . . . . . . . . . . . 15
75   14. Semantic and Miscallaneous Extensions  . . . . . . . . . . . . 16
76   15. Portability Considerations . . . . . . . . . . . . . . . . . . 17
77   16. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
78   17. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
79   18. Normative  . . . . . . . . . . . . . . . . . . . . . . . . . . 19
80       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19
81       Intellectual Property and Copyright Statements . . . . . . . . 20
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
111Williams                 Expires July 26, 2005                  [Page 2]
112
113Internet-Draft           Guide to the GSS-APIv3             January 2005
114
115
1161.  Conventions used in this document
117
118   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
119   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
120   document are to be interpreted as described in [RFC2119].
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
167Williams                 Expires July 26, 2005                  [Page 3]
168
169Internet-Draft           Guide to the GSS-APIv3             January 2005
170
171
1722.  Introduction
173
174   [NOTE: the references section is current fairly empty; the various
175   KITTEN WG work items will be added to this I-D in a subsequent
176   revision.]
177
178   Since the advent of the GSS-APIv2 it has come to be used in a number
179   of Internet (and other) protocols and a number of implementations
180   exist.  In that time implementors and protocol designers have come to
181   understand both, the GSS-API's strengths, and its shortcommings; we
182   believe now that a number of extensions to the GSS-API are needed.
183   Here these proposed extensions, forming what we may call the GSS-API
184   version 3, are described at a high-level.;
185
186   Some of these extensions are intended to facilitate further
187   extensions, so that further major revisions to the GSS-API may not be
188   necessary.  Others are intended to fill voids in the the GSS-APIv2.
189
190   The extensions being proposed are:
191      A pseudo-mechanism OID for the GSS-API itself
192      Mechanism attribute inquiry facilities
193      Security context extensibility extensions
194      Credential extensibility extensions
195      Credential export/import
196      GSS_Store_cred(), for making delegated credentials available for
197      acquisition
198      Pseudo-mechanism stacking
199      Naming extensions, to facilitate authorization by identifiers
200      other than names
201      Additional name types, specifically domain-based naming
202      A pseudo-random function interface
203      Channel bindings specifications
204      Semantic extensions relating to thread- and/or fork-safety
205      [Have I missed anything?  I have a feeling I have.  Re-keying?]
206      ...
207
208   Additionally, because we foresee future minor extensions, including,
209   specifically, extensions which may impact the various namespaces
210   associated with APIs (symbol names, constant values, class names,
211   etc...) we also propose the establishment of IANA registries for
212   these namespaces.
213
214
215
216
217
218
219
220
221
222
223Williams                 Expires July 26, 2005                  [Page 4]
224
225Internet-Draft           Guide to the GSS-APIv3             January 2005
226
227
2283.  A Pseudo-Mechanism OID for the GSS-API Itself
229
230   A mechanism OID is assigned to identify and refer to the GSS-API
231   iself.  This is necessary to enable the use of extended inquiry
232   interfaces to inquire about features of a GSS-API implementation
233   specifically, apart from actual mechanisms.
234
235   But also, this OID is needed for better error handling, so that minor
236   status codes produced in generic contexts that lack a mechanism OID
237   can be distinguished from minor status codes for a "default"
238   mechanism and properly displayed.
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
279Williams                 Expires July 26, 2005                  [Page 5]
280
281Internet-Draft           Guide to the GSS-APIv3             January 2005
282
283
2844.  Mechanism Attribute Inquiry Facilities
285
286   In the course of designing a pseudo-mechanism stacking facility, as
287   well as while considering the impact of all of these extensions on
288   portability, a need for interfaces through which to discover or
289   inquire by features provided by GSS-API mechanisms was discovered.
290
291   The proposed mechanism attribute inquiry interfaces consist of:
292      GSS_Inquire_mech_attrs_for_mech()
293      GSS_Indicate_mechs_by_mech_attrs()
294      GSS_Display_mech_attr()
295
296   These extensions facilitate portability by allowing GSS-APIv3
297   applications to discover the features provided by a given
298   implementation of the GSS-API or any mechanisms.  These extensions
299   are also useful in facilitating stackable pseudo-mechanisms.
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
335Williams                 Expires July 26, 2005                  [Page 6]
336
337Internet-Draft           Guide to the GSS-APIv3             January 2005
338
339
3405.  Security Context Extensibility Extensions
341
342   In order to facilitate future security context options we introduce a
343   GSS_Create_sec_context() interface that creates a security context
344   object, for use with extensions and with GSS_Init_sec_context(),
345   GSS_Accept_sec_context(), and GSS_Inquire_sec_context().  Such
346   security contexts are in a non-established state until they are
347   established through the use of GSS_Init_sec_context() or
348   GSS_Accept_sec_context().
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
391Williams                 Expires July 26, 2005                  [Page 7]
392
393Internet-Draft           Guide to the GSS-APIv3             January 2005
394
395
3966.  Credential Extensibility Extensions
397
398   In order to facilitate future extensions to GSS credentials we
399   introduce a GSS_Create_credential(), similar to
400   GSS_Create_sec_context(), interface that creates an "empty"
401   credential.
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
447Williams                 Expires July 26, 2005                  [Page 8]
448
449Internet-Draft           Guide to the GSS-APIv3             January 2005
450
451
4527.  Credential Export/Import
453
454   To allow for passing of credentials between different "session
455   contexts," between different hosts, or for storage of post-dated
456   credentials, we introduce a credential export/import facility, much
457   like the security context export/import facility of the GSS-APIv2.
458
459   Together with credential extensibility and other extensions this
460   facility may allow for:
461      Credential delegation at any time
462      Post-dated credentials, and storage of the such for subsequent
463      use.
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
503Williams                 Expires July 26, 2005                  [Page 9]
504
505Internet-Draft           Guide to the GSS-APIv3             January 2005
506
507
5088.  GSS_Store_cred()
509
510   This extension fills a void in the GSS-APIv2 where delegated
511   credentials could not be used except in the context of the same
512   process that received them.  With this extension acceptor
513   applications can now make delegated credentials available for use,
514   with GSS_Acquire_cred() et.  al., in other process contexts.
515
516   [Manipulation of "credential stores" is (may be?) out of scope for
517   this document.]
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
559Williams                 Expires July 26, 2005                 [Page 10]
560
561Internet-Draft           Guide to the GSS-APIv3             January 2005
562
563
5649.  Pseudo-Mechanism Stacking
565
566   A number of pseudo-mechanisms are being proposed which are designed
567   to "stack" atop other mechanisms.  The possiblities are many,
568   including: a compression mechanism, a perfect forward security
569   mechanism, an many others.
570
571   The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
572   (SPNEGO) available.  With this proposal the mechanism taxonomy is
573   quite expanded:
574      Concrete mechanisms (e.g., the Kerberos V mechanism)
575      Composite mechanisms (a concrete mechanism composed with one or
576      more stackable pseudo-mechanisms)
577      Stackable pseudo-mechanisms
578      Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
579
580   Although composed mechanisms may be made available for use by
581   GSS-APIv2 applications without any further extensions, use of
582   stackable pseudo-mechanisms can complicate mechanism negotiation;
583   additionally, discovery of mechanisms appropriate for use in one or
584   another context would require hard-coding information about them in
585   GSS-APIv2 applications.  Extensions to the GSS-APIv2 could facilitate
586   use of composite.
587
588   The mechanism attribute inquiry facilities, together with the
589   forllowing additional interfaces, provide for a complete interface to
590   mechanism composition and for managing the complexity of mechanism
591   negotiation:
592      GSS_Compose_oid()
593      GSS_Decompose_oid()
594      GSS_Release_oid()
595      GSS_Indicate_negotiable_mechs()
596      GSS_Negotiate_mechs()
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615Williams                 Expires July 26, 2005                 [Page 11]
616
617Internet-Draft           Guide to the GSS-APIv3             January 2005
618
619
62010.  Naming Extensions
621
622   Some applications make use of exported names, as produced by
623   GSS_Export_name(), to create/manage/evaluate access control lists; we
624   call this name-based authorization.
625
626   Exported names typically encode names that are meant for display to
627   humans, not internal identifiers.
628
629   In practice this creates a number of problems.  E.g., the referential
630   integrity of such access control lists is hard to maintain as
631   principals are added, removed, renamed or old principal names reused.
632
633   Additionally, some mechanisms may lack a notion of a "canonical" name
634   for some or all of their principals.  Such mechanisms cannot be used
635   by applications that rely on name-based authorization.
636
637   <Describe the proposed extensions in this area.>
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
671Williams                 Expires July 26, 2005                 [Page 12]
672
673Internet-Draft           Guide to the GSS-APIv3             January 2005
674
675
67611.  Additional Name Types
677
678   <Decribe domain-based names and the need for them.>
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
727Williams                 Expires July 26, 2005                 [Page 13]
728
729Internet-Draft           Guide to the GSS-APIv3             January 2005
730
731
73212.  GSS_Pseudo_random()
733
734   <Decribe GSS_Pseudo_random() and the need for it.>
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
783Williams                 Expires July 26, 2005                 [Page 14]
784
785Internet-Draft           Guide to the GSS-APIv3             January 2005
786
787
78813.  Channel Bindings Specifications
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
839Williams                 Expires July 26, 2005                 [Page 15]
840
841Internet-Draft           Guide to the GSS-APIv3             January 2005
842
843
84414.  Semantic and Miscallaneous Extensions
845
846   The GSS-APIv2 specifications say nothing about the thread-safety,
847   much less the fork-safety, of the GSS-API.  Thread-safety and
848   fork-safety are, after all, platform- and/or language-specific
849   matters.  But as support for multi-threading spreads the matter of
850   thread-safety cannot be avoided.  The matter of fork-safety is
851   specific to platforms that provide a "fork()" function, or similar.
852
853   <describe the GSS-APIv3's thread-safety requirements>
854
855   <reference the portability considerations section>
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
895Williams                 Expires July 26, 2005                 [Page 16]
896
897Internet-Draft           Guide to the GSS-APIv3             January 2005
898
899
90015.  Portability Considerations
901
902   The potential for additional generic, mechanism-specific, language
903   binding-specific and, most importantly, semantic extensions to the
904   GSS-APIv3 may create application portability problems.  The mechanism
905   attribute inquiry facilities of the GSS-APIv3 and the
906   pseudo-mechanism OID for the GSS-API itself double as a run-time
907   facility for discovery of feature availability.  Run-time feature
908   discovery facilities, in turn, can be used at application build-time
909   as well by building small applications to display the available
910   features.
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
951Williams                 Expires July 26, 2005                 [Page 17]
952
953Internet-Draft           Guide to the GSS-APIv3             January 2005
954
955
95616.  IANA Considerations
957
958   <Describe the namespace issues associated with future minor
959   extensions to the GSS-APIv3 and the IANA registries to be created to
960   cope with them.>
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
1007Williams                 Expires July 26, 2005                 [Page 18]
1008
1009Internet-Draft           Guide to the GSS-APIv3             January 2005
1010
1011
101217.  Security Considerations
1013
1014   <...>
1015
101618  Normative
1017
1018   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
1019              Requirement Levels", BCP 14, RFC 2119, March 1997.
1020
1021   [RFC2743]  Linn, J., "Generic Security Service Application Program
1022              Interface Version 2, Update 1", RFC 2743, January 2000.
1023
1024   [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
1025              C-bindings", RFC 2744, January 2000.
1026
1027
1028Author's Address
1029
1030   Nicolas Williams
1031   Sun Microsystems
1032   5300 Riata Trace Ct
1033   Austin, TX  78727
1034   US
1035
1036   EMail: Nicolas.Williams@sun.com
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
1063Williams                 Expires July 26, 2005                 [Page 19]
1064
1065Internet-Draft           Guide to the GSS-APIv3             January 2005
1066
1067
1068Intellectual Property Statement
1069
1070   The IETF takes no position regarding the validity or scope of any
1071   Intellectual Property Rights or other rights that might be claimed to
1072   pertain to the implementation or use of the technology described in
1073   this document or the extent to which any license under such rights
1074   might or might not be available; nor does it represent that it has
1075   made any independent effort to identify any such rights.  Information
1076   on the procedures with respect to rights in RFC documents can be
1077   found in BCP 78 and BCP 79.
1078
1079   Copies of IPR disclosures made to the IETF Secretariat and any
1080   assurances of licenses to be made available, or the result of an
1081   attempt made to obtain a general license or permission for the use of
1082   such proprietary rights by implementers or users of this
1083   specification can be obtained from the IETF on-line IPR repository at
1084   http://www.ietf.org/ipr.
1085
1086   The IETF invites any interested party to bring to its attention any
1087   copyrights, patents or patent applications, or other proprietary
1088   rights that may cover technology that may be required to implement
1089   this standard.  Please address the information to the IETF at
1090   ietf-ipr@ietf.org.
1091
1092
1093Disclaimer of Validity
1094
1095   This document and the information contained herein are provided on an
1096   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1097   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1098   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1099   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1100   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1101   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1102
1103
1104Copyright Statement
1105
1106   Copyright (C) The Internet Society (2005).  This document is subject
1107   to the rights, licenses and restrictions contained in BCP 78, and
1108   except as set forth therein, the authors retain all their rights.
1109
1110
1111Acknowledgment
1112
1113   Funding for the RFC Editor function is currently provided by the
1114   Internet Society.
1115
1116
1117
1118
1119Williams                 Expires July 26, 2005                 [Page 20]
1120
1121
1122