draft-ietf-kitten-gss-naming-03.txt   draft-ietf-kitten-gss-naming-04.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft MIT Internet-Draft MIT
Expires: April 26, 2006 October 23, 2005 Expires: September 6, 2006 March 5, 2006
Desired Enhancements to GSSAPI Naming Desired Enhancements to GSSAPI Version 3 Naming
draft-ietf-kitten-gss-naming-03.txt draft-ietf-kitten-gss-naming-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 26, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Generic Security Services API (GSS-API) provides a naming The Generic Security Services API (GSS-API) provides a naming
architecture that supports name-based authorization. GSS-API architecture that supports name-based authorization. GSS-API
authenticates two named parties to each other. Names can be stored authenticates two named parties to each other. Names can be stored
on access control lists to make authorization decisions. Advances in on access control lists to make authorization decisions. Advances in
security mechanisms and the way implementers wish to use GSS-API security mechanisms and the way implementers wish to use GSS-API
require this model to be extended. As people move within an require this model to be extended for the next version of GSS-API.
organization or change their names, the name authenticated by GSS-API As people move within an organization or change their names, the name
may change. Using some sort of constant identifier would make ACLs authenticated by GSS-API may change. Using some sort of constant
more stable. Some mechanisms such as public-key mechanisms do not identifier would make ACLs more stable. Some mechanisms such as
have a single name to be used across all environments. Other public-key mechanisms do not have a single name to be used across all
mechanisms such as Kerberos include may include group membership or environments. Other mechanisms such as Kerberos may include group
role information as part of authentication. This document motivates membership or role information as part of authentication. This
extensions to GSS-API naming and describes the extensions under document motivates extensions to GSS-API naming and describes the
discussion. extensions under discussion.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Kerberos Naming . . . . . . . . . . . . . . . . . . . . . . . 5
3. X.509 Names . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Composite Names . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Usage of Name Attributes . . . . . . . . . . . . . . . . . 7
4.2 Open issues . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Handling gss_export_name . . . . . . . . . . . . . . . . . 8
5. Credential Extensions . . . . . . . . . . . . . . . . . . . . 10
6. Mechanisms for Export Name . . . . . . . . . . . . . . . . . . 11
7. Selection of Source Identity . . . . . . . . . . . . . . . . . 12
8. Compatibility with GSS-API V2 . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 16
1. Introduction 1. Introduction
The Generic Security Services API [2] authenticates two named parties The Generic Security Services API [2] authenticates two named parties
to each other. GSS names can be imported in a variety of formats to each other. GSS names can be imported in a variety of formats
through the gss_import_name call. Several mechanism-independent name through the gss_import_name call. Several mechanism-independent name
formats are provided including GSS_C_NT_HOSTBASED_SERVICE for formats are provided including GSS_C_NT_HOSTBASED_SERVICE for
services running on an Internet host and GSS_C_NT_USER_NAME for the services running on an Internet host and GSS_C_NT_USER_NAME for the
names of users. Other mechanism-specific name types are also names of users. Other mechanism-specific name types are also
provided. By the time a name is used in acquiring a mechanism- provided. By the time a name is used in acquiring a mechanism-
skipping to change at page 4, line 5 skipping to change at page 4, line 5
Also, as GSS-API is used in more complex environments, there is a Also, as GSS-API is used in more complex environments, there is a
desire to use attribute certificates [6], Kerberos authorization data desire to use attribute certificates [6], Kerberos authorization data
[3], or other non-name-based authorization models. GSS-API needs to [3], or other non-name-based authorization models. GSS-API needs to
be enhanced in order to support these uses in a mechanism-independent be enhanced in order to support these uses in a mechanism-independent
manner. manner.
This document discusses the particular naming problems with two This document discusses the particular naming problems with two
important classes of GSS-API mechanisms. It also discusses the set important classes of GSS-API mechanisms. It also discusses the set
of proposed solutions and open issues with these solutions. This of proposed solutions and open issues with these solutions. This
draft limits discussion to these solutions and provides a description draft limits discussion to these solutions and provides a description
of the problem against which the solutions can be judged. of the problem against which the solutions can be judged. These
solutions are targeted for incorporation into GSS-API Version 3.
2. Kerberos Naming 2. Kerberos Naming
The Kerberos mechanism demonstrates both the naming stability problem The Kerberos mechanism demonstrates both the naming stability problem
and the authorization extension problem. and the authorization extension problem.
The Kerberos Referrals draft [4] proposes a new type of Kerberos name The Kerberos Referrals draft [4] proposes a new type of Kerberos name
called an enterprise name. The intent is that the enterprise name is 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. an alias that the user knows for themselves and can use to login.
The Kerberos KDC translates this name into a normal Kerberos The Kerberos KDC translates this name into a normal Kerberos
principal and gives the user tickets for this principal. This normal principal and gives the user tickets for this principal. This normal
principal is used for authorization. The intent is that the principal is used for authorization. The intent is that the
enterprise name tracks the user as they move throughout the enterprise name tracks the user as they move throughout the
organization, even if they move to parts of the organization that organization, even if they move to parts of the organization that
have different naming policies. The name they type at login remains have different naming policies. The name they type at login remains
constant, but the Kerberos principal used to authenticate them to constant, but the Kerberos principal used to authenticate them to
services changes. services changes.
Performing a mapping from enterprise name to principal name is not Unauthenticated services cannot generally perform a mapping from
generally possible for unauthenticated services. Even authenticated enterprise name to principal name. Even authenticated services may
services may not be authorized to perform this mapping except for not be authorized to map names other than the name of the
their own name. Also, Kerberos does not (and does not plan to) authenticated service. Also, Kerberos does not (and does not plan
provide a mechanism for mapping enterprise names to principals to) provide a mechanism for mapping enterprise names to principals
besides authentication as the enterprise name. Thus, any such besides authentication as the enterprise name. Thus, any such
mapping would be vendor-specific. With this feature in Kerberos, it mapping would be vendor-specific. With this feature in Kerberos, it
is not possible to implement gss_canonicalize_name for enterprise is not possible to implement gss_canonicalize_name for enterprise
name types. name types. Of course other names types such as traditional
principal names could be used for GSS-API applications. Naturally
this loses the benefits of enterprise names.
Another issue arises with enterprise names. In some cases, it would Another issue arises with enterprise names. In some cases, it would
be desirable to put the enterprise name on the ACL instead of a be desirable to put the enterprise name on the ACL instead of a
principal name for greater ACL stability. At first glance this could principal name for greater ACL stability. At first glance this could
be accomplished by including the enterprise name in the name exported be accomplished by including the enterprise name in the name exported
by gss_export_name. Unfortunately, if this were done, the exported by gss_export_name. Unfortunately, if this were done, the exported
name would change whenever the mapping changed, invalidating any ACL name would change whenever the mapping changed, invalidating any ACL
entries based off the old exported name and defeating the purpose of entries based off the old exported name and defeating the purpose of
including the enterprise name in the exported name. In some cases it including the enterprise name in the exported name. In some cases it
would be desirable to have the exported name be based on the would be desirable to have the exported name be based on the
skipping to change at page 7, line 29 skipping to change at page 7, line 29
3. Query values of an attribute. 3. Query values of an attribute.
4. Delete an attribute from a name. 4. Delete an attribute from a name.
5. Export a complete composite name and all its attributes for 5. Export a complete composite name and all its attributes for
transport between processes. transport between processes.
Note that an exported composite name would not generally be suitable Note that an exported composite name would not generally be suitable
for binary comparison. Avoiding confusion between this operation and for binary comparison. Avoiding confusion between this operation and
the existing gss_export_name operation will require careful work. the existing gss_export_name operation will require careful work.
However many attributes of composite names will be appropriate for
binary comparisons. Such attributes can be used on ACLs just as
exported names are used on ACLs today. For example if a particular
SubjectAltname extension contains the appropriate identity for an
application, then the name attribute for this SubjectAltname can be
placed on the ACL. This is only true if the name attribute is stored
in some canonical form.
Additional utility operations will probably be needed depending on Additional utility operations will probably be needed depending on
the implementation of name attributes. the implementation of name attributes.
4.1 Usage of Name Attributes 4.1 Usage of Name Attributes
Since attributes are part of GSS-API names, the acceptor can retrieve Since attributes are part of GSS-API names, the acceptor can retrieve
the attributes of the initiator's and acceptor's name from the the attributes of the initiator's and acceptor's name from the
context. These attributes can then be used for authorization. context. These attributes can then be used for authorization.
Most name attributes will probably not come from explicit operations Most name attributes will probably not come from explicit operations
to add attributes to a name. Instead, name attributes will probably to add attributes to a name. Instead, name attributes will probably
come from mechanism specific credentials. Components of these come from mechanism specific credentials. Components of these
mechanism specific credentials may come from platform or environment- mechanism specific credentials may come from platform or environment-
specific names. Mechanism specific naming and group membership can specific names. Mechanism specific naming and group membership can
be mapped into name attributes by the mechanism implementation. The be mapped into name attributes by the mechanism implementation. The
specific form of this mapping will generally require protocol specific form of this mapping will generally require protocol
specification for each mechanism. specification for each mechanism.
The value of many name attributes may be suitable for use in binary
comparison. This should enable applications to use these name
attributes on ACLs the same way exported names are now used on ACLs.
For example if a particular SubjectAltname extension contains the
appropriate identity for an application, then the name attribute
for this SubjectAltname can be placed on the ACL. This is only true
if the name attribute is stored in some canonical form.
4.2 Open issues 4.2 Open issues
This section describes parts of the proposal to add attributes to This section describes parts of the proposal to add attributes to
names that will need to be explored before the proposal can become a names that will need to be explored before the proposal can become a
protocol specification. protocol specification.
Are mechanisms expected to be able to carry arbitrary name attributes Are mechanisms expected to be able to carry arbitrary name attributes
as part of a context establishment? At first it seems like this as part of a context establishment? At first it seems like this
would be desirable. However the purpose of GSS-API is to establish would be desirable. However the purpose of GSS-API is to establish
an authenticated context between two peers. In particular, a context an authenticated context between two peers. In particular, a context
skipping to change at page 12, line 18 skipping to change at page 12, line 18
connections to multiple targets. For each target the there may be connections to multiple targets. For each target the there may be
one or more source identities that is appropriate for the connection. one or more source identities that is appropriate for the connection.
Currently each application must choose the source name to use when Currently each application must choose the source name to use when
acquiring credentials or initiating a security context. However the acquiring credentials or initiating a security context. However the
rules that applications use can be generalized to a large extent. rules that applications use can be generalized to a large extent.
GSS-API could simplify application design and implementation by GSS-API could simplify application design and implementation by
taking a larger role in selection of source identity to use when taking a larger role in selection of source identity to use when
connecting to a particular target. connecting to a particular target.
Currently GSS-API credentials represent a single mechanism name. that Currently GSS-API credentials represent a single mechanism name. that
is, by the time credentials are acquired, a particular single is, by the time credentials are acquired, they must act as if a
identity must be chosen for each mechanism in the credential. All particular single identity is chosen for each mechanism in the
these identities must correspond to a single mechanism independent credential. All these identities must correspond to a single
name. mechanism independent name.
Two possibilities have been proposed for involving GSS-API in the Two possibilities have been proposed for involving GSS-API in the
selection of source identities. First, the restriction that a selection of source identities. First, the restriction that a
mechanism name must be chosen when credentials are acquired could be mechanism name must be chosen when credentials are acquired could be
relaxed. Some name form would need to be used, but this name form relaxed. Some name form would need to be used, but this name form
could represent a set of possibilities. The particular identity could represent a set of possibilities. The particular identity
would be chosen when context establishment happened. This could would be chosen when context establishment happened. This could
involve information received from the target in identity selection. involve information received from the target in identity selection.
Another possibility is to provide a mechanism to acquire credentials Another possibility is to provide a mechanism to acquire credentials
and to provide information about the target when credentials are and to provide information about the target when credentials are
acquired. This would be much less of a change to GSS-API but would acquired. This would be much less of a change to GSS-API but would
not allow information received from the target to choose identity not allow information received from the target to choose identity
selection. selection.
With both approaches, information to communicate the needs of the With both approaches, information to communicate the needs of the
application to the GSS-API mechanism will be required. For example, application to the GSS-API mechanism will be required. For example,
hinting about whether information can be cached and about the scope hinting about whether information can be cached and about the scope
of cache entries is required. of cache entries is required.
8. Security Considerations Another possibility can be implemented in GSS-API V2 today. Do not
bind the credentials to a mechanism name until either the credentials
are queried or they are used to set up a context. This is
undesirable because if an application uses the credential inquiry
interface then it will get different behavior than cases where this
interface is not used. For this reason, the working group favors an
extension to GSS-API V3.
8. Compatibility with GSS-API V2
In order to avoid breaking existing applications or mechanisms the
following backward compatibility requirements need to be met:
1. Existing APIs must continue to behave as they do in GSS-API V2.
2. GSS-API V2 mechanisms must produce the same exported name forms;
composite names cannot change the existing exported name forms.
3. Extensions add new optional behavior.
If GSS-API V3 mechanisms are more permissive than GSS-API V2
mechanisms then care must be taken so that GSS-API V2 applications do
not select these mechanisms.
9. Security Considerations
GSS-API sets up a security context between two named parties. The GSS-API sets up a security context between two named parties. The
GSS-API names are security assertions that are authenticated by the GSS-API names are security assertions that are authenticated by the
context establishment process. As such the GSS naming architecture context establishment process. As such the GSS naming architecture
is critical to the security of GSS-API. is critical to the security of GSS-API.
Currently GSS-API uses a simplistic naming model for authorization. Currently GSS-API uses a simplistic naming model for authorization.
Names can be compared against a set of names on an access control Names can be compared against a set of names on an access control
list. This architecture is relatively simple and its security list. This architecture is relatively simple and its security
properties are well understood. However it does not provide the properties are well understood. However it does not provide the
skipping to change at page 14, line 5 skipping to change at page 15, line 5
consider ways of managing security exposures created by this consider ways of managing security exposures created by this
increased complexity. increased complexity.
One area where the complexity may lead to security problems is One area where the complexity may lead to security problems is
composite names with attributes from different sources. This may be composite names with attributes from different sources. This may be
desirable so that name attributes that carry their own desirable so that name attributes that carry their own
authentication. However the design of any solutions needs to make authentication. However the design of any solutions needs to make
sure that applications can assign appropriate trust to name sure that applications can assign appropriate trust to name
components. components.
9. Acknowledgements 10. Acknowledgements
John Brezak, Paul Leach and Nicolas Williams all participated in John Brezak, Paul Leach and Nicolas Williams all participated in
discussions that lead to a desire to enhance GSS naming. Martin Rex discussions that lead to a desire to enhance GSS naming. Martin Rex
provided descriptions of the current naming architecture and pointed provided descriptions of the current naming architecture and pointed
out many ways in which proposed enhancements would create out many ways in which proposed enhancements would create
interoperability problems or increase complexity. Martin also interoperability problems or increase complexity. Martin also
provided excellent information on what aspects of GSS naming have provided excellent information on what aspects of GSS naming have
tended to be implemented badly or have not met the needs of some tended to be implemented badly or have not met the needs of some
customers. customers.
Nicolas Williams helped describe the possible approaches for Nicolas Williams helped describe the possible approaches for
enhancing naming. enhancing naming.
10. Informative References 11. Informative References
[1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
rfc 2025, October 1996. rfc 2025, October 1996.
[2] Linn, J., "Generic Security Service Application Program [2] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos [3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
skipping to change at page 15, line 41 skipping to change at page 16, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 15 change blocks. 
37 lines changed or deleted 82 lines changed or added

This html diff was produced by rfcdiff 1.29, available from http://www.levkowetz.com/ietf/tools/rfcdiff/