draft-ietf-kitten-gss-naming-05.txt   rfc4768.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft MIT Request for Comments: 4768 MIT
Expires: March 4, 2007 August 31, 2006 Category: Informational December 2006
Desired Enhancements to GSSAPI Version 3 Naming
draft-ietf-kitten-gss-naming-05.txt
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Desired Enhancements to
http://www.ietf.org/ietf/1id-abstracts.txt. Generic Security Services Application Program Interface (GSS-API)
Version 3 Naming
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 4, 2007. This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (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 (ACLs) to make authorization decisions.
security mechanisms and the way implementers wish to use GSS-API Advances in security mechanisms and the way implementers wish to use
require this model to be extended for the next version of GSS-API. GSS-API require this model to be extended for the next version of
As people move within an organization or change their names, the name GSS-API. As people move within an organization or change their
authenticated by GSS-API may change. Using some sort of constant names, the name authenticated by GSS-API may change. Using some sort
identifier would make ACLs more stable. Some mechanisms such as of constant identifier would make ACLs more stable. Some mechanisms,
public-key mechanisms do not have a single name to be used across all such as public-key mechanisms, do not have a single name to be used
environments. Other mechanisms such as Kerberos may include group across all environments. Other mechanisms, such as Kerberos, may
membership or role information as part of authentication. This include group membership or role information as part of
document motivates extensions to GSS-API naming and describes the authentication. This document motivates extensions to GSS-API naming
extensions under discussion. and describes the extensions under discussion.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Kerberos Naming . . . . . . . . . . . . . . . . . . . . . . . 5 2. Kerberos Naming .................................................3
3. X.509 Names . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. X.509 Names .....................................................4
4. Composite Names . . . . . . . . . . . . . . . . . . . . . . . 7 4. Composite Names .................................................5
4.1. Usage of Name Attributes . . . . . . . . . . . . . . . . . 7 4.1. Usage of Name Attributes ...................................6
4.2. Open issues . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Open Issues ................................................6
4.3. Handling gss_export_name . . . . . . . . . . . . . . . . . 8 4.3. Handling gss_export_name ...................................7
5. Credential Extensions . . . . . . . . . . . . . . . . . . . . 10 5. Credential Extensions ...........................................7
6. Mechanisms for Export Name . . . . . . . . . . . . . . . . . . 11 6. Mechanisms for Export Name ......................................8
7. Selection of Source Identity . . . . . . . . . . . . . . . . . 12 7. Selection of Source Identity ....................................8
8. Compatibility with GSS-API V2 . . . . . . . . . . . . . . . . 13 8. Compatibility with GSS-API V2 ...................................9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations .........................................9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements ..............................................10
11. Informative References . . . . . . . . . . . . . . . . . . . . 15 11. Informative References ........................................10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
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-
specific credential or establishing a security context, it has been specific credential or establishing a security context, it has been
transformed into one of these mechanism-specific name types. In transformed into one of these mechanism-specific name types. In
addition, the GSS-API provides a function called gss_export_name that addition, the GSS-API provides a function called gss_export_name that
will transform a GSS-API name into a binary blob suitable for will transform a GSS-API name into a binary blob suitable for
comparisons. This binary blob can be stored on ACLs and then comparisons. This binary blob can be stored on ACLs and then
authorization decisions can be made simply by comparing the name authorization decisions can be made simply by comparing the name
exported from a newly accepted context to the name on the ACL. exported from a newly accepted context to the name on the ACL.
Storing names on ACLs can be problematic because names tend to change Storing names on ACLs can be problematic because names tend to change
over time . If the name contains organizational information such as over time. If the name contains organizational information, such as
a domain part or an indication of what department someone works for, a domain part or an indication of what department someone works for,
this changes as the person moves around the organization. Even if no this changes as the person moves around the organization. Even if no
organizational information is included in the name, the name will organizational information is included in the name, the name will
change as people change their names. Updating ACLs to reflect name change as people change their names. Updating ACLs to reflect name
changes is difficult. Another significant problem is that names can changes is difficult. Another significant problem is that names can
be reused to apply to an entity other than the entity to which they be reused to apply to an entity other than the entity to which they
originally applied. For example if a Unix user ID is placed on an originally applied. For example, if a Unix user ID is placed on an
ACL, the account deleted and then a new user assigned the old ID, ACL, the account deleted and then a new user assigned the old ID,
then that new user may gain privileges intended for the old user. then that new user may gain privileges intended for the old user.
Inherent in the GSS naming model is the idea that mechanism names Inherent in the GSS naming model is the idea that mechanism names
need to be able to be represented in a single canonical form. Anyone need to be able to be represented in a single canonical form. Anyone
importing that name needs to be able to retrieve the canonical form importing that name needs to be able to retrieve the canonical form
of that name. of that name.
Several security mechanisms have been proposed for which this naming Several security mechanisms have been proposed for which this naming
architecture is too restrictive. In some cases it is not always architecture is too restrictive. In some cases, it is not always
possible to canonicalize any name that is imported. In other cases possible to canonicalize any name that is imported. In other cases,
there is no single canonical name. there is no single canonical name.
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 their associated open issues. This
draft limits discussion to these solutions and provides a description document limits discussion to these solutions and provides a
of the problem against which the solutions can be judged. These description of the problem against which the solutions can be judged.
solutions are targeted for incorporation into GSS-API Version 3. 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 document [4] proposes a new type of Kerberos
called an enterprise name. The intent is that the enterprise name is name called an enterprise name. The intent is that the enterprise
an alias that the user knows for themselves and can use to login. name is an alias that the user knows for themselves and can use to
The Kerberos KDC translates this name into a normal Kerberos log in. The Kerberos Key Distribution Center (KDC) translates this
principal and gives the user tickets for this principal. This normal name into a normal Kerberos principal and gives the user tickets for
principal is used for authorization. The intent is that the this principal. This normal principal is used for authorization.
enterprise name tracks the user as they move throughout the The intent is that the enterprise name tracks the user as they moves
organization, even if they move to parts of the organization that throughout the organization, even if they move to parts of the
have different naming policies. The name they type at login remains organization that have different naming policies. The name they type
constant, but the Kerberos principal used to authenticate them to at login remains constant, but the Kerberos principal used to
services changes. authenticate them to services changes.
Unauthenticated services cannot generally perform a mapping from Unauthenticated services cannot generally perform a mapping from
enterprise name to principal name. Even authenticated services may enterprise name to principal name. Even authenticated services may
not be authorized to map names other than the name of the not be authorized to map names other than the name of the
authenticated service. Also, Kerberos does not (and does not plan authenticated service. Also, Kerberos does not (and does not plan
to) 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. Of course other names types such as traditional name types. Of course, other name types such as traditional
principal names could be used for GSS-API applications. Naturally principal names could be used for GSS-API applications. Naturally,
this loses the benefits of enterprise names. 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
be accomplished by including the enterprise name in the name exported could be accomplished by including the enterprise name in the name
by gss_export_name. Unfortunately, if this were done, the exported exported by gss_export_name. Unfortunately, if this were done, the
name would change whenever the mapping changed, invalidating any ACL exported name would change whenever the mapping changed, invalidating
entries based off the old exported name and defeating the purpose of any ACL entries based off the old exported name and defeating the
including the enterprise name in the exported name. In some cases it purpose of including the enterprise name in the exported name. In
would be desirable to have the exported name be based on the some cases, it would be desirable to have the exported name be based
enterprise name and in others based on the principal name, but this on the enterprise name and, in others, based on the principal name,
is not permitted by the current GSS-API. but this is not permitted by the current GSS-API.
Another development also complicates GSS-API naming for Kerberos. Another development also complicates GSS-API naming for Kerberos.
Several vendors have been looking at mechanisms to include group Several vendors have been looking at mechanisms to include group
membership information in Kerberos authorization data. It is membership information in Kerberos authorization data. It is
desirable to put these group names on ACLs. Again, GSS-API currently desirable to put these group names on ACLs. Again, GSS-API currently
has no mechanism to use this information. has no mechanism to use this information.
3. X.509 Names 3. X.509 Names
X.509 names are more complicated than Kerberos names. In the X.509 names are more complicated than Kerberos names. In the
Kerberos case there is a single principal carried in all Kerberos Kerberos case, there is a single principal carried in all Kerberos
messages. X.509 certificates have multiple options. It seems the messages. X.509 certificates have multiple options. It seems the
subject name might be the appropriate name to use as the name to be subject name might be the appropriate name to use as the name to be
exported in a GSS-API mechanism. However RFC 3280 [5] allows the exported in a GSS-API mechanism. However, RFC 3280 [5] allows the
subject name to be an empty sequence in end-entity certificates. subject name to be an empty sequence in end-entity certificates.
Therefore the subjectAltName extension might be the only portion of Therefore, the subjectAltName extension might be the only portion of
the certificate that identifies the subject. As in the case of the certificate that identifies the subject. As in the case of
Kerberos group memberships, there may be many subjectAltName Kerberos group memberships, there may be many subjectAltName
extensions available in a certificate. Different applications will extensions available in a certificate. Different applications will
care about different name forms. One possible candidate for an care about different name forms. One possible candidate for an
exported name would be all the names from the subject field and the exported name would be all the names from the subject field, and the
subjectAltName extension from a certificate. However as new names subjectAltName extension from a certificate. However, as new names
are added then existing ACL entries would be invalidated; this is are added, existing ACL entries would be invalidated; this is
undesirable. Thus there is no single value that can be defined as undesirable. Thus, there is no single value that can be defined as
the exported GSS-API name that will be useful in all environments. the exported GSS-API name that will be useful in all environments.
A profile of a particular X.509 GSS-API mechanism could require a A profile of a particular X.509 GSS-API mechanism could require that
specific name be used. However this would limit that mechanism to a specific name be used. However, this would limit that mechanism to
require a particular type of certificate. There is interest in being require a particular type of certificate. There is interest in being
able to use arbitrary X.509 certificates with GSS-API for some able to use arbitrary X.509 certificates with GSS-API for some
applications. applications.
Experience so far has not lead to sufficient interoperability with Experience so far has not led to sufficient interoperability with
GSS-API X.509 mechanisms. Even if the subject name is used, there is GSS-API X.509 mechanisms. Even if the subject name is used, there is
ambiguity in how to handle sorting of name components. Martin Rex ambiguity in how to handle sorting of name components. Martin Rex
said that he was aware of several SPKM [1] implementations but no two said that he was aware of several SPKM [1] implementations, but that
were fully interoperable on names. no two were fully interoperable on names.
Also, as discussed in the introduction, it is desirable to support Also, as discussed in the introduction, it is desirable to support
X.509 attribute certificates. X.509 attribute certificates.
4. Composite Names 4. Composite Names
One proposal to solve these problems is to extend the concept of a One proposal to solve these problems is to extend the concept of a
GSS-API name to include a set of name attributes. Each attribute GSS-API name to include a set of name attributes. Each attribute
would be an octet-string labeled by an OID. Examples of attributes would be an octet-string labeled by an OID. Examples of attributes
would include Kerberos enterprise names, group memberships in an would include Kerberos enterprise names, group memberships in an
authorization infrastructure, Kerberos authorization data attributes authorization infrastructure, and Kerberos authorization data
and subjectAltName attributes in a certificate. Several new attributes and subjectAltName attributes in a certificate. Several
operations would be needed: new operations would be needed:
1. Add an attribute to name. 1. Add an attribute to name.
2. Query attributes of name. 2. Query attributes of name.
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 However, many attributes of composite names will be appropriate for
binary comparisons. Such attributes can be used on ACLs just as binary comparisons. Such attributes can be used on ACLs, just as
exported names are used on ACLs today. For example if a particular exported names are used on ACLs today. For example, if a particular
SubjectAltName extension contains the appropriate identity for an SubjectAltName extension contains the appropriate identity for an
application, then the name attribute for this SubjectAltName can be application, then the name attribute for this SubjectAltName can be
placed on the ACL. This is only true if the name attribute is stored placed on the ACL. This is only true if the name attribute is stored
in some canonical form. 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 be specific names. Mechanism-specific naming and group membership can
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.
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
authenticates two named entities to each other. The names of these authenticates two named entities to each other. The names of these
entities and attributes associated with these names will be used for entities and attributes associated with these names will be used for
authorization decisions. If an initiator or acceptor is allowed to authorization decisions. If an initiator or acceptor is allowed to
assert name attributes and the authenticity of these assertions is assert name attributes, and the authenticity of these assertions is
not validated by the mechanisms, then security problems will result. not validated by the mechanisms, then security problems will result.
On the other hand, requiring that name attributes be mechanism- On the other hand, requiring that name attributes be
specific and only be carried by mechanisms that understand the name mechanism-specific and only be carried by mechanisms that understand
attributes and can validate them compromises GSS-API's place as a the name attributes and can validate them compromises GSS-API's place
generic API. Application authors would be forced to understand as a generic API. Application authors would be forced to understand
mechanism-specific attributes to make authorization decisions. In mechanism-specific attributes to make authorization decisions. In
addition if mechanisms are not required to transport arbitrary addition, if mechanisms are not required to transport arbitrary
attributes, then application authors will need to deal with different attributes, then application authors will need to deal with different
implementations of the same mechanism that support different sets of implementations of the same mechanism that support different sets of
name attributes. One possible solution is to carry a source along name attributes. One possible solution is to carry a source along
with each name attribute; this source could indicate whether the with each name attribute; this source could indicate whether the
attribute comes from a mechanism data structure or from the other attribute comes from a mechanism data structure or from the other
party in the authentication. party in the authentication.
Another related question is how will name attributes be mapped into Another related question is how name attributes will be mapped into
their mechanism-specific forms. For example it would be desirable to their mechanism-specific forms. For example, it would be desirable
map many Kerberos authorization data elements into name attributes. to map many Kerberos authorization data elements into name
In the case of the Microsoft PAC, it would be desirable for some attributes. In the case of the Microsoft PAC (privilege attribute
applications to get the entire PAC. However in many cases, the certificate), it would be desirable for some applications to get the
specific lists of security IDs contained in the PAC would be more entire PAC. However, in many cases, the specific lists of security
directly useful to an application. So there may not be a good one- IDs contained in the PAC would be more directly useful to an
to-one mapping between the mechanism-specific elements and the application. So there may not be a good one-to-one mapping between
representation desirable at the GSS-API layer. the mechanism-specific elements and the representation desirable at
the GSS-API layer.
Specific name matching rules need to be developed. How do names with Specific name matching rules need to be developed. How do names with
attributes compare? What is the effect of a name attribute on a attributes compare? What is the effect of a name attribute on a
target name in gss_accept_sec_context? target name in gss_accept_sec_context?
4.3. Handling gss_export_name 4.3. Handling gss_export_name
For many mechanisms, there will be an obvious choice to use for the 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 name exported by gss_export_name. For example, in the case of
Kerberos, the principal name can continue to be used as the exported Kerberos, the principal name can continue to be used as the exported
name. This will allow applications depending on existing GSS-API name. This will allow applications that depend on existing GSS-API
name-based authorization to continue to work. However it is probably name-based authorization to continue to work. However, it is
desirable to allow GSS-API mechanisms for which gss_export_name probably desirable to allow GSS-API mechanisms for which
cannot meaningfully be defined. The behavior of gss_export_name in gss_export_name cannot meaningfully be defined. In such cases, the
such cases should probably be to return some error. Such mechanisms behavior of gss_export_name should probably be to return some error.
may not work with existing applications and cannot conform to the Such mechanisms may not work with existing applications and cannot
current version of the GSS-API. conform to the current version of the GSS-API.
5. Credential Extensions 5. Credential Extensions
An alternative to the name attributes proposal is to extend GSS-API An alternative to the name attributes proposal is to extend GSS-API
credentials with extensions labeled by OIDs. Interfaces would be credentials with extensions labeled by OIDs. Interfaces would be
needed to manipulate these credential extensions and to retrieve the needed to manipulate these credential extensions and to retrieve the
credential extensions for credentials used to establish a context. credential extensions for credentials used to establish a context.
Even if name attributes are used, credential extensions may be useful Even if name attributes are used, credential extensions may be useful
for other unrelated purposes. for other unrelated purposes.
skipping to change at page 10, line 25 skipping to change at page 7, line 47
some credential extension mechanism. Doing so will have many of the some credential extension mechanism. Doing so will have many of the
same open issues as discussed in the composite names proposal. The same open issues as discussed in the composite names proposal. The
main advantage of a credential extensions proposal is that it avoids main advantage of a credential extensions proposal is that it avoids
specifying how name attributes interact with name comparison or specifying how name attributes interact with name comparison or
target names. target names.
The primary advantage of the name attributes proposal over credential The primary advantage of the name attributes proposal over credential
extensions is that name attributes seem to fit better into the GSS- extensions is that name attributes seem to fit better into the GSS-
API authorization model. Names are already available at all points API authorization model. Names are already available at all points
when authorization decisions are made. In addition, for many when authorization decisions are made. In addition, for many
mechanisms the sort of information carried as name attributes will mechanisms, the sort of information carried as name attributes will
also be carried as part of the name in the mechanism also be carried as part of the name in the mechanism.
6. Mechanisms for Export Name 6. Mechanisms for Export Name
Another proposal is to define some GSS-API mechanisms whose only Another proposal is to define some GSS-API mechanisms whose only
purpose is to have an exportable name form that is useful. For 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 example, you might be able to export a name as a local machine user
ID with such a mechanism. ID with such a mechanism.
This solution works well especially for name information that can be This solution works well for name information that can be looked up
looked up in a directory. It was unclear whether this solution would in a directory. It was unclear whether this solution would allow
allow mechanism-specific name information to be extracted from a mechanism-specific name information to be extracted from a context.
context. If so, then this solution would meet many of the goals of If so, then this solution would meet many of the goals of this
this document. document.
One advantage of this solution is that it requires few if any changes One advantage of this solution is that it requires few, if any,
to GSS-API semantics. It is not as flexible as other solutions. changes to GSS-API semantics. It is not as flexible as other
Also, it is not clear how to handle mechanisms that do not have a solutions. Also, it is not clear how to handle mechanisms that do
well defined name to export with this solution. not have a well-defined name to export with this solution.
7. Selection of Source Identity 7. Selection of Source Identity
Today, applications such as e-mail clients and web browsers require Today, applications such as e-mail clients and Web browsers require
connections to multiple targets. For each target there may be one or connections to multiple targets. For each target, there may be one
more source identities that is appropriate for the connection. 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.
is, by the time credentials are acquired, they must act as if a That is, by the time credentials are acquired, they must act as if a
particular single identity is chosen for each mechanism in the particular single identity is chosen for each mechanism in the
credential. All these identities must correspond to a single credential. All these identities must correspond to a single
mechanism independent 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.
Another possibility can be implemented in GSS-API V2 today. Do not Another possibility can be implemented in GSS-API V2 today: Do not
bind the credentials to a mechanism name until either the credentials bind the credentials to a mechanism name until either the credentials
are queried or they are used to set up a context. This is are queried or they are used to set up a context. This is
undesirable because if an application uses the credential inquiry undesirable because if an application uses the credential inquiry
interface then it will get different behavior than cases where this interface, then it will get different behavior than cases where this
interface is not used. For this reason, the working group favors an interface is not used. For this reason, the working group favors an
extension to GSS-API V3. extension to GSS-API V3.
8. Compatibility with GSS-API V2 8. Compatibility with GSS-API V2
In order to avoid breaking existing applications or mechanisms the In order to avoid breaking existing applications or mechanisms, the
following backward compatibility requirements need to be met: following backward compatibility requirements need to be met:
1. Existing APIs must continue to behave as they do in GSS-API V2. 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; 2. GSS-API V2 mechanisms must produce the same exported name forms;
composite names cannot change the existing exported name forms. composite names cannot change the existing exported name forms.
3. Extensions add new optional behavior. 3. Extensions add new optional behavior.
If GSS-API V3 mechanisms are more permissive than GSS-API V2 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 mechanisms, then care must be taken so that GSS-API V2 applications
not select these mechanisms. do not select these mechanisms.
9. Security Considerations 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
flexibility and feature set for future deployments of GSS-API. flexibility and feature set for future deployments of GSS-API.
This proposal will significantly increase the complexity of the GSS This proposal will significantly increase the complexity of the GSS
naming architecture. As this proposal is fleshed out, we need to naming architecture. As this proposal is fleshed out, we need to
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 can carry their own authentication.
authentication. However the design of any solutions needs to make However, the design of any solutions needs to make sure that
sure that applications can assign appropriate trust to name applications can assign appropriate trust to name components.
components.
10. 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 led 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.
11. 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)", RFC 4120, July 2005.
draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
progress), June 2004.
[4] Jaganathan , K., Zhu, L., Swift, M., and J. Brezak, "Generating [4] Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms",
KDC Referrals to locate Kerberos realms", Work in Progress, June 2006.
draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
2004.
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 [5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", rfc 3280, April 2002. List (CRL) Profile", RFC 3280, April 2002.
[6] Farrell, S. and R. Housley, "An Internet Attribute Certificate [6] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization.", rfc 3281, April 2002. Profile for Authorization", RFC 3281, April 2002.
Author's Address Author's Address
Sam Hartman Sam Hartman
MIT MIT
Email: hartmans@mit.edu EMail: hartmans-ietf@mit.edu
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2006).
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.
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, THE IETF TRUST,
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 17, line 29 skipping to change at page 12, line 46
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Acknowledgement
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 (2006). 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 Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 57 change blocks. 
195 lines changed or deleted 173 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/