draft-ietf-kitten-gss-naming-00.txt   draft-ietf-kitten-gss-naming-01.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft MIT Internet-Draft MIT
Expires: May 31, 2005 November 30, 2004 Expires: August 21, 2005 February 20, 2005
Desired Enhancements to GSSAPI Naming Desired Enhancements to GSSAPI Naming
draft-ietf-kitten-gss-naming-00.txt draft-ietf-kitten-gss-naming-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of 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 is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 May 31, 2005. This Internet-Draft will expire on August 21, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). Copyright (C) The Internet Society (2005).
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. Some mechanisms such as require this model to be extended. As people move within an
public-key mechanisms do not have a single name to be used across all organization or change their names, the name authenticated by GSS-API
environments. Other mechanisms such as Kerberos allow names to may change. Using some sort of constant identifier would make ACLs
change as people move around organizations. This document proposes more stable. Some mechanisms such as public-key mechanisms do not
expanding the definition of GSS-API names to deal with these have a single name to be used across all environments. Other
situations. mechanisms such as Kerberos include may include group membership or
role information as part of authentication. This document motivates
extensions to GSS-API naming and describes the extensions under
discussion.
1. Introduction 1. Introduction
The Generic Security Services API [1] 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 such as GSS_C_NT_HOSTBASED_SERVICE for services running on an formats are provided including GSS_C_NT_HOSTBASED_SERVICE for
Internet host and GSS_C_NT_USER_NAME for the names of users. Other services running on an Internet host and GSS_C_NT_USER_NAME for the
mechanism-specific name types are also provided. By the time a name names of users. Other mechanism-specific name types are also
is used in acquiring a mechanism-specific credential or establishing provided. By the time a name is used in acquiring a
a security context, it has been transformed into one of these mechanism-specific credential or establishing a security context, it
mechanism-specific name types. In addition, the GSS-API provides a has been transformed into one of these mechanism-specific name types.
function called gss_export_name that will flatten a GSS-API name into In addition, the GSS-API provides a function called gss_export_name
a binary blob suitable for comparisons. This binary blob can be that will flatten a GSS-API name into a binary blob suitable for
stored on ACLs and then authorization decisions can be made simply by comparisons. This binary blob can be stored on ACLs and then
comparing the name exported from a newly accepted context to the name authorization decisions can be made simply by comparing the name
on the ACL. exported from a newly accepted context to the name on the ACL.
Inherent in this model is the idea that mechanism names 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 of that
name.
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.
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. changes is difficult.
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
importing that name needs to be able to retrieve the canonical form
of that name.
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.
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 [5], Kerberos authorization data desire to use attribute certificates [6], Kerberos authorization data
[2], 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 draft discusses two different cases where the current GSS-API This document discusses the particular naming problems with two
naming seems inadequate. Two proposals that have been discussed important classes of GSS-API mechanisms. It also discusses the set
within the IETF Kitten community are discussed. Finally, the of proposed solutions and open issues with these solutions. This
problems that need to be resolved to adopt either of these proposals draft limits discussion to these solutions and provides a description
are discussed. of the problem against which the solutions can be judged.
2. Kerberos Naming 2. Kerberos Naming
The Kerberos Referrals draft [3] proposes a new type of Kerberos name The Kerberos mechanism demonstrates both the naming stability problem
and the authorization extension problem.
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 Performing a mapping from enterprise name to principal name is not
generally possible for unauthenticated services. So in order to generally possible for unauthenticated services. Even authenticated
canonicalize an enterprise name to get a principal, a service must services may not be authorized to perform this mapping except for
have credentials. However it may not be desirable to allow services their own name. Also, Kerberos does not (and does not plan to)
to map enterprise names to principal names in the general case. provide a mechanism for mapping enterprise names to principals
Also, Kerberos does not (and does not plan to) provide a mechanism besides authentication as the enterprise name. Thus, any such
for mapping enterprise names to principals besides authentication as mapping would be vendor-specific. With this feature in Kerberos, it
the enterprise name. Thus, any such mapping would be is not possible to implement gss_canonicalize_name for enterprise
vendor-specific. With this feature in Kerberos, it is not possible name types.
to implement gss_canonicalize_name for enterprise name types.
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. Thus, it would be desirable to include the principal name for greater ACL stability. At first glance this could
enterprise name in the name exported by gss_export_name. be accomplished by including the enterprise name in the name exported
Unfortunately, if this were done, the exported name would change by gss_export_name. Unfortunately, if this were done, the exported
whenever the mapping changed, invalidating any ACL entries based off name would change whenever the mapping changed, invalidating any ACL
the old exported name and defeating the purpose of including the entries based off the old exported name and defeating the purpose of
enterprise name. In some cases it would be desirable to have the including the enterprise name in the exported name. In some cases it
exported name be based on the enterprise name and in others based on would be desirable to have the exported name be based on the
the principal name, but this is not permitted by the current GSS-API. enterprise name and in others based on the principal name, 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 at least as complex as Kerberos names. It seems the X.509 names are more complicated than Kerberos names. In the
Kerberos case there is a single principal carried in all Kerberos
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 [4] does not even exported in a GSS-API mechanism. However RFC 3280 [5] does not even
require the subject name to be a non-empty sequence. Instead there require the subject name to be a non-empty sequence. Instead there
are cases where the subjectAltName extension is the only thing to are cases where the subjectAltName extension is the only thing to
identify the subject of the certificate. As in the case of Kerberos identify the subject of the certificate. As in the case of Kerberos
group memberships, there may be many subjectAltName extensions group memberships, there may be many subjectAltName extensions
available in a certificate. Different applications will care about available in a certificate. Different applications will care about
different extensions. Thus there is no single value that can be different extensions. Thus there is no single value that can be
defined as the exported GSS-API name that will be useful in all defined as the exported GSS-API name that will be useful in all
environments. 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 a
specific name be used. However this would limit that mechanism to 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
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
said that he was aware of several SPKM [1] implementations but no two
were fully interoperable on names.
Also, as discussed in the introduction, it is desirable to support
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, Kerberos authorization data attributes
and subjectAltName attributes in a certificate. Several new and subjectAltName attributes in a certificate. Several new
operations would be needed: operations would be needed:
1. Add 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
transport between processes.
Note that an exported composite name would not be suitable for binary
comparison. Avoiding confusion between this operation and the
existing gss_export_name operation will require careful work.
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 name from the context. These the attributes of the initiator's and acceptor's name from the
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. Mechanism specific naming come from mechanism specific credentials. Components of these
and group membership can be mapped into name attributes by the mechanism specific credentials may come from platform or
mechanism implementation. The specific form of this mapping will environment-specific names. Mechanism specific naming and group
generally require protocol specification for each mechanism. membership can be mapped into name attributes by the mechanism
implementation. The specific form of this mapping will generally
require protocol specification for each mechanism.
The value of many name attributes may be suitable for use in binary The value of many name attributes may be suitable for use in binary
comparison. This should enable applications to use these name comparison. This should enable applications to use these name
attributes on ACLs the same way exported names are now used on ACLs. attributes on ACLs the same way exported names are now used on ACLs.
For example if a particular Subjectaltname extension contains the For example if a particular Subjectaltname extension contains the
appropriate identity for an application, then the name attribute appropriate identity for an application, then the name attribute
for this Subjectaltname can be placed on the ACL. This is only true for this Subjectaltname can be placed on the ACL. This is only true
if the name attribute is stored in some canonical form. if the name attribute is stored in some canonical form.
4.2 Open issues 4.2 Open issues
skipping to change at page 12, line 5 skipping to change at page 11, line 23
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
composite names with attributes from different sources. This may be
desirable so that name attributes that carry their own
authentication. However the design of any solutions needs to make
sure that applications can assign appropriate trust to name
components.
9. Acknowledgements 9. 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 10 Informative References
[1] Linn, J., "Generic Security Service Application Program [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", rfc
2025, October 1996.
[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.
[2] 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
progress), June 2004. progress), June 2004.
[3] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating [4] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
KDC Referrals to locate Kerberos realms", KDC Referrals to locate Kerberos realms",
draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress), draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
2004. 2004.
[4] 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.
[5] 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@mit.edu
Intellectual Property Statement Intellectual Property Statement
skipping to change at page 13, line 41 skipping to change at page 13, 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 (2004). This document is subject Copyright (C) The Internet Society (2005). 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. 

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