x
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14336 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
674
doc/standardisation/draft-hartman-gss-naming-01.txt
Normal file
674
doc/standardisation/draft-hartman-gss-naming-01.txt
Normal file
@@ -0,0 +1,674 @@
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Hartman
|
||||
Internet-Draft MIT
|
||||
Expires: April 24, 2005 October 24, 2004
|
||||
|
||||
|
||||
GSSAPI Mechanisms without a Single Canonical Name
|
||||
draft-hartman-gss-naming-01.txt
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document is an Internet-Draft and is subject to all provisions
|
||||
of section 3 of RFC 3667. By submitting this Internet-Draft, each
|
||||
author represents that any applicable patent or other IPR claims of
|
||||
which he or she is aware have been or will be disclosed, and any of
|
||||
which he or she become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
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.
|
||||
|
||||
This Internet-Draft will expire on April 24, 2005.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2004).
|
||||
|
||||
Abstract
|
||||
|
||||
The Generic Security Services API (GSSAPI) provides a naming
|
||||
architecture that supports name-based authorization. GSSAPI
|
||||
authenticates two named parties to each other. Names can be stored
|
||||
on access control lists to make authorization decisions. Advances in
|
||||
security mechanisms and the way implementers wish to use GSSAPI
|
||||
require this model to be extended. Some mechanisms such as
|
||||
public-key mechanisms do not have a single name to be used. Other
|
||||
mechanisms such as Kerberos allow names to change as people move
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 1]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
around organizations. This document proposes expanding the
|
||||
definition of GSSAPI names to deal with these situations.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 2]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Generic Security Services API [1] provides a function called
|
||||
gss_export_name that will flatten a GSSAPI name into a binary blob
|
||||
suitable for comparisons. This binary blob can be stored on ACLs and
|
||||
then authorization decisions can be made simply by comparing the name
|
||||
exported from a newly accepted context to the name on the ACL.
|
||||
|
||||
As a side effect of this model, each mechanism name needs to be able
|
||||
to be represented in a single canonical form and anyone importing
|
||||
that name needs to be able to retrieve the canonical form.
|
||||
|
||||
Several security mechanisms have been proposed for which this naming
|
||||
architecture is too restrictive. In some cases it is not always
|
||||
possible to canonicalize any name that is imported. In other cases
|
||||
there is no single canonical name. In addition, there is a desire to
|
||||
have more complex authorization models in GSSAPI than the current
|
||||
name based authorization model.
|
||||
|
||||
This draft discusses two different cases where the current GSSAPI
|
||||
naming seems inadequate. Two proposals that have been discussed
|
||||
within the IETF Kitten community are discussed. Finally, the
|
||||
problems that need to be resolved to adopt either of these proposals
|
||||
are discussed.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 3]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
2. Kerberos Naming
|
||||
|
||||
The Kerberos Referrals draft [2] proposes a new type of Kerberos name
|
||||
called an enterprise name. The intent is that the enterprise name is
|
||||
an alias that the user knows for themselves and can use to login.
|
||||
The Kerberos KDC translates this name into a normal Kerberos
|
||||
principal and gives the user tickets for this principal. This normal
|
||||
principal is used for authorization. The intent is that the
|
||||
enterprise name tracks the user as they move throughout the
|
||||
organization, even if they move to parts of the organization that
|
||||
have different naming policies. The name they type at login remains
|
||||
constant, but the Kerberos principal used to authenticate them to
|
||||
services changes.
|
||||
|
||||
Performing a mapping from enterprise name to principal name is not
|
||||
generally possible for unauthenticated services. So in order to
|
||||
canonicalize an enterprise name to get a principal, a service must
|
||||
have credentials. However it may not be desirable to allow services
|
||||
to map enterprise names to principal names in the general case.
|
||||
Also, Kerberos does not (and does not plan to) provide a mechanism
|
||||
for mapping enterprise names to principals besides authentication as
|
||||
the enterprise name. So any such mapping would be vendor-specific.
|
||||
With this feature in Kerberos, it is not possible to implement
|
||||
gss_canonicalize_name for enterprise name types.
|
||||
|
||||
Another issue arises with enterprise names. IN some cases it would
|
||||
be desirable to put the enterprise name on the ACL instead of a
|
||||
principal name. Thus, it would be desirable to include the
|
||||
enterprise name in the name exported by gss_export_name. However
|
||||
then the exported name would change whenever the mapping changed,
|
||||
defeating the purpose of including the enterprise name. So in some
|
||||
cases it would be desirable to have the exported name be based on the
|
||||
enterprise name and in others based on the principal name, but this
|
||||
is not currently possible.
|
||||
|
||||
Another development also complicates GSSAPI naming for Kerberos.
|
||||
Several vendors have been looking at mechanisms to include group
|
||||
membership information in Kerberos authorization data. It is
|
||||
desirable to put these group names on ACLs. Again, GSSAPI currently
|
||||
has no mechanism to use this information.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 4]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
3. X.509 Names
|
||||
|
||||
X.509 names are at least as complex as Kerberos names. It seems like
|
||||
you might want to use the subject name as the name to be exported in
|
||||
a GSSAPI mechanism. However RFC 3280 [3] does not even require the
|
||||
subject name to be a non-empty sequence. Instead there are cases
|
||||
where the subjectAltName extension is the only thing to identify the
|
||||
subject of the certificate. As in the case of Kerberos group
|
||||
memberships, there may be many subjectAltName extensions available in
|
||||
a certificate. Different applications will care about different
|
||||
extensions. Thus there is no single value that can be defined as
|
||||
the exported GSSAPI name that will be generally useful.
|
||||
|
||||
A profile of a particular X.509 GSSAPI mechanism could require a
|
||||
specific name be used. However this would limit that mechanism to
|
||||
require a particular type of certificate. There is interest in being
|
||||
able to use arbitrary X.509 certificates with GSSAPI for some
|
||||
applications.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 5]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
4. Composite Names
|
||||
|
||||
One proposal to solve these problems is to extend the concept of a
|
||||
GSSAPI name to include a set of name attributes. Each attribute
|
||||
would be an octet-string labeled by an OID. Examples of attributes
|
||||
would include Kerberos enterprise names, group memberships in an
|
||||
authorization infrastructure, Kerberos authorization data attributes
|
||||
and subjectAltName attributes in a certificate. Several new
|
||||
operations would be needed:
|
||||
1. Add attribute to name
|
||||
2. Query attributes of name
|
||||
3. Query values of an attribute
|
||||
4. Delete an attribute from a name
|
||||
|
||||
4.1 Usage of Name Attributes
|
||||
|
||||
Since attributes are part of GSSAPI names, the acceptor can retrieve
|
||||
the attributes of the initiator's name from the context. These
|
||||
attributes can then be used for authorization.
|
||||
|
||||
Most name attributes will probably not come from explicit operations
|
||||
to add attributes to a name. Instead, name attributes will probably
|
||||
come from mechanism specific credentials. Mechanism specific naming
|
||||
and group membership can be mapped into name attributes by the
|
||||
mechanism implementation. The specific form of this mapping will
|
||||
general require protocol specification for each mechanism.
|
||||
|
||||
4.2 Open issues
|
||||
|
||||
This section describes parts of the proposal to add attributes to
|
||||
names that will need to be explored before the proposal can become a
|
||||
protocol specification.
|
||||
|
||||
Are mechanisms expected to be able to carry arbitrary name attributes
|
||||
as part of a context establishment? At first it seems like this
|
||||
would be desirable. However the point of GSSAPI is to establish an
|
||||
authenticated context between two peers. In particular, a context
|
||||
authenticates two named entities to each other. The names of these
|
||||
entities and attributes associated with these names will be used for
|
||||
authorization decisions. If an initiator or acceptor is allowed to
|
||||
assert name attributes and the authenticity of these assertions is
|
||||
not validated by the mechanisms, then security problems may result.
|
||||
On the other hand, requiring that name attributes be mechanism
|
||||
specific and only be carried by mechanisms that understand the name
|
||||
attributes and can validate them compromises GSSAPI's place as a
|
||||
generic API. Application authors would be forced to understand
|
||||
mechanism-specific attributes to make authorization decisions. In
|
||||
addition if mechanisms are not required to transport arbitrary
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 6]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
attributes, then application authors will need to deal with different
|
||||
implementations of the same mechanism that support different sets of
|
||||
name attributes. One possible solution is to carry a source along
|
||||
with each name attribute; this source could indicate whether the
|
||||
attribute comes from a mechanism data structure or from the other
|
||||
party in the authentication.
|
||||
|
||||
Another related question is how will name attributes be mapped into
|
||||
their mechanism-specific forms. For example it would be desirable to
|
||||
map many Kerberos authorization data elements into name attributes.
|
||||
In the case of the Microsoft PAC, it would be desirable for some
|
||||
applications to get the entire PAC. However in many cases, the
|
||||
specific lists of security IDs contained in the PAC would be more
|
||||
directly useful to an application. So there may not be a good
|
||||
one-to-one mapping between the mechanism-specific elements and the
|
||||
representation desirable at the GSSAPI layer.
|
||||
|
||||
Specific name matching rules need to be developed. How do names with
|
||||
attributes compare? What is the effect of a name attribute on a
|
||||
target name in gss_accept_sec_context?
|
||||
|
||||
4.3 Handling gss_export_name
|
||||
|
||||
For many mechanisms, there will be an obvious choice to use for the
|
||||
name exported by gss_export_name. For example in the case of
|
||||
Kerberos, the principal name can continue to be used as the exported
|
||||
name. This will allow applications depending on existing GSSAPI
|
||||
name-based authorization to continue to work. However it is probably
|
||||
desirable to allow GSSAPI mechanisms for which gss_export_name cannot
|
||||
meaningfully be defined. The behavior of gss_export_name in such
|
||||
cases should probably be to return some error. Such mechanisms may
|
||||
not work with existing applications and cannot conform to the current
|
||||
version of the GSSAPI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 7]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
5. Credential Extensions
|
||||
|
||||
An alternative to the name attributes proposal is to extend GSSAPI
|
||||
credentials with extensions labeled by OIDs. Interfaces would be
|
||||
needed to manipulate these credential extensions and to retrieve the
|
||||
credential extensions for credentials used to establish a context.
|
||||
Even if name attributes are used, credential extensions may be useful
|
||||
for other unrelated purposes.
|
||||
|
||||
It is possible to solve problems discussed in this document using
|
||||
some credential extension mechanism. Doing so will have many of the
|
||||
same open issues as discussed in the name attributes proposal. The
|
||||
main advantage of a credential extensions proposal is that it avoids
|
||||
specifying how name attributes interact with name comparison or
|
||||
target names.
|
||||
|
||||
The primary advantage of the name attributes proposal over credential
|
||||
extensions is that name attributes seem to fit better into the GSSAPI
|
||||
authorization model. Names are already available at all points when
|
||||
authorization decisions are made. In addition, for many mechanisms
|
||||
the sort of information carried as name attributes will also be
|
||||
carried as part of the name in the mechanism
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 8]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
6. Mechanisms for Export Name
|
||||
|
||||
Another proposal is to define some GSSAPI mechanisms whose only
|
||||
purpose is to have an exportable name form that is useful. For
|
||||
example, you might be able to export a name as a local machine user
|
||||
ID with such a mechanism.
|
||||
|
||||
This solution works well especially for name information that can be
|
||||
looked up in a directory. It was unclear from the discussion whether
|
||||
this solution would allow mechanism-specific name information to be
|
||||
extracted from a context. If so, then this solution would meet many
|
||||
of the goals of this document.
|
||||
|
||||
One advantage of this solution is that it requires few if any changes
|
||||
to GSSAPI semantics. It is not as flexible as other solutions.
|
||||
Also, it is not clear how to handle mechanisms that do not have a
|
||||
well defined name to export with this solution.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 9]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
GSSAPI sets up a security context between two named parties. The
|
||||
GSSAPI names are security assertions that are authenticated by the
|
||||
context establishment process. As such the GSS naming architecture
|
||||
is critical to the security of GSSAPI.
|
||||
|
||||
Currently GSSAPI uses a simplistic naming model for authorization.
|
||||
Names can be compared against a set of names on an access control
|
||||
list. This architecture is relatively simple and its security
|
||||
properties are well understood. However it does not provide the
|
||||
flexibility and feature set for future deployments of GSSAPI.
|
||||
|
||||
This proposal will significantly increase the complexity of the GSS
|
||||
naming architecture. As this proposal is fleshed out, we need to
|
||||
consider ways of managing security exposures created by this
|
||||
increased complexity.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 10]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
8. Acknowledgements
|
||||
|
||||
John Brezak, Paul Leach and Nicolas Williams all participated in
|
||||
discussions that defined the problem this proposal attempts to solve.
|
||||
Nicolas Williams and I discussed details of proposals to solve this
|
||||
problem. However the details and open issues presented here have
|
||||
only been reviewed by me and so I am responsible for their errors.
|
||||
|
||||
9 Informative References
|
||||
|
||||
[1] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
[2] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
|
||||
KDC Referrals to locate Kerberos realms",
|
||||
draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
|
||||
2004.
|
||||
|
||||
[3] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
|
||||
Public Key Infrastructure Certificate and Certificate Revocation
|
||||
List (CRL) Profile", rfc 3280, April 2002.
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Sam Hartman
|
||||
MIT
|
||||
|
||||
EMail: hartmans@mit.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 11]
|
||||
|
||||
Internet-Draft GSS Name Attributes October 2004
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Hartman Expires April 24, 2005 [Page 12]
|
||||
|
||||
|
1249
doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
Normal file
1249
doc/standardisation/draft-ietf-cat-kerberos-pk-init-21.txt
Normal file
File diff suppressed because it is too large
Load Diff
961
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
Normal file
961
doc/standardisation/draft-ietf-krb-wg-kerberos-referrals-05.txt
Normal file
@@ -0,0 +1,961 @@
|
||||
|
||||
|
||||
NETWORK WORKING GROUP L. Zhu
|
||||
Internet-Draft K. Jaganathan
|
||||
Obsoletes: 2478 (if approved) Microsoft Corporation
|
||||
Expires: April 25, 2005 October 25, 2004
|
||||
|
||||
|
||||
Generating KDC Referrals to locate Kerberos realms
|
||||
draft-ietf-krb-wg-kerberos-referrals-05
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document is an Internet-Draft and is subject to all provisions
|
||||
of section 3 of RFC 3667. By submitting this Internet-Draft, each
|
||||
author represents that any applicable patent or other IPR claims of
|
||||
which he or she is aware have been or will be disclosed, and any of
|
||||
which he or she become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
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.
|
||||
|
||||
This Internet-Draft will expire on April 25, 2005.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2004).
|
||||
|
||||
Abstract
|
||||
|
||||
The memo documents a method for a Kerberos Key Distribution Center
|
||||
(KDC) to respond to client requests for Kerberos tickets when the
|
||||
client does not have detailed configuration information on the realms
|
||||
of users or services. The KDC will handle requests for principals in
|
||||
other realms by returning either a referral error or a cross-realm
|
||||
TGT to another realm on the referral path. The clients will use this
|
||||
referral information to reach the realm of the target principal and
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 1]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
then receive the ticket.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||||
2. Conventions Used in This Document . . . . . . . . . . . . . 5
|
||||
3. Requesting a Referral . . . . . . . . . . . . . . . . . . . 6
|
||||
4. Realm Organization Model . . . . . . . . . . . . . . . . . . 7
|
||||
5. Client Name Canonicalization . . . . . . . . . . . . . . . . 8
|
||||
6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . 9
|
||||
7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
8. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . 12
|
||||
9. Compatibility with Earlier Implementations of Name
|
||||
Canonicalization . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
10. Security Considerations . . . . . . . . . . . . . . . . . . 14
|
||||
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15
|
||||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
|
||||
12.1 Normative References . . . . . . . . . . . . . . . . . . . 16
|
||||
12.2 Informative References . . . . . . . . . . . . . . . . . . 16
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16
|
||||
Intellectual Property and Copyright Statements . . . . . . . 17
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 2]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Current implementations of the Kerberos AS and TGS protocols, as
|
||||
defined in [KRBCLR], use principal names constructed from a known
|
||||
user or service name and realm. A service name is typically
|
||||
constructed from a name of the service and the DNS host name of the
|
||||
computer that is providing the service. Many existing deployments of
|
||||
Kerberos use a single Kerberos realm where all users and services
|
||||
would be using the same realm. However in an environment where there
|
||||
are multiple trusted Kerberos realms, the client needs to be able to
|
||||
determine what realm a particular user or service is in before making
|
||||
an AS or TGS request. Traditionally this requires client
|
||||
configuration to make this possible.
|
||||
|
||||
When having to deal with multiple trusted realms, users are forced to
|
||||
know what realm they are in before they can obtain a ticket granting
|
||||
ticket (TGT) with an AS request. However, in many cases the user
|
||||
would like to use a more familiar name that is not directly related
|
||||
to the realm of their Kerberos principal name. A good example of
|
||||
this is an RFC 822 style email name [RFC822]. This document
|
||||
describes a mechanism that would allow a user to specify a user
|
||||
principal name that is an alias for the user's Kerberos principal
|
||||
name. In practice this would be the name that the user specifies to
|
||||
obtain a TGT from a Kerberos KDC. The user principal name no longer
|
||||
has a direct relationship with the Kerberos principal or realm. Thus
|
||||
the administrator is able to move the user's principal to other
|
||||
realms without the user having to know that it happened.
|
||||
|
||||
Once a user has a TGT, they would like to be able to access services
|
||||
in any trusted Kerberos realm. To do this requires that the client
|
||||
be able to determine what realm the target service principal is in
|
||||
before making the TGS request. Current implementations of Kerberos
|
||||
typically have a table that maps DNS host names to corresponding
|
||||
Kerberos realms. In order for this to work on the client, each
|
||||
application canonicalizes the host name of the service, for example
|
||||
by doing a DNS lookup followed by a reverse lookup using the returned
|
||||
IP address. The returned primary host name is then used in the
|
||||
construction of the principal name for the target service. In order
|
||||
for the correct realm to be added for the target host, the mapping
|
||||
table [domain_to_realm] is consulted for the realm corresponding to
|
||||
the DNS host name. The corresponding realm is then used to complete
|
||||
the target service principal name.
|
||||
|
||||
This traditional mechanism requires that each client have very
|
||||
detailed configuration information about the hosts that are providing
|
||||
services and their corresponding realms. Having client side
|
||||
configuration information can be very costly from an administration
|
||||
point of view - especially if there are many realms and computers in
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 3]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
the environment.
|
||||
|
||||
There are also cases where specific DNS aliases (local names) have
|
||||
been setup in an organization to refer to a server in another
|
||||
organization (remote server). The server has different DNS names in
|
||||
each organization and each organization has a Kerberos realm that is
|
||||
configured to service DNS names within that organization. Ideally
|
||||
users are able to authenticate to the server in the other
|
||||
organization using the local server name. This would mean that the
|
||||
local realm be able to produce a ticket to the remote server under
|
||||
its name. You could give that remote server an identity in the local
|
||||
realm and then have that remote server maintain a separate secret for
|
||||
each alias it is known as. Alternatively you could arrange to have
|
||||
the local realm issue a referral to the remote realm and notify the
|
||||
requesting client of the server's remote name that should be used in
|
||||
order to request a ticket.
|
||||
|
||||
This memo proposes a solution for these problems and simplifies
|
||||
administration by minimizing the configuration information needed on
|
||||
each computer using Kerberos. Specifically it describes a mechanism
|
||||
to allow the KDC to handle canonicalization of names, provide for
|
||||
principal aliases for users and services and provide a mechanism for
|
||||
the KDC to determine the trusted realm authentication path by being
|
||||
able to generate referrals to other realms in order to locate
|
||||
principals.
|
||||
|
||||
Two kinds of KDC referrals are introduced in this memo:
|
||||
|
||||
1. Client referrals, in which the client doesn't know which realm
|
||||
contains a user account.
|
||||
2. Server referrals, in which the client doesn't know which realm
|
||||
contains a server account.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 4]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
2. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 5]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
3. Requesting a Referral
|
||||
|
||||
In order to request referrals defined in section 5, 6, and 7, the
|
||||
Kerberos client MUST explicitly request the canonicalize KDC option
|
||||
(bit 15) [KRBCLR] for the AS-REQ or TGS-REQ. This flag indicates to
|
||||
the KDC that the client is prepared to receive a reply that contains
|
||||
a principal name other than the one requested.
|
||||
|
||||
|
||||
KDCOptions ::= KerberosFlags
|
||||
-- canonicalize (15)
|
||||
-- other KDCOptions values omitted
|
||||
|
||||
The client should expect, when sending names with the "canonicalize"
|
||||
KDC option, that names in the KDC's reply MAY be different than the
|
||||
name in the request. A referral TGT is a cross realm TGT that is
|
||||
returned with the server name of the ticket being different from the
|
||||
server name in the request [KRBCLR].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 6]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
4. Realm Organization Model
|
||||
|
||||
This memo assumes that the world of principals is arranged on
|
||||
multiple levels: the realm, the enterprise, and the world. A KDC may
|
||||
issue tickets for any principal in its realm or cross-realm tickets
|
||||
for realms with which it has a direct trust relationship. The KDC
|
||||
also has access to a trusted name service that can resolve any name
|
||||
from within its enterprise into a realm. This trusted name service
|
||||
removes the need to use an un-trusted DNS lookup for name resolution.
|
||||
|
||||
For example, consider the following configuration, where lines
|
||||
indicate trust relationships:
|
||||
|
||||
MS.COM
|
||||
/ \
|
||||
/ \
|
||||
OFFICE.MS.COM NTDEV.MS.COM
|
||||
|
||||
In this configuration, all users in the MS.COM enterprise could have
|
||||
a principal name such as alice@MS.COM, with the same realm portion.
|
||||
In addition, servers at MS.COM should be able to have DNS host names
|
||||
from any DNS domain independent of what Kerberos realm their
|
||||
principals reside in.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 7]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
5. Client Name Canonicalization
|
||||
|
||||
A client account may have multiple principal names. More useful,
|
||||
though, is a globally unique name that allows unification of email
|
||||
and security principal names. For example, all users at MS may have
|
||||
a client principal name of the form "joe@MS.COM" even though the
|
||||
principals are contained in multiple realms. This global name is
|
||||
again an alias for the true client principal name, which indicates
|
||||
what realm contains the principal. Thus, accounts "alice" in the
|
||||
realm NTDEV.MS.COM and "bob" in OFFICE.MS.COM may logon as
|
||||
"alice@MS.COM" and "bob@MS.COM".
|
||||
|
||||
This utilizes a new client principal name type, as the AS-REQ message
|
||||
only contains a single realm field, and the realm portion of this
|
||||
name doesn't correspond to any Kerberos realm. Thus, the entire name
|
||||
"alice@MS.COM" is transmitted as a single component in the client
|
||||
name field of the AS-REQ message, with a name type of NT-ENTERPRISE
|
||||
[KRBCLR]. The KDC will recognize this name type and then transform
|
||||
the requested name into the true principal name. The true principal
|
||||
name can be using a name type different from the requested name type.
|
||||
Typically the true principal name will be a NT-PRINCIPAL [KRBCLR].
|
||||
|
||||
If the "canonicalize" KDC option is set, then the KDC MAY change the
|
||||
client principal name and type in the AS response and ticket returned
|
||||
from the name type of the client name in the request. For example
|
||||
the AS request may specify a client name of "bob@MS.COM" as an
|
||||
NT-ENTERPRISE name with the "canonicalize" KDC option set and the KDC
|
||||
will return with a client name of "104567" as a NT-UID.
|
||||
|
||||
It is assumed that the client discovers whether the KDC supports the
|
||||
NT-ENTERPRISE name type via out of band mechanisms.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 8]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
6. Client Referrals
|
||||
|
||||
The simplest form of ticket referral is for a user requesting a
|
||||
ticket using an AS-REQ. In this case, the client machine will send
|
||||
the AS-REQ to a convenient trusted realm, for example the realm of
|
||||
the client machine. In the case of the name alice@MS.COM, the client
|
||||
MAY optimistically choose to send the request to MS.COM. The realm
|
||||
in the AS-REQ is always the name of the realm that the request is for
|
||||
as specified in [KRBCLR].
|
||||
|
||||
The KDC will try to lookup the name in its local account database.
|
||||
If the account is present in the realm of the request, it SHOULD
|
||||
return a KDC reply structure with the appropriate ticket.
|
||||
|
||||
If the account is not present in the realm specified in the request
|
||||
and the "canonicalize" KDC option is set, the KDC will try to lookup
|
||||
the entire name, alice@MS.COM, using a name service. If this lookup
|
||||
is unsuccessful, it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN
|
||||
[KRBCLR]. If the lookup is successful, it MUST return an error
|
||||
KDC_ERR_WRONG_REALM [KRBCLR] and in the error message the crealm
|
||||
field will contain either the true realm of the client or another
|
||||
realm that MAY have better information about the client's true realm.
|
||||
The client SHALL NOT use a cname returned from a referral until that
|
||||
name is validated.
|
||||
|
||||
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
|
||||
new AS request with the same client principal name used to generate
|
||||
the first referral to the realm specified by the realm field of the
|
||||
Kerberos error message from the first request. The client SHOULD
|
||||
repeat these steps until it finds the true realm of the client. To
|
||||
avoid infinite referral loops, an implementation should limit the
|
||||
number of referrals. A suggested limit is 5 referrals before giving
|
||||
up.
|
||||
|
||||
In Microsoft's current implementation through the use of global
|
||||
catalogs any domain in one forest is reachable from any other domain
|
||||
in the same forest or another trusted forest with 3 or less
|
||||
referrals. A forest is a collection of realms with hierarchical
|
||||
trust relationships: there can be multiple trust trees in a forest;
|
||||
each child and parent realm pair and each root realm pair have
|
||||
bidirectional transitional direct rusts between them.
|
||||
|
||||
The true principal name of the client, carried via the KRB_ERROR
|
||||
message, can be validated in a subsequent TGS message exchange where
|
||||
its value is communicated back to the KDC via the authenticator in
|
||||
the PA-TGS-REQ padata [KRBCLR].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 9]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
7. Server Referrals
|
||||
|
||||
The primary difference in server referrals is that the KDC MUST
|
||||
return a referral TGT rather than an error message as is done in the
|
||||
client referrals. There needs to be a place to include in the reply
|
||||
information about what realm contains the server. This is done by
|
||||
returning information about the server name in the pre-authentication
|
||||
data field of the KDC reply [KRBCLR], as specified later in this
|
||||
section.
|
||||
|
||||
If the KDC resolves the server principal name into a principal in the
|
||||
realm specified by the service realm name, it will return a normal
|
||||
ticket.
|
||||
|
||||
If the "canonicalize" flag in the KDC options is not set, the KDC
|
||||
MUST only look up the name as a normal principal name in the
|
||||
specified server realm. If the "canonicalize" flag in the KDC
|
||||
options is set and the KDC doesn't find the principal locally, the
|
||||
KDC MAY return a cross-realm ticket granting ticket to the next hop
|
||||
on the trust path towards a realm that may be able to resolve the
|
||||
principal name. The true principal name of the server SHALL be
|
||||
returned in the padata of the reply if it is different from what is
|
||||
specified the request.
|
||||
|
||||
When a referral TGT is returned, the KDC MUST return the target realm
|
||||
for the referral TGT as an KDC supplied pre-authentication data
|
||||
element in the response. This referral information in
|
||||
pre-authentication data MUST be encrypted using the session key from
|
||||
the reply ticket. The key usage value for the encryption operation
|
||||
used by PA-SERVER-REFERRAL is 26.
|
||||
|
||||
The pre-authentication data returned by the KDC, which contains the
|
||||
referred realm and the true principal name of server, is encoded in
|
||||
DER as follows.
|
||||
|
||||
PA-SERVER-REFERRAL 25
|
||||
|
||||
PA-SERVER-REFERRAL-DATA ::= EncryptedData
|
||||
-- ServerReferralData --
|
||||
|
||||
ServerReferralData ::= SEQUENCE {
|
||||
referred-realm [0] Realm, OPTIONAL
|
||||
-- target realm of the referral TGT
|
||||
true-principal-name [1] PrincipalName OPTIONAL,
|
||||
-- true server principal name
|
||||
...
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 10]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
Clients SHALL NOT accept a reply ticket, whose the server principal
|
||||
name is different from that of the request, if the KDC response does
|
||||
not contain a PA-SERVER-REFERRAL padata entry.
|
||||
|
||||
The referred-realm field is present if and only if the returned
|
||||
ticket is a referral TGT, not a service ticket for the requested
|
||||
server principal.
|
||||
|
||||
When a referral TGT is returned and the true-principal-name field is
|
||||
present, the client MUST use that name in the subsequent requests to
|
||||
the server realm when following the referral.
|
||||
|
||||
Client SHALL NOT accept a true server principal name for a service
|
||||
ticket if the true-principal-name field is not present in the
|
||||
PA-SERVER-REFERRAL data.
|
||||
|
||||
The client will use this referral information to request a chain of
|
||||
cross-realm ticket granting tickets until it reaches the realm of the
|
||||
server, and can then expect to receive a valid service ticket.
|
||||
|
||||
However an implementation should limit the number of referrals that
|
||||
it processes to avoid infinite referral loops. A suggested limit is
|
||||
5 referrals before giving up.
|
||||
|
||||
Here is an example of a client requesting a service ticket for a
|
||||
service in realm NTDEV.MS.COM where the client is in OFFICE.MS.COM.
|
||||
|
||||
+NC = Canonicalize KDCOption set
|
||||
+PA-REFERRAL = returned PA-SERVER-REFERRAL
|
||||
C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to OFFICE.MS.COM
|
||||
S: TGS-REP sname=krbtgt/MS.COM@OFFICE.MS.COM +PA-REFERRAL
|
||||
containing MS.COM as the referred realm with no
|
||||
true-principal-name
|
||||
C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to MS.COM
|
||||
S: TGS-REP sname=krbtgt/NTDEV.MS.COM@MS.COM +PA-REFERRAL
|
||||
containing NTDEV.MS.COM as the referred realm with no
|
||||
true-principal-name
|
||||
C: TGS-REQ sname=http/foo.ntdev.ms.com +NC to NTDEV.MS.COM
|
||||
S: TGS-REP sname=http/foo.ntdev.ms.com@NTDEV.MS.COM
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 11]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
8. Cross Realm Routing
|
||||
|
||||
The current Kerberos protocol requires the client to explicitly
|
||||
request a cross-realm TGT for each pair of realms on a referral
|
||||
chain. As a result, the client need to be aware of the trust
|
||||
hierarchy and of any short-cut trusts (those that aren't parent-
|
||||
child trusts).
|
||||
|
||||
Instead, using the server referral routing mechanism as defined in
|
||||
Section 7, The KDC will determine the best path for the client and
|
||||
return a cross-realm TGT as the referral TGT, and the target realm
|
||||
for this TGT in the PA-SERVER-REFERRAL of the KDC reply.
|
||||
|
||||
If the "canonicalize" KDC option is not set, the KDC SHALL NOT return
|
||||
a referral TGT. Clients SHALL NOT process referral TGTs if the KDC
|
||||
response does not contain the PA-SERVER-REFERRAL padata.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 12]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
9. Compatibility with Earlier Implementations of Name Canonicalization
|
||||
|
||||
The Microsoft Windows 2000 and Windows 2003 releases included an
|
||||
earlier form of name-canonicalization [XPR]. Here are the
|
||||
differences:
|
||||
|
||||
1) The TGS referral data is returned inside of the KDC message as
|
||||
"encrypted pre-authentication data".
|
||||
|
||||
|
||||
|
||||
EncKDCRepPart ::= SEQUENCE {
|
||||
key [0] EncryptionKey,
|
||||
last-req [1] LastReq,
|
||||
nonce [2] UInt32,
|
||||
key-expiration [3] KerberosTime OPTIONAL,
|
||||
flags [4] TicketFlags,
|
||||
authtime [5] KerberosTime,
|
||||
starttime [6] KerberosTime OPTIONAL,
|
||||
endtime [7] KerberosTime,
|
||||
renew-till [8] KerberosTime OPTIONAL,
|
||||
srealm [9] Realm,
|
||||
sname [10] PrincipalName,
|
||||
caddr [11] HostAddresses OPTIONAL,
|
||||
encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL
|
||||
}
|
||||
|
||||
2) The preauth data type definition in the encrypted preauth data is
|
||||
as follows:
|
||||
|
||||
|
||||
|
||||
PA-SVR-REFERRAL-INFO 20
|
||||
|
||||
PA-SVR-REFERRAL-DATA ::= SEQUENCE {
|
||||
referred-name [1] PrincipalName OPTIONAL,
|
||||
referred-realm [0] Realm
|
||||
}}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 13]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
10. Security Considerations
|
||||
|
||||
For the AS exchange case, it is important that the logon mechanism
|
||||
not trust a name that has not been used to authenticate the user.
|
||||
For example, the name that the user enters as part of a logon
|
||||
exchange may not be the name that the user authenticates as, given
|
||||
that the KDC_ERR_WRONG_REALM error may have been returned. The
|
||||
relevant Kerberos naming information for logon (if any), is the
|
||||
client name and client realm in the service ticket targeted at the
|
||||
workstation that was obtained using the user's initial TGT.
|
||||
|
||||
How the client name and client realm is mapped into a local account
|
||||
for logon is a local matter, but the client logon mechanism MUST use
|
||||
additional information such as the client realm and/or authorization
|
||||
attributes from the service ticket presented to the workstation by
|
||||
the user, when mapping the logon credentials to a local account on
|
||||
the workstation.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 14]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
11. Acknowledgments
|
||||
|
||||
The authors wish to thank Ken Raeburn for his comments and
|
||||
suggestions.
|
||||
|
||||
Sam Hartman, Ken Raeburn, and authors came up with the idea of using
|
||||
the ticket key to encrypt the referral data, which prevents cut and
|
||||
paste attack using the referral data and referral TGTs.
|
||||
|
||||
John Brezak, Mike Swift, and Jonathan Trostle wrote the initial
|
||||
version of this document.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 15]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
12. References
|
||||
|
||||
12.1 Normative References
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[KRBCLR] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
|
||||
Kerberos Network Authentication Service (V5)",
|
||||
draft-ietf-krb-wg-kerberos-clarifications. Work in
|
||||
progress.
|
||||
|
||||
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet
|
||||
Text Messages", RFC 822, August 1982.
|
||||
|
||||
12.2 Informative References
|
||||
|
||||
[XPR] Trostle, J., Kosinovsky, I., and Swift, M.,
|
||||
"Implementation of Crossrealm Referral Handling in the
|
||||
MIT Kerberos Client", In Network and Distributed System
|
||||
Security Symposium, February 2001.
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Larry Zhu
|
||||
Microsoft Corporation
|
||||
One Microsoft Way
|
||||
Redmond, WA 98052
|
||||
US
|
||||
|
||||
EMail: lzhu@microsoft.com
|
||||
|
||||
|
||||
Karthik Jaganathan
|
||||
Microsoft Corporation
|
||||
One Microsoft Way
|
||||
Redmond, WA 98052
|
||||
US
|
||||
|
||||
EMail: karthikj@microsoft.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 16]
|
||||
|
||||
Internet-Draft KDC Referrals October 2004
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Zhu & Jaganathan Expires April 25, 2005 [Page 17]
|
||||
|
||||
|
1178
doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
Normal file
1178
doc/standardisation/draft-ietf-krb-wg-preauth-framework-02.txt
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,249 @@
|
||||
|
||||
|
||||
GSSAPI Java CSharp C. Morris
|
||||
INTERNET-DRAFT Novell, Inc.
|
||||
draft-morris-java-gssapi-update-for-csharp-00.txt comorris@novell.com
|
||||
Expires 10 March 2004 July 2004
|
||||
|
||||
|
||||
Generic Security Service API Version 2 : Java & C# Bindings
|
||||
|
||||
Status of this Memo
|
||||
|
||||
Comments should be submitted to comorris@novell.com.
|
||||
|
||||
By submitting this Internet-Draft, I certify that any applicable
|
||||
patent or other IPR claims of which I am aware have been disclosed, or
|
||||
will be disclosed, and any of which I become aware will be disclosed,
|
||||
in accordance with RFC 3668.
|
||||
|
||||
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 a "work in progress."
|
||||
|
||||
The list of current Internet-Drafts can be accessed at
|
||||
http://www.ietf.org/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
Abstract
|
||||
|
||||
The Generic Security Services Application Program Interface (GSS-API)
|
||||
offers application programmers uniform access to security services
|
||||
atop a variety of underlying cryptographic mechanisms. This document
|
||||
proposes an update to RFC 2853, Generic Security Service API Version
|
||||
2 : Java Bindings, to include C# bindings.
|
||||
|
||||
4.17. C# Modifications
|
||||
|
||||
This section describes the language dependent modifications necessary
|
||||
to implement the interface in C#.
|
||||
|
||||
4.17.1 C# Assembly Name
|
||||
|
||||
The C# namespace is org.ietf.gss. See section 4.17.5 for an example.
|
||||
|
||||
4.17.2 C# Class Definitions
|
||||
|
||||
All class definitions & methods remain the same as specified in the
|
||||
Java bindings.
|
||||
|
||||
4.17.3 C# Data Types
|
||||
|
||||
All data types remain the same.
|
||||
|
||||
4.17.4 C# Exception Handling
|
||||
|
||||
All exception codes remain the same as specified in the Java bindings.
|
||||
However, C# does not have a 'throws' statement. Therefore, method prototypes do
|
||||
not include the exception type. For example,
|
||||
|
||||
Java method prototype :
|
||||
|
||||
public abstract GSSName createName(String nameStr, Oid nameType)
|
||||
throws GSSException;
|
||||
|
||||
Equivalent C# method prototype :
|
||||
|
||||
public abstract GSSName createName(String nameStr, Oid nameType);
|
||||
|
||||
C# does implement the throw and catch keywords, for example:
|
||||
|
||||
public class GSSName createName(String nameStr, Oid nameType)
|
||||
{
|
||||
int majorCode = 0;
|
||||
...
|
||||
|
||||
majorCode = validateParms(nameStr, nameType);
|
||||
|
||||
if (majorCode)
|
||||
throw new GSSException(majorCode);
|
||||
|
||||
...
|
||||
}
|
||||
|
||||
|
||||
4.17.5 C# Example Code
|
||||
|
||||
Client example :
|
||||
|
||||
using ietf.org.gss;
|
||||
|
||||
class GssapiClient
|
||||
{
|
||||
private static TcpClient client;
|
||||
private static NetworkStream stream;
|
||||
|
||||
static void Main(string[] args)
|
||||
{
|
||||
Connect("127.0.0.1", "message from client");
|
||||
|
||||
try
|
||||
{
|
||||
GSSManager manager = GSSManager.getInstance();
|
||||
|
||||
Oid krb5Mechanism = new Oid("1.2.840.113554.1.2.2");
|
||||
Oid krb5PrincipalNameType = new Oid("1.2.840.113554.1.2.2.1");
|
||||
|
||||
// Optionally Identify who the client wishes to be
|
||||
// GSSName name = manager.createName("test@gsserver", GSSName.NT_USER_NAME);
|
||||
|
||||
// Obtain default credential
|
||||
GSSCredential userCreds = manager.createCredential(GSSCredential.INITIATE_ONLY);
|
||||
GSSName name = userCreds.getName(krb5PrincipalNameType);
|
||||
|
||||
Console.WriteLine("Just acquired credentials for " + name.toString());
|
||||
|
||||
int acceptLife = userCreds.getRemainingAcceptLifetime(new Oid("2.3.4"));
|
||||
int initLife = userCreds.getRemainingInitLifetime(new Oid("1..3."));
|
||||
int remLife = userCreds.getRemainingLifetime();
|
||||
int usage = userCreds.getUsage();
|
||||
|
||||
GSSName namea = userCreds.getName();
|
||||
Oid[] oa = userCreds.getMechs();
|
||||
|
||||
// Instantiate and initialize a security context that will be
|
||||
// established with the server
|
||||
GSSContext context = manager.createContext(name,
|
||||
krb5Mechanism,
|
||||
userCreds,
|
||||
GSSContext.DEFAULT_LIFETIME);
|
||||
|
||||
userCreds.dispose();
|
||||
|
||||
// Optionally Set Context Options, must be done before iniSecContext call
|
||||
context.requestMutualAuth(true);
|
||||
context.requestConf(true);
|
||||
context.requestInteg(true);
|
||||
context.requestSequenceDet(true);
|
||||
context.requestCredDeleg(true);
|
||||
|
||||
MemoryStream ins = new MemoryStream();
|
||||
MemoryStream outs = new MemoryStream();
|
||||
|
||||
// loop until context is setup and no more tokens to receive
|
||||
while (!context.isEstablished())
|
||||
{
|
||||
outs = new MemoryStream();
|
||||
context.initSecContext(ins, outs);
|
||||
|
||||
// send token if present
|
||||
if (outs.Length > 0)
|
||||
{
|
||||
Console.WriteLine("Sending token...");
|
||||
sendToken(outs);
|
||||
}
|
||||
|
||||
// check if we should expect more tokens
|
||||
if (context.isEstablished())
|
||||
break;
|
||||
|
||||
// another token expected from peer
|
||||
Console.WriteLine("Still expecting another token from server...");
|
||||
ins = recvToken();
|
||||
}
|
||||
|
||||
//
|
||||
// display context information
|
||||
//
|
||||
|
||||
// Did the server authenticate back to client?
|
||||
Console.WriteLine("\n{0} Mutual Authentication",
|
||||
context.getMutualAuthState() ? "Using" : "Not using");
|
||||
Console.WriteLine("Credentials were delegated = "
|
||||
+ context.getCredDelegState());
|
||||
Console.WriteLine("Remaining lifetime in seconds = "
|
||||
+ context.getLifetime());
|
||||
Console.WriteLine("Context mechanism = " + context.getMech());
|
||||
Console.WriteLine("Initiator = " + context.getSrcName().toString());
|
||||
Console.WriteLine("Acceptor = " + context.getTargName().toString());
|
||||
Console.WriteLine("Confidentiality (i.e., privacy) is {0}available",
|
||||
context.getConfState() ? "" : "not ");
|
||||
Console.WriteLine("Integrity is {0}available",
|
||||
context.getIntegState() ? "" : "not ");
|
||||
Console.WriteLine("Is initiator = " + context.isInitiator());
|
||||
Console.WriteLine("Is transferable = " + context.isTransferable());
|
||||
Console.WriteLine("Is protReady = " + context.isProtReady());
|
||||
Console.WriteLine("ReplayDetState = " +
|
||||
context.getReplayDetState());
|
||||
Console.WriteLine("SequenceDetState = " +
|
||||
context.getSequenceDetState());
|
||||
|
||||
// perform wrap on an application supplied message
|
||||
// using QOP = 0, and requesting privacy service
|
||||
|
||||
MessageProp msgProp = new MessageProp(0, true);
|
||||
byte [] message = System.Text.Encoding.ASCII.GetBytes("Hello GSS-API!");
|
||||
byte [] token = System.Text.Encoding.ASCII.GetBytes("tok");
|
||||
|
||||
// Byte aray method is equivalent to stream method
|
||||
//byte []token = context.wrap(message, 0, appMsg.length, msgProp);
|
||||
//sendToken(token);
|
||||
|
||||
ins = new MemoryStream();
|
||||
outs = new MemoryStream();
|
||||
ins.Write(token, 0, token.Length);
|
||||
context.getMIC(ins, outs, msgProp);
|
||||
sendToken(outs);
|
||||
|
||||
outs = new MemoryStream();
|
||||
outs.Write(message, 0, message.Length);
|
||||
sendToken(outs);
|
||||
|
||||
ins = new MemoryStream();
|
||||
outs = new MemoryStream();
|
||||
ins.Write(message, 0, message.Length);
|
||||
context.wrap(ins, outs, msgProp);
|
||||
sendToken(outs);
|
||||
|
||||
// Optionally export context to another thead
|
||||
GSSContext ctx = manager.createContext(context.export());
|
||||
Console.WriteLine("New context isTransferable = " + ctx.isTransferable());
|
||||
Console.WriteLine("New context isInitiator = " +ctx.isInitiator());
|
||||
Console.WriteLine("New context protReady = " +ctx.isProtReady());
|
||||
Console.WriteLine("New context srcName = " +ctx.getSrcName().toString());
|
||||
Console.WriteLine("New context targName = " +ctx.getTargName().toString());
|
||||
|
||||
// release the local-end of the context
|
||||
ctx.dispose();
|
||||
|
||||
stream.Close();
|
||||
Console.WriteLine("Leaving...");
|
||||
}
|
||||
catch (GSSException e)
|
||||
{
|
||||
Console.WriteLine(e.getMessage());
|
||||
Console.WriteLine(e.StackTrace);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
Expires 10 March 2004
|
||||
|
||||
|
@@ -0,0 +1,557 @@
|
||||
NETWORK WORKING GROUP N. Williams
|
||||
Internet-Draft Sun
|
||||
Expires: December 30, 2004 July 2004
|
||||
|
||||
|
||||
|
||||
GSS-API Domain-Based Service Names and Name Type
|
||||
draft-williams-gssapi-domain-based-names-00.txt
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
|
||||
By submitting this Internet-Draft, I certify that any applicable
|
||||
patent or other IPR claims of which I am aware have been disclosed,
|
||||
and any of which I become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
This Internet-Draft will expire on December 30, 2004.
|
||||
|
||||
|
||||
Copyright Notice
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
|
||||
This document describes domainname-based service principal names and
|
||||
the corresponding name type for the GSS-API.
|
||||
|
||||
|
||||
Domain-based service names are similar to host-based service names,
|
||||
but using a domain name (not necessarily and Internat domain name)
|
||||
instead of or in addition to a hostname. The primary purpose of
|
||||
domain-based service names is to provide a way to name clustered
|
||||
services after the domain which they service, thereby allowing their
|
||||
clients to authorize the service's servers based on authentication of
|
||||
their names.
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 1]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
|
||||
1. Conventions used in this document . . . . . . . . . . . . . . . 3
|
||||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. Name Type OID and Symbolic Name . . . . . . . . . . . . . . . . 5
|
||||
4. Query and Display Syntaxes . . . . . . . . . . . . . . . . . . . 6
|
||||
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
|
||||
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
|
||||
7. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . 9
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 2]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
1. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 3]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
2. Introduction
|
||||
|
||||
|
||||
The use of hostbased principal names for domain-wide services
|
||||
presents the problem of how to distinguish between an instance of a
|
||||
hostbased service that is authorized to respond for a domain and one
|
||||
that isn't.
|
||||
|
||||
|
||||
Consider LDAP. LDAP with SASL and the Kerberos V GSS-API mechanism
|
||||
uses a hostbased principal with a service name of "ldap", a
|
||||
reasonable approach, provided there is only one logical LDAP
|
||||
directory in a Kerberos realm's domain, and that all ldap servers in
|
||||
that realm serve that one LDAP directory. If there were other LDAP
|
||||
directories, then clients could not tell which service is authorized
|
||||
to serve which directory, not without assuming a secure method for
|
||||
finding LDAP servers (e.g., DNSSEC). This is a significant, and
|
||||
oft-unstated restriction on users of LDAP.
|
||||
|
||||
|
||||
Domain based names can eliminate this problem by allowing LDAP
|
||||
service names to indicate which LDAP directory they are authorized to
|
||||
serve.
|
||||
|
||||
|
||||
A domain-based name consists of three required elements:
|
||||
o a service name
|
||||
o a domain name
|
||||
o a hostname
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 4]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
3. Name Type OID and Symbolic Name
|
||||
|
||||
|
||||
The new name type has an OID of
|
||||
[NOTE: OID assignment to be made with IANA.]
|
||||
|
||||
|
||||
{iso(1) org(3) dod(6) internet(1) security(5) nametypes(6)
|
||||
gss-domain-based(5)}
|
||||
|
||||
|
||||
The recommended symbolic name for this GSS-API name type is
|
||||
"GSS_C_NT_DOMAINBASED_SERVICE".
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 5]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
4. Query and Display Syntaxes
|
||||
|
||||
|
||||
There is a single syntax that applies to both query and display forms
|
||||
of domain-based names. (We ignore string profile matters here as the
|
||||
GSS-API's, and its mechanisms' use of character strings are out of
|
||||
scope for this document.)
|
||||
|
||||
|
||||
The syntax is:
|
||||
domain-based-name :=
|
||||
| <service> '@' <domain> '@' <hostname>
|
||||
| <service> '@@' <hostname>
|
||||
|
||||
|
||||
The domain name element is only optional in the query syntax of
|
||||
domain-based names.
|
||||
|
||||
|
||||
A missing domain name is always to be added by the GSS-API mechanisms
|
||||
during name canonicalization, using whatever default values are
|
||||
appropriate for the mechanisms.
|
||||
|
||||
|
||||
Therefore the display form of domain-based MNs (see [RFC2743]) MUST
|
||||
include all three elements of domain-based names.
|
||||
|
||||
|
||||
Note that for Internet domain names the trailing '.' is not and MUST
|
||||
NOT be included in the domain name (or hostname) parts of the display
|
||||
form GSS-API domain-based MNs.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 6]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
5. Examples
|
||||
|
||||
|
||||
o ldap@@ds1.example.tld
|
||||
o ldap@example.tld@ds1.example.tld
|
||||
|
||||
|
||||
o kadmin@@kdc1.example.tld
|
||||
o kadmin@example.tld@kdc1.example.tld
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 7]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
6. Security Considerations
|
||||
|
||||
|
||||
Use of GSS-API domain-based names may not be negotiable by some
|
||||
GSS-API mechanisms, and some acceptors may not support GSS-API
|
||||
domain-based names. In such cases initiators are left to fallback on
|
||||
the use of hostbased names, in which case the initiators MUST also
|
||||
verify that the acceptor's hostbased name is authorized to provide
|
||||
the given service for the domain that the initiator had wanted.
|
||||
|
||||
|
||||
The above security consideration also applies to all GSS-API
|
||||
initiators who lack support for domain-based service names.
|
||||
|
||||
|
||||
7 Normative
|
||||
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
[RFC2743] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
|
||||
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
|
||||
C-bindings", RFC 2744, January 2000.
|
||||
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
|
||||
Nicolas Williams
|
||||
Sun Microsystems
|
||||
5300 Riata Trace Ct
|
||||
Austin, TX 78727
|
||||
US
|
||||
|
||||
|
||||
EMail: Nicolas.Williams@sun.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 8]
|
||||
Internet-Draft GSS Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 9]
|
617
doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
Normal file
617
doc/standardisation/draft-williams-gssapi-extensions-iana-00.txt
Normal file
@@ -0,0 +1,617 @@
|
||||
|
||||
|
||||
NETWORK WORKING GROUP N. Williams
|
||||
Internet-Draft Sun
|
||||
Expires: December 30, 2004 July 2004
|
||||
|
||||
|
||||
Namespace Considerations and Registries for GSS-API Extensions
|
||||
draft-williams-gssapi-extensions-iana-00.txt
|
||||
|
||||
Status of this Memo
|
||||
|
||||
By submitting this Internet-Draft, I certify that any applicable
|
||||
patent or other IPR claims of which I am aware have been disclosed,
|
||||
and any of which I become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
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.
|
||||
|
||||
This Internet-Draft will expire on December 30, 2004.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes the ways in which the GSS-API may be extended
|
||||
and directs the creation of IANA registries for GSS-API namespaces
|
||||
that may be affected by any extensions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 1]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Conventions used in this document . . . . . . . . . . . . . . 3
|
||||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . 5
|
||||
4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 6
|
||||
5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 7
|
||||
6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . 8
|
||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
|
||||
9. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
|
||||
Intellectual Property and Copyright Statements . . . . . . . . 11
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 2]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
1. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 3]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
2. Introduction
|
||||
|
||||
There is a need for generic and mechanism-specific extensions to the
|
||||
Generic Security Services Application Programming Interface
|
||||
(GSS-API). As such extensions are designed and standardized, both at
|
||||
the IETF and elsewhere, there is a non-trivial risk of namespace
|
||||
pollution and conflicts. To avoid this we set out guidelines for
|
||||
extending the GSS-API and create IANA registries of GSS-API
|
||||
namespaces.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 4]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
3. Extensions to the GSS-API
|
||||
|
||||
Extensions to the GSS-API can be categorized as follows:
|
||||
o Generic
|
||||
o Implementation-specific
|
||||
o Mechanism-specific
|
||||
o Language binding-specific
|
||||
o Any combination of two or all three of the last three
|
||||
|
||||
Extensions to the GSS-API may be purely semantic, without effect on
|
||||
the GSS-API's namespaces. Or they may introduce new functions,
|
||||
constants, types, etc...; these clearly affect the GSS-API
|
||||
namespaces.
|
||||
|
||||
Extensions that affect the GSS-API namespaces should be registered
|
||||
with the IANA< along with their specific effects on the GSS-API
|
||||
namespaces.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 5]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
4. Generic GSS-API Namespaces
|
||||
|
||||
All the function, constant and type names, as well as all the
|
||||
constant values specified in the base GSS-API specification for the
|
||||
basic generic GSS-API namespace.
|
||||
|
||||
The generic GSS-API namespaces are:
|
||||
o Type names
|
||||
o Function names
|
||||
o Constant names for each type
|
||||
o Constant values for each type
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 6]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
5. Language Binding-Specific GSS-API Namespaces
|
||||
|
||||
<Add text; discuss header, module, library, class namespaces and
|
||||
whatever else comes up that is language-specific and appropriate for
|
||||
registration with the IANA.>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 7]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
6. Extension-Specific GSS-API Namespaces
|
||||
|
||||
Extensions to the GSS-API may create additional namespaces. IANA
|
||||
registries SHOULD be created for any such new namespaces.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 8]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
7. IANA Considerations
|
||||
|
||||
The following registries should be established upon publication of
|
||||
this document as an RFC:
|
||||
o GSS-API Type Name Registry
|
||||
o GSS-API Function Name Registry
|
||||
o GSS-API Constant Name Registry
|
||||
o GSS-API Constant Value Registry
|
||||
o GSS-API Class/Header/Library/Module Name Registry
|
||||
|
||||
Entries in these registries should consist of:
|
||||
o Namespace name
|
||||
o Symbol name or prefix, OR value or value range.
|
||||
o [optional] Reference to normative reference for the registration.
|
||||
o [optional] Programming language
|
||||
o [optional] Entry sub-type (e.g., "header name")
|
||||
o [optional] Mechanism OID(s) and/or OID prefix(es) associated with
|
||||
the entry
|
||||
o [optional] Magic
|
||||
o [optional] Expert Review (body or people who reviewed the
|
||||
registration)
|
||||
o [optional] Description (in English)
|
||||
|
||||
<Add text on guidelines for IANA consideration of registration
|
||||
applications, particularly with respect to entries w/o normative
|
||||
references, "magic" entries (e.g., special values of 'time' types
|
||||
which indicate something other than absolute or relative time, such
|
||||
as GSS_C_INDEFINITE), expert review requirements for registrations w/
|
||||
o normative references, etc....>
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 9]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
8. Security Considerations
|
||||
|
||||
This document has no security considerations.
|
||||
|
||||
9 Normative
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC2743] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
|
||||
C-bindings", RFC 2744, January 2000.
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Nicolas Williams
|
||||
Sun Microsystems
|
||||
5300 Riata Trace Ct
|
||||
Austin, TX 78727
|
||||
US
|
||||
|
||||
EMail: Nicolas.Williams@sun.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 10]
|
||||
|
||||
Internet-Draft GSS-API Namespace Considerations July 2004
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 11]
|
||||
|
||||
|
498
doc/standardisation/draft-williams-gssapi-prf-00.txt
Normal file
498
doc/standardisation/draft-williams-gssapi-prf-00.txt
Normal file
@@ -0,0 +1,498 @@
|
||||
NETWORK WORKING GROUP N. Williams
|
||||
Internet-Draft Sun
|
||||
Expires: December 30, 2004 S. Hartman
|
||||
MIT
|
||||
July 2004
|
||||
|
||||
|
||||
|
||||
A PRF API extension for the GSS-API
|
||||
draft-williams-gssapi-prf-00.txt
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
|
||||
By submitting this Internet-Draft, I certify that any applicable
|
||||
patent or other IPR claims of which I am aware have been disclosed,
|
||||
and any of which I become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
This Internet-Draft will expire on December 30, 2004.
|
||||
|
||||
|
||||
Copyright Notice
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
|
||||
This document defines a Pseudo-Random Function (PRF) extension to the
|
||||
GSS-API for keying application protocols given an established GSS-API
|
||||
security context.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 1]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
|
||||
1. Conventions used in this document . . . . . . . . . . . . . . 3
|
||||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 5
|
||||
3.1 C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
|
||||
5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
Intellectual Property and Copyright Statements . . . . . . . . 8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 2]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
1. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 3]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
2. Introduction
|
||||
|
||||
|
||||
A need has arisen for users of the GSS-API to key applications'
|
||||
cryptographic protocols using established GSS-API security contexts.
|
||||
Such applications can use the GSS-API for authentication, but not for
|
||||
transport security (for whatever reasons), and since the GSS-API does
|
||||
not provide a method for obtaining keying material from established
|
||||
security contexts such applications cannot make effective use of the
|
||||
GSS-API.
|
||||
|
||||
|
||||
To address this need we define a PRF extension to the GSS-API.
|
||||
|
||||
|
||||
At this point EAP may be the primary consumer of this extension.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 4]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
3. GSS_Pseudo_random()
|
||||
|
||||
|
||||
Inputs:
|
||||
|
||||
|
||||
o context CONTEXT handle,
|
||||
o prf_in OCTET STRING
|
||||
|
||||
|
||||
Outputs:
|
||||
|
||||
|
||||
o major_status INTEGER,
|
||||
o minor_status INTEGER,
|
||||
o prf_out OCTET STRING
|
||||
|
||||
|
||||
Return major_status codes:
|
||||
o GSS_S_COMPLETE indicates no error.
|
||||
o GSS_S_NO_CONTEXT indicates that a null context has been provided
|
||||
as input.
|
||||
o GSS_S_CONTEXT_EXPIRED indicates that an expired context has been
|
||||
provided as input.
|
||||
o GSS_S_FAILURE indicates failure or lack of support; the minor
|
||||
status code may provide additional information.
|
||||
|
||||
|
||||
This function applies the context's mechanism's keyed PRF function to
|
||||
the input data (prf_in), keyed with key material associated with the
|
||||
given security context and outputs the result (prf_out).
|
||||
|
||||
|
||||
3.1 C-Bindings
|
||||
|
||||
|
||||
OM_uint32 gss_pseudo_random(
|
||||
OM_uint32 *minor_status,
|
||||
gss_ctx_id_t context,
|
||||
const gss_buffer_t prf_in,
|
||||
gss_buffer_t prf_out
|
||||
);
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 5]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
|
||||
GSS mechanisms' PRF functions should use a key derived from contexts'
|
||||
session keys and should preserve the forward security properties of
|
||||
the mechanisms' key exchanges.
|
||||
|
||||
|
||||
Care should be taken in properly designing a mechanism's PRF
|
||||
function. Cryptographic hash functions which do not provide strong
|
||||
collision resistance should not be used, except through HMAC.
|
||||
|
||||
|
||||
GSS mechanisms' PRF functions may output fewer octets than the
|
||||
application may need, therefore GSS-API applications that use
|
||||
GSS_Pseudo_random() may require a "PRF+" construction based on
|
||||
GSS_Pseudo_random().
|
||||
|
||||
|
||||
[Question: Should GSS_Pseudo_random() have an input roughly
|
||||
corresponding to the "key usage" used for key derivation in Kerberos
|
||||
V?]
|
||||
|
||||
|
||||
5 Normative
|
||||
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
[RFC2743] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
|
||||
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
|
||||
C-bindings", RFC 2744, January 2000.
|
||||
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
|
||||
Nicolas Williams
|
||||
Sun Microsystems
|
||||
5300 Riata Trace Ct
|
||||
Austin, TX 78727
|
||||
US
|
||||
|
||||
|
||||
EMail: Nicolas.Williams@sun.com
|
||||
|
||||
|
||||
|
||||
Sam Hartman
|
||||
Massachussets Institute of Technology
|
||||
...
|
||||
..., MA ...
|
||||
US
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 6]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
EMail: hartmans@mit.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 7]
|
||||
Internet-Draft A PRF Extension for the GSS-API July 2004
|
||||
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 8]
|
@@ -0,0 +1,466 @@
|
||||
|
||||
INTERNET-DRAFT Nicolas Williams
|
||||
Sun Microsystems
|
||||
September 2003
|
||||
|
||||
|
||||
|
||||
GSS-APIv2 Extension for Storing Delegated Credentials
|
||||
<draft-williams-gssapi-store-deleg-creds-01.txt>
|
||||
|
||||
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
This document is an Internet-Draft and is in full conformance with
|
||||
all provisions of Section 10 of RFC2026 [RFC2026].
|
||||
|
||||
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.
|
||||
|
||||
This draft expires on January 30th, 2004. Please send comments to
|
||||
the authors.
|
||||
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2003). All Rights Reserved.
|
||||
|
||||
Abstract
|
||||
|
||||
This document defines a new function for the GSS-API which allows
|
||||
applications to store delegated (and other) credentials in the
|
||||
implicit GSS-API credential store. This is needed for GSS-API
|
||||
applications to use delegated credentials as they would use other
|
||||
credentials.
|
||||
|
||||
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 [RFC2119].
|
||||
|
||||
N. Williams [Page 1]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1 Introduction
|
||||
2 GSS_Store_cred()
|
||||
2.1 C-Bindings for GSS_Store_cred()
|
||||
3 Examples
|
||||
4 Security Considerations
|
||||
5 References
|
||||
5.1 Normative References
|
||||
6 Author's Address
|
||||
|
||||
1 Introduction
|
||||
|
||||
The GSS-API [RFC2743] clearly assumes that credentials exist in an
|
||||
implicit store whence they can be acquired using GSS_Acquire_cred()
|
||||
and GSS_Add_cred() or through use of the default credential.
|
||||
Multiple credential stores may exist on a given host, but only one
|
||||
store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any
|
||||
given time.
|
||||
|
||||
[NOTE: This assumption can be seen in sections 1.1.1.2 and 1.1.1.3
|
||||
of RFC2743 as well as in section 3.5 of RFC2744.
|
||||
|
||||
Note to the RFC editor: please remove this note before
|
||||
publication.]
|
||||
|
||||
Applications may be able to change the credential store from which
|
||||
credentials can be acquired, either by changing user contexts (where
|
||||
the applications have the privilege to do so) or by other means
|
||||
(where a user may have multiple credential stores).
|
||||
|
||||
Some GSS-API acceptor applications always change user contexts, after
|
||||
accepting a GSS-API security context and making appropriate
|
||||
authorization checks, to the user context corresponding to the
|
||||
initiator principal name or to a context requested by the initiator.
|
||||
The means by which credential stores are managed are generally beyond
|
||||
the scope of the GSS-API.
|
||||
|
||||
In the case of delegated credential handles however, such credentials
|
||||
do not exist in the acceptor's credential store or in the credential
|
||||
stores of the user contexts to which the acceptor application might
|
||||
change - which is precisely the raison d'etre of credential
|
||||
delegation. But the GSS-API provides no mechanism by which delegated
|
||||
credential handles can be made available for acquisition through
|
||||
GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide
|
||||
any credential import/export interfaces like the GSS-API context
|
||||
import/export interfaces.
|
||||
|
||||
Thus acceptors are limited to making only direct use of delegated
|
||||
credential handles and only with GSS_Init_sec_context(),
|
||||
GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is
|
||||
particularly onerous on Unix systems where a call to exec() to
|
||||
|
||||
N. Williams [Page 2]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
replace the process image obliterates the delegated credentials
|
||||
handle.
|
||||
|
||||
[NOTE: Delegated credentials are practically unusable on Unix
|
||||
implementations of Secure Shell (SSHv2) servers, except where
|
||||
there are extended interfaces for dealing with delegated
|
||||
credentials, which to date have always been
|
||||
mechanism-specific interfaces.
|
||||
|
||||
Note to the RFC editor: please remove this note before
|
||||
publication.]
|
||||
|
||||
In order to make delegated credentials generally as useful as
|
||||
credentials that can be acquired with GSS_Acquire_cred() and
|
||||
GSS_Add_cred() a primitive is needed which allows storing of
|
||||
credentials in the implicit credential store. This primitive we call
|
||||
"GSS_Store_cred()."
|
||||
|
||||
[NOTE: Simon Wilkinson's patches to OpenSSH for GSS-API sport a
|
||||
simple internal interface for storing delegated credentials
|
||||
in users' credential store - this internal interface wraps
|
||||
around two mechanism specific internal interfaces for storing
|
||||
GSI and Kerberos V credentials.
|
||||
|
||||
Simon's code shows that:
|
||||
|
||||
a) a generic method is needed for making delegated
|
||||
credentials available for indirect use through acquisition
|
||||
(as opposed to just using the actual delegated cred
|
||||
handle)
|
||||
|
||||
b) it is possible to design and implement such a generic
|
||||
method for storing delegated credentials.
|
||||
|
||||
No new concepts are added to the GSS-API by this document,
|
||||
but the implicit existence of a credential store in the
|
||||
background is made explicit, and a deficiency of the GSS-API
|
||||
is corrected.
|
||||
|
||||
Compare this to the GGF proposal which includes a credential
|
||||
import/export facility (like the existing context import/
|
||||
export facility), but with an option to export as
|
||||
"environment variables," meaning something like "store these
|
||||
input creds in some new credential store and then tell me the
|
||||
name of that credential store through some output environment
|
||||
variable"[*]. Thus, the GGF export-cred-to-environment-
|
||||
variable proposal adds knowledge of environment variables to
|
||||
the GSS-API, which this proposal does not. Note that a
|
||||
credential import/export facility along the lines of the
|
||||
existing context import/export facility may be useful and
|
||||
complements the GSS_Store_cred() interface; in fact, with
|
||||
GSS_Store_cred() it should be possible to remove the
|
||||
'option_req' input parameter and export-to-env-var features
|
||||
|
||||
N. Williams [Page 3]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
of the GGF's GSS_Export_cred() credential export proposal.
|
||||
|
||||
[*] For the exact semantics see section 1.2, paragraph 6 of
|
||||
draft-engert-ggf-gss-extensions-00.txt
|
||||
|
||||
One side effect of GSS_Store_cred(), however, is that it
|
||||
allows applications that can switch their current credential
|
||||
store to move credentials from one store to the other; this
|
||||
is a direct result of making it possible to store a
|
||||
credential given a GSS-API credential handle. Perhaps there
|
||||
should be some text allowing, or recommending, that
|
||||
implementations of GSS_Store_cred() allow only the storage of
|
||||
credentials acquired through credential delegation.
|
||||
|
||||
Note to the RFC editor: please remove this note before
|
||||
publication.]
|
||||
|
||||
2 GSS_Store_cred()
|
||||
|
||||
Inputs:
|
||||
|
||||
o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST
|
||||
-- NOT be GSS_C_NO_CREDENTIAL
|
||||
|
||||
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
|
||||
-- 2=ACCEPT-ONLY
|
||||
|
||||
o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID
|
||||
-- then store all the elements of the input_cred_handle, otherwise
|
||||
-- store only the element of the corresponding mechanism
|
||||
|
||||
o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the
|
||||
-- same principal in the credential store
|
||||
|
||||
o default_cred BOOLEAN -- if TRUE make the stored credential
|
||||
-- available as the default credential (for acquisition with
|
||||
-- GSS_C_NO_NAME as the desired name or for use as
|
||||
-- GSS_C_NO_CREDENTIAL)
|
||||
|
||||
Outputs:
|
||||
|
||||
o major_status INTEGER,
|
||||
|
||||
o minor_status INTEGER,
|
||||
|
||||
o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of
|
||||
-- mechanism OIDs for which credential elements were successfully
|
||||
-- stored
|
||||
|
||||
o cred_usage_stored INTEGER -- like cred_usage, but indicates what
|
||||
-- kind of credential was stored (useful when the cred_usage input
|
||||
-- parameter is set to INITIATE-AND-ACCEPT)
|
||||
|
||||
|
||||
N. Williams [Page 4]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
Return major_status codes:
|
||||
|
||||
o GSS_S_COMPLETE indicates that the credentials were successfully
|
||||
stored.
|
||||
|
||||
o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials
|
||||
had expired or expired before they could be stored.
|
||||
|
||||
o GSS_S_NO_CRED indicates that no input credentials were given.
|
||||
|
||||
o GSS_S_UNAVAILABLE indicates that the credential store is not
|
||||
available.
|
||||
|
||||
o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input
|
||||
credential could not be stored because a credential for the same
|
||||
principal exists in the current credential store and the
|
||||
overwrite_cred input argument was FALSE.
|
||||
|
||||
o GSS_S_FAILURE indicates that the credential could not be stored
|
||||
for some other reason. The minor status code may provide more
|
||||
information if a non-GSS_C_NULL_OID desired_mech_element was given.
|
||||
|
||||
GSS_Store_cred() is used to store, in the current credential store, a
|
||||
given credential that has either been acquired from a different
|
||||
credential store or been accepted as a delegated credential.
|
||||
|
||||
Specific mechanism elements of a credential can be stored one at a
|
||||
time by specifying a non-GSS_C_NULL_OID mechanism OID as the
|
||||
desired_mech_element input argument, in which case the minor status
|
||||
output SHOULD have a mechanism-specific value when the major status
|
||||
is not GSS_S_COMPLETE.
|
||||
|
||||
The initiator, acceptor or both usages of the input credential may be
|
||||
stored as per the cred_usage input argument.
|
||||
|
||||
The credential elements that were actually stored, when the major
|
||||
status is GSS_S_COMPLETE, are indicated through the cred_usage_stored
|
||||
and mech_elements_stored function outputs.
|
||||
|
||||
If credentials already exist in the current store for the principal
|
||||
of the input_cred_handle, then those credentials are not replaced
|
||||
with the input credentials unless the overwrite_cred input argument
|
||||
is TRUE.
|
||||
|
||||
Finally, if the current credential store has no default credential
|
||||
(that is, no credential that could be acquired for GSS_C_NO_NAME) or
|
||||
if the default_cred input argument is TRUE, and the input credential
|
||||
can be successfully stored, then the input credential will be
|
||||
available for acquisition with GSS_C_NO_NAME as the desired name
|
||||
input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as
|
||||
GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(),
|
||||
GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and
|
||||
GSS_Accept_sec_context().
|
||||
|
||||
N. Williams [Page 5]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
|
||||
2.1 C-Bindings for GSS_Store_cred()
|
||||
|
||||
The C-bindings for GSS_Store_cred() make use of types from and are
|
||||
designed based on the style of the GSS-APIv2 C-Bindings [RFC2744].
|
||||
|
||||
OM_uint32 gss_store_cred(
|
||||
OM_uint32 *minor_status,
|
||||
gss_cred_id_t input_cred,
|
||||
gss_cred_usage_t cred_usage,
|
||||
const gss_OID desired_mech,
|
||||
OM_uint32 overwrite_cred,
|
||||
OM_uint32 default_cred,
|
||||
gss_OID_set *elements_stored,
|
||||
gss_cred_usage_t *cred_usage_stored)
|
||||
|
||||
The two boolean arguments, 'overwrite_cred' and 'default_cred' are
|
||||
typed as OM_uint32; 0 corresponds to FALSE, non-zero values
|
||||
correspond to TRUE.
|
||||
|
||||
3 Examples
|
||||
|
||||
The intended usage of GSS_Store_cred() is to make delegated
|
||||
credentials available to child processes of GSS-API acceptor
|
||||
applications. Example pseudo-code:
|
||||
|
||||
/*
|
||||
* <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE, an
|
||||
* initiator name (hereafter, "src_name") and a delegated credential
|
||||
* handle (hereafter "deleg_cred").>
|
||||
*
|
||||
* <"requested_username" is a username derived from the initiator
|
||||
* name or explicitly requested by the initiator application.>
|
||||
*/
|
||||
...
|
||||
|
||||
if (authorize_gss_client(src_name, requested_username)) {
|
||||
/*
|
||||
* For Unix-type platforms this may mean calling setuid() and it
|
||||
* may or may not also mean setting/unsetting such environment
|
||||
* variables as KRB5CCNAME and what not.
|
||||
*/
|
||||
if (change_user_context(requested_username))
|
||||
(void) gss_store_creds(&minor_status, deleg_cred,
|
||||
GSS_C_INITIATE, actual_mech,
|
||||
0, 1, NULL, NULL);
|
||||
}
|
||||
else ...
|
||||
}
|
||||
else ...
|
||||
|
||||
4 Security Considerations
|
||||
|
||||
|
||||
N. Williams [Page 6]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
Acceptor applications MUST only store delegated credentials into
|
||||
appropriate credential stores and only after proper authorization of
|
||||
the authenticated initiator principal to the requested service(s).
|
||||
|
||||
Acceptor applications that have no use for delegated credentials MUST
|
||||
release them (such acceptor applications that use the GSS-API
|
||||
C-Bindings may simply provide a NULL value for the
|
||||
delegated_cred_handle argument to gss_accept_sec_context()).
|
||||
|
||||
5 References
|
||||
|
||||
5.1 Normative References
|
||||
|
||||
[RFC2026]
|
||||
S. Bradner, RFC2026: "The Internet Standard Process - Revision
|
||||
3," October 1996, Obsoletes - RFC 1602, Status: Best Current
|
||||
Practice.
|
||||
|
||||
[RFC2119]
|
||||
S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to
|
||||
Indicate Requirement Levels," March 1997, Status: Best Current
|
||||
Practice.
|
||||
|
||||
[RFC2743]
|
||||
J. Linn, RFC2743: "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1," January 2000, Status: Proposed
|
||||
Standard.
|
||||
|
||||
[RFC2744]
|
||||
J. Wray, RFC2744: "Generic Security Service API Version 2 :
|
||||
C-bindings," January 2000, Status: Proposed Standard.
|
||||
|
||||
6 Author's Address
|
||||
|
||||
Nicolas Williams
|
||||
Sun Microsystems
|
||||
5300 Riata Trace Ct
|
||||
Austin, TX 78727
|
||||
Email: Nicolas.Williams@sun.com
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2003). 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
|
||||
|
||||
N. Williams [Page 7]
|
||||
|
||||
DRAFT GSS_Store_cred() Expires March 2004
|
||||
|
||||
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.
|
||||
|
||||
Acknowledgement
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
N. Williams [Page 8]
|
1200
doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
Normal file
1200
doc/standardisation/draft-williams-gssapi-v3-guide-to-00.txt
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,432 @@
|
||||
NETWORK WORKING GROUP N. Williams
|
||||
Internet-Draft Sun
|
||||
Expires: December 30, 2004 July 2004
|
||||
|
||||
|
||||
|
||||
GSS-API Domain-Based Service Names Mapping for the Kerberos V GSS
|
||||
Mechanism
|
||||
draft-williams-krb5-gssapi-domain-based-names-00.txt
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
|
||||
By submitting this Internet-Draft, I certify that any applicable
|
||||
patent or other IPR claims of which I am aware have been disclosed,
|
||||
and any of which I become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
This Internet-Draft will expire on December 30, 2004.
|
||||
|
||||
|
||||
Copyright Notice
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
|
||||
This document describes the mapping of GSS-API domainname-based
|
||||
service principal names onto Kerberos V principal names.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 1]
|
||||
Internet-Draft Kerberos Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
|
||||
1. Conventions used in this document . . . . . . . . . . . . . . . 3
|
||||
2. Domain-Based Names for the Kerberos V GSS-API Mechanism . . . . 4
|
||||
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
|
||||
5. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . 7
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 2]
|
||||
Internet-Draft Kerberos Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
1. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 3]
|
||||
Internet-Draft Kerberos Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
2. Domain-Based Names for the Kerberos V GSS-API Mechanism
|
||||
|
||||
|
||||
In accordance with [DOMAIN-BASED-NAMES] this document provides the
|
||||
mechanism-specific details needed to implement GSS-API [RFC2743]
|
||||
domain-based service names with the Kerberos V GSS-API mechanism
|
||||
[RFC1964].
|
||||
|
||||
|
||||
GSS_C_NT_DOMAINBASED_SERVICE name are mapped to Kerberos V principal
|
||||
names as follows:
|
||||
o the <service> name becomes the first (0th) component of the
|
||||
Kerberos V principal name;
|
||||
o the <domain> name becomes the second component of the Kerberos V
|
||||
principal name; if the <domain> name is missing in the GSS name
|
||||
then a default domain name MUST be substituted (though no
|
||||
mechanism for determining this default is given here; this is an
|
||||
implementation-specific detail);
|
||||
o the <hostname>, if present, becomes the third component of the
|
||||
Kerberos V principal name;
|
||||
o the realm of the resulting principal name is that which
|
||||
corresponds to the domain name, treated as a hostname, or, if none
|
||||
can be determined in this way, then the realm of the hostname, if
|
||||
present, and, finally, if that is not possible, the default realm
|
||||
for the GSS-API caller.
|
||||
|
||||
|
||||
The same name canonicalization considerations and methods as used
|
||||
elsewhere in the Kerberos V GSS-API mechanism [RFC1964] and Kerberos
|
||||
V [RFC1510] in general apply here.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 4]
|
||||
Internet-Draft Kerberos Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
3. Examples
|
||||
|
||||
|
||||
o "ldap@@ds1.example.tld" may map to "ldap/example.tld/
|
||||
ds1.example.tld@EXAMPLE.TLD"
|
||||
o "ldap@example.tld@ds1.example.tld" may map to "ldap/example.tld/
|
||||
ds1.example.tld@EXAMPLE.TLD"
|
||||
|
||||
|
||||
o "kadmin@@kdc1.example.tld" may map to "kadmin/example.tld/
|
||||
kdc1.example.tld@EXAMPLE.TLD"
|
||||
o "kadmin@example.tld@kdc1.example.tld" may map to "kadmin/
|
||||
example.tld/kdc1.example.tld@EXAMPLE.TLD"
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 5]
|
||||
Internet-Draft Kerberos Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
4. Security Considerations
|
||||
|
||||
|
||||
See [DOMAIN-BASED-NAMES].
|
||||
|
||||
|
||||
5 Normative
|
||||
|
||||
|
||||
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
|
||||
Authentication Service (V5)", RFC 1510, September 1993.
|
||||
|
||||
|
||||
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC
|
||||
1964, June 1996.
|
||||
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
[RFC2743] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
|
||||
Nicolas Williams
|
||||
Sun Microsystems
|
||||
5300 Riata Trace Ct
|
||||
Austin, TX 78727
|
||||
US
|
||||
|
||||
|
||||
EMail: Nicolas.Williams@sun.com
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 6]
|
||||
Internet-Draft Kerberos Domain Based Names July 2004
|
||||
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Williams Expires December 30, 2004 [Page 7]
|
373
doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
Normal file
373
doc/standardisation/draft-williams-krb5-gssapi-prf-00.txt
Normal file
@@ -0,0 +1,373 @@
|
||||
NETWORK WORKING GROUP N. Williams
|
||||
Internet-Draft Sun
|
||||
Expires: December 30, 2004 S. Hartman
|
||||
MIT
|
||||
July 2004
|
||||
|
||||
|
||||
|
||||
A PRF for the Kerberos V GSS-API Mechanism
|
||||
draft-williams-krb5-gssapi-prf-00.txt
|
||||
|
||||
|
||||
Status of this Memo
|
||||
|
||||
|
||||
By submitting this Internet-Draft, I certify that any applicable
|
||||
patent or other IPR claims of which I am aware have been disclosed,
|
||||
and any of which I become aware will be disclosed, in accordance with
|
||||
RFC 3668.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
This Internet-Draft will expire on December 30, 2004.
|
||||
|
||||
|
||||
Copyright Notice
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). All Rights Reserved.
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
|
||||
This document defines the Pseudo-Random Function (PRF) for the
|
||||
Kerberos V GSS-API mechanism, based on the PRF defined for the
|
||||
Kerberos V cryptographic framework, for keying application protocols
|
||||
given an established Kerberos V GSS-API security context.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 1]
|
||||
Internet-Draft A PRF for the Kerberos V Mech July 2004
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
|
||||
1. Conventions used in this document . . . . . . . . . . . . . . . 3
|
||||
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4
|
||||
3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
|
||||
4. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . 6
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 2]
|
||||
Internet-Draft A PRF for the Kerberos V Mech July 2004
|
||||
|
||||
|
||||
|
||||
1. 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 [RFC2119].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 3]
|
||||
Internet-Draft A PRF for the Kerberos V Mech July 2004
|
||||
|
||||
|
||||
|
||||
2. Introduction
|
||||
|
||||
|
||||
The GSS-API PRF function for the Kerberos V mechanism shall be the
|
||||
output of the enctype's PRF function keyed with the negotiated
|
||||
session key of the security context (e.g., the acceptor's subkey) and
|
||||
key usage X (TBD).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 4]
|
||||
Internet-Draft A PRF for the Kerberos V Mech July 2004
|
||||
|
||||
|
||||
|
||||
3. Security Considerations
|
||||
|
||||
|
||||
Kerberos V enctypes' PRF functions should use a key derived from
|
||||
contexts' session keys and should preserve the forward security
|
||||
properties of the mechanisms' key exchanges.
|
||||
|
||||
|
||||
Care should be taken in properly designing a mechanism's PRF
|
||||
function. Cryptographic hash functions which do not provide strong
|
||||
collision resistance should not be used, except through HMAC.
|
||||
|
||||
|
||||
4 Normative
|
||||
|
||||
|
||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
[RFC2743] Linn, J., "Generic Security Service Application Program
|
||||
Interface Version 2, Update 1", RFC 2743, January 2000.
|
||||
|
||||
|
||||
[RFC2744] Wray, J., "Generic Security Service API Version 2 :
|
||||
C-bindings", RFC 2744, January 2000.
|
||||
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
|
||||
Nicolas Williams
|
||||
Sun Microsystems
|
||||
5300 Riata Trace Ct
|
||||
Austin, TX 78727
|
||||
US
|
||||
|
||||
|
||||
EMail: Nicolas.Williams@sun.com
|
||||
|
||||
|
||||
|
||||
Sam Hartman
|
||||
Massachussets Institute of Technology
|
||||
...
|
||||
..., MA ...
|
||||
US
|
||||
|
||||
|
||||
EMail: hartmans@mit.edu
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 5]
|
||||
Internet-Draft A PRF for the Kerberos V Mech July 2004
|
||||
|
||||
|
||||
|
||||
Intellectual Property Statement
|
||||
|
||||
|
||||
The IETF takes no position regarding the validity or scope of any
|
||||
Intellectual Property Rights or other rights that might be claimed to
|
||||
pertain to the implementation or use of the technology described in
|
||||
this document or the extent to which any license under such rights
|
||||
might or might not be available; nor does it represent that it has
|
||||
made any independent effort to identify any such rights. Information
|
||||
on the procedures with respect to rights in RFC documents can be
|
||||
found in BCP 78 and BCP 79.
|
||||
|
||||
|
||||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||||
assurances of licenses to be made available, or the result of an
|
||||
attempt made to obtain a general license or permission for the use of
|
||||
such proprietary rights by implementers or users of this
|
||||
specification can be obtained from the IETF on-line IPR repository at
|
||||
http://www.ietf.org/ipr.
|
||||
|
||||
|
||||
The IETF invites any interested party to bring to its attention any
|
||||
copyrights, patents or patent applications, or other proprietary
|
||||
rights that may cover technology that may be required to implement
|
||||
this standard. Please address the information to the IETF at
|
||||
ietf-ipr@ietf.org.
|
||||
|
||||
|
||||
|
||||
Disclaimer of Validity
|
||||
|
||||
|
||||
This document and the information contained herein are provided on an
|
||||
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
|
||||
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
|
||||
ENGINEERING TASK FORCE DISCLAIM 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.
|
||||
|
||||
|
||||
|
||||
Copyright Statement
|
||||
|
||||
|
||||
Copyright (C) The Internet Society (2004). This document is subject
|
||||
to the rights, licenses and restrictions contained in BCP 78, and
|
||||
except as set forth therein, the authors retain all their rights.
|
||||
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
|
||||
Funding for the RFC Editor function is currently provided by the
|
||||
Internet Society.
|
||||
|
||||
|
||||
|
||||
|
||||
Williams & Hartman Expires December 30, 2004 [Page 6]
|
1155
doc/standardisation/draft-zhu-spnego-2478bis-00.txt
Normal file
1155
doc/standardisation/draft-zhu-spnego-2478bis-00.txt
Normal file
File diff suppressed because it is too large
Load Diff
Reference in New Issue
Block a user