4
NETWORK WORKING GROUP N. Williams
6
Expires: April 19, 2006 October 16, 2005
10
draft-ietf-kitten-gssapi-v3-guide-to-01.txt
14
By submitting this Internet-Draft, each author represents that any
15
applicable patent or other IPR claims of which he or she is aware
16
have been or will be disclosed, and any of which he or she becomes
17
aware will be disclosed, in accordance with Section 6 of BCP 79.
19
Internet-Drafts are working documents of the Internet Engineering
20
Task Force (IETF), its areas, and its working groups. Note that
21
other groups may also distribute working documents as Internet-
24
Internet-Drafts are draft documents valid for a maximum of six months
25
and may be updated, replaced, or obsoleted by other documents at any
26
time. It is inappropriate to use Internet-Drafts as reference
27
material or to cite them other than as "work in progress."
29
The list of current Internet-Drafts can be accessed at
30
http://www.ietf.org/ietf/1id-abstracts.txt.
32
The list of Internet-Draft Shadow Directories can be accessed at
33
http://www.ietf.org/shadow.html.
35
This Internet-Draft will expire on April 19, 2006.
39
Copyright (C) The Internet Society (2005).
43
Extensions to the GSS-APIv2 are needed for a number of reasons. This
44
documents describes the extensions being proposed, the resons,
45
possible future directions, and portability, IANA and security
46
considerations. This document does not define any protocol or
47
interface and is purely informational.
55
Williams Expires April 19, 2006 [Page 1]
57
Internet-Draft Guide to the GSS-APIv3 October 2005
62
1. Conventions used in this document . . . . . . . . . . . . . . 3
63
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
64
3. A Pseudo-Mechanism OID for the GSS-API Itself . . . . . . . . 6
65
4. Mechanism Attribute Inquiry Facilities . . . . . . . . . . . . 7
66
5. Security Context Extensibility Extensions . . . . . . . . . . 8
67
6. Credential Extensibility Extensions . . . . . . . . . . . . . 9
68
7. Credential Export/Import . . . . . . . . . . . . . . . . . . . 10
69
8. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 11
70
9. Pseudo-Mechanism Stacking . . . . . . . . . . . . . . . . . . 12
71
10. Naming Extensions . . . . . . . . . . . . . . . . . . . . . . 13
72
11. Additional Name Types . . . . . . . . . . . . . . . . . . . . 14
73
12. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 15
74
13. Channel Bindings Specifications . . . . . . . . . . . . . . . 16
75
14. Semantic and Miscallaneous Extensions . . . . . . . . . . . . 17
76
15. Portability Considerations . . . . . . . . . . . . . . . . . . 18
77
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
78
17. Security Considerations . . . . . . . . . . . . . . . . . . . 20
79
18. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 20
80
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21
81
Intellectual Property and Copyright Statements . . . . . . . . 22
111
Williams Expires April 19, 2006 [Page 2]
113
Internet-Draft Guide to the GSS-APIv3 October 2005
116
1. Conventions used in this document
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].
167
Williams Expires April 19, 2006 [Page 3]
169
Internet-Draft Guide to the GSS-APIv3 October 2005
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
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.;
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.
190
The extensions being proposed are:
192
A pseudo-mechanism OID for the GSS-API itself
194
Mechanism attribute inquiry facilities
196
Security context extensibility extensions
198
Credential extensibility extensions
200
Credential export/import
202
GSS_Store_cred(), for making delegated credentials available for
205
Pseudo-mechanism stacking
207
Naming extensions, to facilitate authorization by identifiers
210
Additional name types, specifically domain-based naming
212
A pseudo-random function interface
214
Channel bindings specifications
216
Semantic extensions relating to thread- and/or fork-safety
218
[Have I missed anything? I have a feeling I have. Re-keying?]
223
Williams Expires April 19, 2006 [Page 4]
225
Internet-Draft Guide to the GSS-APIv3 October 2005
230
Additionally, because we foresee future minor extensions, including,
231
specifically, extensions which may impact the various namespaces
232
associated with APIs (symbol names, constant values, class names,
233
etc...) we also propose the establishment of IANA registries for
279
Williams Expires April 19, 2006 [Page 5]
281
Internet-Draft Guide to the GSS-APIv3 October 2005
284
3. A Pseudo-Mechanism OID for the GSS-API Itself
286
A mechanism OID is assigned to identify and refer to the GSS-API
287
iself. This is necessary to enable the use of extended inquiry
288
interfaces to inquire about features of a GSS-API implementation
289
specifically, apart from actual mechanisms.
291
But also, this OID is needed for better error handling, so that minor
292
status codes produced in generic contexts that lack a mechanism OID
293
can be distinguished from minor status codes for a "default"
294
mechanism and properly displayed.
335
Williams Expires April 19, 2006 [Page 6]
337
Internet-Draft Guide to the GSS-APIv3 October 2005
340
4. Mechanism Attribute Inquiry Facilities
342
In the course of designing a pseudo-mechanism stacking facility, as
343
well as while considering the impact of all of these extensions on
344
portability, a need for interfaces through which to discover or
345
inquire by features provided by GSS-API mechanisms was discovered.
347
The proposed mechanism attribute inquiry interfaces consist of:
349
GSS_Inquire_mech_attrs_for_mech()
351
GSS_Indicate_mechs_by_mech_attrs()
353
GSS_Display_mech_attr()
355
These extensions facilitate portability by allowing GSS-APIv3
356
applications to discover the features provided by a given
357
implementation of the GSS-API or any mechanisms. These extensions
358
are also useful in facilitating stackable pseudo-mechanisms.
391
Williams Expires April 19, 2006 [Page 7]
393
Internet-Draft Guide to the GSS-APIv3 October 2005
396
5. Security Context Extensibility Extensions
398
In order to facilitate future security context options we introduce a
399
GSS_Create_sec_context() interface that creates a security context
400
object, for use with extensions and with GSS_Init_sec_context(),
401
GSS_Accept_sec_context(), and GSS_Inquire_sec_context(). Such
402
security contexts are in a non-established state until they are
403
established through the use of GSS_Init_sec_context() or
404
GSS_Accept_sec_context().
447
Williams Expires April 19, 2006 [Page 8]
449
Internet-Draft Guide to the GSS-APIv3 October 2005
452
6. Credential Extensibility Extensions
454
In order to facilitate future extensions to GSS credentials we
455
introduce a GSS_Create_credential(), similar to
456
GSS_Create_sec_context(), interface that creates an "empty"
503
Williams Expires April 19, 2006 [Page 9]
505
Internet-Draft Guide to the GSS-APIv3 October 2005
508
7. Credential Export/Import
510
To allow for passing of credentials between different "session
511
contexts," between different hosts, or for storage of post-dated
512
credentials, we introduce a credential export/import facility, much
513
like the security context export/import facility of the GSS-APIv2.
515
Together with credential extensibility and other extensions this
516
facility may allow for:
518
Credential delegation at any time
520
Post-dated credentials, and storage of the such for subsequent
559
Williams Expires April 19, 2006 [Page 10]
561
Internet-Draft Guide to the GSS-APIv3 October 2005
566
This extension fills a void in the GSS-APIv2 where delegated
567
credentials could not be used except in the context of the same
568
process that received them. With this extension acceptor
569
applications can now make delegated credentials available for use,
570
with GSS_Acquire_cred() et. al., in other process contexts.
572
[Manipulation of "credential stores" is (may be?) out of scope for
615
Williams Expires April 19, 2006 [Page 11]
617
Internet-Draft Guide to the GSS-APIv3 October 2005
620
9. Pseudo-Mechanism Stacking
622
A number of pseudo-mechanisms are being proposed which are designed
623
to "stack" atop other mechanisms. The possiblities are many,
624
including: a compression mechanism, a perfect forward security
625
mechanism, an many others.
627
The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism
628
(SPNEGO) available. With this proposal the mechanism taxonomy is
631
Concrete mechanisms (e.g., the Kerberos V mechanism)
633
Composite mechanisms (a concrete mechanism composed with one or
634
more stackable pseudo-mechanisms)
636
Stackable pseudo-mechanisms
638
Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself)
640
Although composed mechanisms may be made available for use by GSS-
641
APIv2 applications without any further extensions, use of stackable
642
pseudo-mechanisms can complicate mechanism negotiation; additionally,
643
discovery of mechanisms appropriate for use in one or another context
644
would require hard-coding information about them in GSS-APIv2
645
applications. Extensions to the GSS-APIv2 could facilitate use of
648
The mechanism attribute inquiry facilities, together with the
649
forllowing additional interfaces, provide for a complete interface to
650
mechanism composition and for managing the complexity of mechanism
659
GSS_Indicate_negotiable_mechs()
661
GSS_Negotiate_mechs()
671
Williams Expires April 19, 2006 [Page 12]
673
Internet-Draft Guide to the GSS-APIv3 October 2005
676
10. Naming Extensions
678
Some applications make use of exported names, as produced by
679
GSS_Export_name(), to create/manage/evaluate access control lists; we
680
call this name-based authorization.
682
Exported names typically encode names that are meant for display to
683
humans, not internal identifiers.
685
In practice this creates a number of problems. E.g., the referential
686
integrity of such access control lists is hard to maintain as
687
principals are added, removed, renamed or old principal names reused.
689
Additionally, some mechanisms may lack a notion of a "canonical" name
690
for some or all of their principals. Such mechanisms cannot be used
691
by applications that rely on name-based authorization.
693
<Describe the proposed extensions in this area.>
727
Williams Expires April 19, 2006 [Page 13]
729
Internet-Draft Guide to the GSS-APIv3 October 2005
732
11. Additional Name Types
734
<Decribe domain-based names and the need for them.>
783
Williams Expires April 19, 2006 [Page 14]
785
Internet-Draft Guide to the GSS-APIv3 October 2005
788
12. GSS_Pseudo_random()
790
<Decribe GSS_Pseudo_random() and the need for it.>
839
Williams Expires April 19, 2006 [Page 15]
841
Internet-Draft Guide to the GSS-APIv3 October 2005
844
13. Channel Bindings Specifications
895
Williams Expires April 19, 2006 [Page 16]
897
Internet-Draft Guide to the GSS-APIv3 October 2005
900
14. Semantic and Miscallaneous Extensions
902
The GSS-APIv2 specifications say nothing about the thread-safety,
903
much less the fork-safety, of the GSS-API. Thread-safety and fork-
904
safety are, after all, platform- and/or language-specific matters.
905
But as support for multi-threading spreads the matter of thread-
906
safety cannot be avoided. The matter of fork-safety is specific to
907
platforms that provide a "fork()" function, or similar.
909
<describe the GSS-APIv3's thread-safety requirements>
911
<reference the portability considerations section>
951
Williams Expires April 19, 2006 [Page 17]
953
Internet-Draft Guide to the GSS-APIv3 October 2005
956
15. Portability Considerations
958
The potential for additional generic, mechanism-specific, language
959
binding-specific and, most importantly, semantic extensions to the
960
GSS-APIv3 may create application portability problems. The mechanism
961
attribute inquiry facilities of the GSS-APIv3 and the pseudo-
962
mechanism OID for the GSS-API itself double as a run-time facility
963
for discovery of feature availability. Run-time feature discovery
964
facilities, in turn, can be used at application build-time as well by
965
building small applications to display the available features.
1007
Williams Expires April 19, 2006 [Page 18]
1009
Internet-Draft Guide to the GSS-APIv3 October 2005
1012
16. IANA Considerations
1014
<Describe the namespace issues associated with future minor
1015
extensions to the GSS-APIv3 and the IANA registries to be created to
1063
Williams Expires April 19, 2006 [Page 19]
1065
Internet-Draft Guide to the GSS-APIv3 October 2005
1068
17. Security Considerations
1074
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1075
Requirement Levels", BCP 14, RFC 2119, March 1997.
1077
[RFC2743] Linn, J., "Generic Security Service Application Program
1078
Interface Version 2, Update 1", RFC 2743, January 2000.
1080
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
1081
C-bindings", RFC 2744, January 2000.
1119
Williams Expires April 19, 2006 [Page 20]
1121
Internet-Draft Guide to the GSS-APIv3 October 2005
1132
Email: Nicolas.Williams@sun.com
1175
Williams Expires April 19, 2006 [Page 21]
1177
Internet-Draft Guide to the GSS-APIv3 October 2005
1180
Intellectual Property Statement
1182
The IETF takes no position regarding the validity or scope of any
1183
Intellectual Property Rights or other rights that might be claimed to
1184
pertain to the implementation or use of the technology described in
1185
this document or the extent to which any license under such rights
1186
might or might not be available; nor does it represent that it has
1187
made any independent effort to identify any such rights. Information
1188
on the procedures with respect to rights in RFC documents can be
1189
found in BCP 78 and BCP 79.
1191
Copies of IPR disclosures made to the IETF Secretariat and any
1192
assurances of licenses to be made available, or the result of an
1193
attempt made to obtain a general license or permission for the use of
1194
such proprietary rights by implementers or users of this
1195
specification can be obtained from the IETF on-line IPR repository at
1196
http://www.ietf.org/ipr.
1198
The IETF invites any interested party to bring to its attention any
1199
copyrights, patents or patent applications, or other proprietary
1200
rights that may cover technology that may be required to implement
1201
this standard. Please address the information to the IETF at
1205
Disclaimer of Validity
1207
This document and the information contained herein are provided on an
1208
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1209
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1210
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1211
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1212
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1213
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1218
Copyright (C) The Internet Society (2005). This document is subject
1219
to the rights, licenses and restrictions contained in BCP 78, and
1220
except as set forth therein, the authors retain all their rights.
1225
Funding for the RFC Editor function is currently provided by the
1231
Williams Expires April 19, 2006 [Page 22]
added
removed
doc/standardisation/draft-ietf-kitten-gssapi-v3-guide-to-01.txt
