draft-ietf-kitten-gss-naming-01.txt   draft-ietf-kitten-gss-naming-02.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft MIT Internet-Draft MIT
Expires: August 21, 2005 February 20, 2005 Expires: December 4, 2005 June 2, 2005
Desired Enhancements to GSSAPI Naming Desired Enhancements to GSSAPI Naming
draft-ietf-kitten-gss-naming-01.txt draft-ietf-kitten-gss-naming-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 21, 2005. This Internet-Draft will expire on December 4, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
discussion. discussion.
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 provided. By the time a name is used in acquiring a mechanism-
mechanism-specific credential or establishing a security context, it specific credential or establishing a security context, it has been
has been transformed into one of these mechanism-specific name types. transformed into one of these mechanism-specific name types. In
In addition, the GSS-API provides a function called gss_export_name addition, the GSS-API provides a function called gss_export_name that
that will flatten a GSS-API name into a binary blob suitable for will flatten 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. changes is difficult. Another significant problem is that names can
be reused to apply to another entity than the entity to which they
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,
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.
skipping to change at page 5, line 17 skipping to change at page 6, line 17
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] 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. One possible candidate for an exported name
defined as the exported GSS-API name that will be useful in all would be all the names and SubjectAltName extensions from a
environments. certificate. However as new names are added then existing ACL
entries would be invalidated; this is undesirable. Thus there is no
single value that can be defined as 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 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 Experience so far has not lead 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
skipping to change at page 6, line 14 skipping to change at page 7, line 14
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 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 be suitable for binary Note that an exported composite name would not generally be suitable
comparison. Avoiding confusion between this operation and the for binary comparison. Avoiding confusion between this operation and
existing gss_export_name operation will require careful work. the existing gss_export_name operation will require careful work.
Additional utility operations will probably be needed depending on
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 mechanism specific credentials may come from platform or environment-
environment-specific names. Mechanism specific naming and group specific names. Mechanism specific naming and group membership can
membership can be mapped into name attributes by the mechanism be mapped into name attributes by the mechanism implementation. The
implementation. The specific form of this mapping will generally specific form of this mapping will generally require protocol
require protocol specification for each mechanism. 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 7, line 33 skipping to change at page 8, line 41
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 will name attributes be mapped into
their mechanism-specific forms. For example it would be desirable to their mechanism-specific forms. For example it would be desirable to
map many Kerberos authorization data elements into name attributes. map many Kerberos authorization data elements into name attributes.
In the case of the Microsoft PAC, it would be desirable for some In the case of the Microsoft PAC, it would be desirable for some
applications to get the entire PAC. However in many cases, the applications to get the entire PAC. However in many cases, the
specific lists of security IDs contained in the PAC would be more specific lists of security IDs contained in the PAC would be more
directly useful to an application. So there may not be a good directly useful to an application. So there may not be a good one-
one-to-one mapping between the mechanism-specific elements and the to-one mapping between the mechanism-specific elements and the
representation desirable at the GSS-API layer. 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
skipping to change at page 8, line 22 skipping to change at page 10, line 22
for other unrelated purposes. for other unrelated purposes.
It is possible to solve problems discussed in this document using It is possible to solve problems discussed in this document using
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 extensions is that name attributes seem to fit better into the GSS-
GSS-API authorization model. Names are already available at all API authorization model. Names are already available at all points
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.
skipping to change at page 10, line 8 skipping to change at page 12, line 8
many of the goals of this document. many of the goals of this 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 changes
to GSS-API semantics. It is not as flexible as other solutions. to GSS-API semantics. It is not as flexible as other solutions.
Also, it is not clear how to handle mechanisms that do not have a Also, it is not clear how to handle mechanisms that do not have a
well defined name to export with this solution. well defined name to export with this solution.
7. Deferring Credential Binding 7. Deferring Credential Binding
Currently GSS-API credentials represent a single mechanism name. Currently GSS-API credentials represent a single mechanism name.
While working on other issues discussion focused around choosing the While working on other issues discussion came up focused around
correct credential for a particular target. There are several choosing the correct credential for a particular target. There are
situations where an implementation can do a better job of choosing a several situations where an implementation can do a better job of
default source name to use given the name of the target to connect choosing a default source name to use given the name of the target to
to. Currently, GSS-API does not provide a mechanism to do this. connect to. Currently, GSS-API does not provide a mechanism to do
Adding such a mechanism would be desirable. this. Adding such a mechanism would be desirable.
8. Security Considerations 8. 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
skipping to change at page 12, line 19 skipping to change at page 14, line 19
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] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", rfc [1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)",
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
progress), June 2004. progress), June 2004.
[4] 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.
[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@mit.edu
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 

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