draft-ietf-kitten-gss-naming-04.txt   draft-ietf-kitten-gss-naming-05.txt 
Network Working Group S. Hartman Network Working Group S. Hartman
Internet-Draft MIT Internet-Draft MIT
Expires: September 6, 2006 March 5, 2006 Expires: March 4, 2007 August 31, 2006
Desired Enhancements to GSSAPI Version 3 Naming Desired Enhancements to GSSAPI Version 3 Naming
draft-ietf-kitten-gss-naming-04.txt draft-ietf-kitten-gss-naming-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 33 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006. This Internet-Draft will expire on March 4, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The Generic Security Services API (GSS-API) provides a naming The Generic Security Services API (GSS-API) provides a naming
architecture that supports name-based authorization. GSS-API architecture that supports name-based authorization. GSS-API
authenticates two named parties to each other. Names can be stored authenticates two named parties to each other. Names can be stored
skipping to change at page 2, line 16 skipping to change at page 2, line 16
membership or role information as part of authentication. This membership or role information as part of authentication. This
document motivates extensions to GSS-API naming and describes the document motivates extensions to GSS-API naming and describes the
extensions under discussion. extensions under discussion.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Kerberos Naming . . . . . . . . . . . . . . . . . . . . . . . 5 2. Kerberos Naming . . . . . . . . . . . . . . . . . . . . . . . 5
3. X.509 Names . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. X.509 Names . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Composite Names . . . . . . . . . . . . . . . . . . . . . . . 7 4. Composite Names . . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Usage of Name Attributes . . . . . . . . . . . . . . . . . 7 4.1. Usage of Name Attributes . . . . . . . . . . . . . . . . . 7
4.2 Open issues . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Open issues . . . . . . . . . . . . . . . . . . . . . . . 8
4.3 Handling gss_export_name . . . . . . . . . . . . . . . . . 8 4.3. Handling gss_export_name . . . . . . . . . . . . . . . . . 8
5. Credential Extensions . . . . . . . . . . . . . . . . . . . . 10 5. Credential Extensions . . . . . . . . . . . . . . . . . . . . 10
6. Mechanisms for Export Name . . . . . . . . . . . . . . . . . . 11 6. Mechanisms for Export Name . . . . . . . . . . . . . . . . . . 11
7. Selection of Source Identity . . . . . . . . . . . . . . . . . 12 7. Selection of Source Identity . . . . . . . . . . . . . . . . . 12
8. Compatibility with GSS-API V2 . . . . . . . . . . . . . . . . 13 8. Compatibility with GSS-API V2 . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . 15 11. Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 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 flatten 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 another entity 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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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] does not even exported in a GSS-API mechanism. However RFC 3280 [5] allows the
require the subject name to be a non-empty sequence. Instead there subject name to be an empty sequence in end-entity certificates.
are cases where the subjectAltName extension is the only thing to Therefore the subjectAltName extension might be the only portion of
identify the subject of the certificate. As in the case of Kerberos the certificate that identifies the subject. As in the case of
group memberships, there may be many subjectAltName extensions Kerberos group memberships, there may be many subjectAltName
available in a certificate. Different applications will care about extensions available in a certificate. Different applications will
different extensions. One possible candidate for an exported name care about different name forms. One possible candidate for an
would be all the names and SubjectAltName extensions from a exported name would be all the names from the subject field and the
certificate. However as new names are added then existing ACL subjectAltName extension from a certificate. However as new names
entries would be invalidated; this is undesirable. Thus there is no are added then existing ACL entries would be invalidated; this is
single value that can be defined as the exported GSS-API name that undesirable. Thus there is no single value that can be defined as
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 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 7, line 32 skipping to change at page 7, line 32
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 specific names. mechanism-specific naming and group membership can be
be mapped into name attributes by the mechanism implementation. The 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 mechanism-
specific and only be carried by mechanisms that understand the name specific and only be carried by mechanisms that understand the name
attributes and can validate them compromises GSS-API's place as a attributes and can validate them compromises GSS-API's place as a
generic API. Application authors would be forced to understand 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
skipping to change at page 8, line 48 skipping to change at page 8, line 48
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 one- directly useful to an application. So there may not be a good 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
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 depending 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 probably
desirable to allow GSS-API mechanisms for which gss_export_name desirable to allow GSS-API mechanisms for which gss_export_name
cannot meaningfully be defined. The behavior of gss_export_name in cannot meaningfully be defined. The behavior of gss_export_name in
such cases should probably be to return some error. Such mechanisms such cases should probably be to return some error. Such mechanisms
may not work with existing applications and cannot conform to the may not work with existing applications and cannot conform to the
skipping to change at page 11, line 13 skipping to change at page 11, line 13
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 especially for name information that can be
looked up in a directory. It was unclear from the discussion whether looked up in a directory. It was unclear whether this solution would
this solution would allow mechanism-specific name information to be allow mechanism-specific name information to be extracted from a
extracted from a context. If so, then this solution would meet many context. If so, then this solution would meet many of the goals of
of the goals of this document. 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. 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 the there may be connections to multiple targets. For each target there may be one or
one or more source identities that is appropriate for the connection. more source identities that is appropriate for the connection.
Currently each application must choose the source name to use when Currently each application must choose the source name to use when
acquiring credentials or initiating a security context. However the acquiring credentials or initiating a security context. However the
rules that applications use can be generalized to a large extent. rules that applications use can be generalized to a large extent.
GSS-API could simplify application design and implementation by GSS-API could simplify application design and implementation by
taking a larger role in selection of source identity to use when taking a larger role in selection of source identity to use when
connecting to a particular target. connecting to a particular target.
Currently GSS-API credentials represent a single mechanism name. that Currently GSS-API credentials represent a single mechanism name. that
is, by the time credentials are acquired, they must act as if a 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
 End of changes. 16 change blocks. 
40 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/