oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity
Files
26dd1edaa9b7053f647a42d6a66e66e56a57d321
heimdal/doc/standardisation/draft-ietf-kitten-gss-naming-00.txt
Love Hörnquist Åstrand 7419e11eee x 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14364 ec53bebd-3082-4978-b11e-865c3cabbd6b
2004-12-02 19:49:36 +00:00

727 lines
22 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

Network Working Group S. Hartman
Internet-Draft MIT
Expires: May 31, 2005 November 30, 2004
Desired Enhancements to GSSAPI Naming
draft-ietf-kitten-gss-naming-00.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 31, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The Generic Security Services API (GSS-API) provides a naming
architecture that supports name-based authorization. GSS-API
authenticates two named parties to each other. Names can be stored
on access control lists to make authorization decisions. Advances in
security mechanisms and the way implementers wish to use GSS-API
require this model to be extended. Some mechanisms such as
public-key mechanisms do not have a single name to be used across all
environments. Other mechanisms such as Kerberos allow names to
Hartman Expires May 31, 2005 [Page 1]
Internet-Draft GSS Names November 2004
change as people move around organizations. This document proposes
expanding the definition of GSS-API names to deal with these
situations.
Hartman Expires May 31, 2005 [Page 2]
Internet-Draft GSS Names November 2004
1. Introduction
The Generic Security Services API [1] authenticates two named parties
to each other. GSS names can be imported in a variety of formats
through the gss_import_name call. Several mechanism-independent name
formats such as GSS_C_NT_HOSTBASED_SERVICE for services running on an
Internet host and GSS_C_NT_USER_NAME for the names of users. Other
mechanism-specific name types are also provided. By the time a name
is used in acquiring a mechanism-specific credential or establishing
a security context, it has been transformed into one of these
mechanism-specific name types. In addition, the GSS-API provides a
function called gss_export_name that will flatten a GSS-API name into
a binary blob suitable for comparisons. This binary blob can be
stored on ACLs and then authorization decisions can be made simply by
comparing the name 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
over time . If the name contains organizational information such as
a domain part or an indication of what department someone works for,
this changes as the person moves around the organization. Even if no
organizational information is included in the name, the name will
change as people change their names. Updating ACLs to reflect name
changes is difficult.
Also, as GSS-API is used in more complex environments, there is a
desire to use attribute certificates [5], Kerberos authorization data
[2], or other non-name-based authorization models. GSS-API needs to
be enhanced in order to support these uses in a mechanism-independent
manner.
This draft discusses two different cases where the current GSS-API
naming seems inadequate. Two proposals that have been discussed
within the IETF Kitten community are discussed. Finally, the
problems that need to be resolved to adopt either of these proposals
are discussed.
Hartman Expires May 31, 2005 [Page 3]
Internet-Draft GSS Names November 2004
2. Kerberos Naming
The Kerberos Referrals draft [3] proposes a new type of Kerberos name
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.
The Kerberos KDC translates this name into a normal Kerberos
principal and gives the user tickets for this principal. This normal
principal is used for authorization. The intent is that the
enterprise name tracks the user as they move throughout the
organization, even if they move to parts of the organization that
have different naming policies. The name they type at login remains
constant, but the Kerberos principal used to authenticate them to
services changes.
Performing a mapping from enterprise name to principal name is not
generally possible for unauthenticated services. So in order to
canonicalize an enterprise name to get a principal, a service must
have credentials. However it may not be desirable to allow services
to map enterprise names to principal names in the general case.
Also, Kerberos does not (and does not plan to) provide a mechanism
for mapping enterprise names to principals besides authentication as
the enterprise name. Thus, any such mapping would be
vendor-specific. With this feature in Kerberos, it is not possible
to implement gss_canonicalize_name for enterprise name types.
Another issue arises with enterprise names. IN some cases it would
be desirable to put the enterprise name on the ACL instead of a
principal name. Thus, it would be desirable to include the
enterprise name in the name exported by gss_export_name.
Unfortunately, if this were done, the exported name would change
whenever the mapping changed, invalidating any ACL entries based off
the old exported name and defeating the purpose of including the
enterprise name. In some cases it would be desirable to have the
exported name be based on the 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.
Several vendors have been looking at mechanisms to include group
membership information in Kerberos authorization data. It is
desirable to put these group names on ACLs. Again, GSS-API currently
has no mechanism to use this information.
Hartman Expires May 31, 2005 [Page 4]
Internet-Draft GSS Names November 2004
3. X.509 Names
X.509 names are at least as complex as Kerberos names. It seems the
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
require the subject name to be a non-empty sequence. Instead there
are cases where the subjectAltName extension is the only thing to
identify the subject of the certificate. As in the case of Kerberos
group memberships, there may be many subjectAltName extensions
available in a certificate. Different applications will care about
different extensions. 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
specific name be used. However this would limit that mechanism to
require a particular type of certificate. There is interest in being
able to use arbitrary X.509 certificates with GSS-API for some
applications.
Hartman Expires May 31, 2005 [Page 5]
Internet-Draft GSS Names November 2004
4. Composite Names
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
would be an octet-string labeled by an OID. Examples of attributes
would include Kerberos enterprise names, group memberships in an
authorization infrastructure, Kerberos authorization data attributes
and subjectAltName attributes in a certificate. Several new
operations would be needed:
1. Add attribute to name
2. Query attributes of name
3. Query values of an attribute
4. Delete an attribute from a name
4.1 Usage of Name Attributes
Since attributes are part of GSS-API names, the acceptor can retrieve
the attributes of the initiator's name from the context. These
attributes can then be used for authorization.
Most name attributes will probably not come from explicit operations
to add attributes to a name. Instead, name attributes will probably
come from mechanism specific credentials. Mechanism specific naming
and group 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
comparison. This should enable applications to use these name
attributes on ACLs the same way exported names are now used on ACLs.
For example if a particular Subjectaltname extension contains the
appropriate identity for an application, then the name attribute
for this Subjectaltname can be placed on the ACL. This is only true
if the name attribute is stored in some canonical form.
4.2 Open issues
This section describes parts of the proposal to add attributes to
names that will need to be explored before the proposal can become a
protocol specification.
Are mechanisms expected to be able to carry arbitrary name attributes
as part of a context establishment? At first it seems like this
would be desirable. However the purpose of GSS-API is to establish
an authenticated context between two peers. In particular, a context
authenticates two named entities to each other. The names of these
entities and attributes associated with these names will be used for
authorization decisions. If an initiator or acceptor is allowed to
Hartman Expires May 31, 2005 [Page 6]
Internet-Draft GSS Names November 2004
assert name attributes and the authenticity of these assertions is
not validated by the mechanisms, then security problems will result.
On the other hand, requiring that name attributes be mechanism
specific and only be carried by mechanisms that understand the name
attributes and can validate them compromises GSS-API's place as a
generic API. Application authors would be forced to understand
mechanism-specific attributes to make authorization decisions. In
addition if mechanisms are not required to transport arbitrary
attributes, then application authors will need to deal with different
implementations of the same mechanism that support different sets of
name attributes. One possible solution is to carry a source along
with each name attribute; this source could indicate whether the
attribute comes from a mechanism data structure or from the other
party in the authentication.
Another related question is how will name attributes be mapped into
their mechanism-specific forms. For example it would be desirable to
map many Kerberos authorization data elements into name attributes.
In the case of the Microsoft PAC, it would be desirable for some
applications to get the entire PAC. However in many cases, the
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-to-one mapping between 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
attributes compare? What is the effect of a name attribute on a
target name in gss_accept_sec_context?
4.3 Handling gss_export_name
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
Kerberos, the principal name can continue to be used as the exported
name. This will allow applications depending on existing GSS-API
name-based authorization to continue to work. However it is probably
desirable to allow GSS-API mechanisms for which gss_export_name
cannot meaningfully be defined. The behavior of gss_export_name in
such cases should probably be to return some error. Such mechanisms
may not work with existing applications and cannot conform to the
current version of the GSS-API.
Hartman Expires May 31, 2005 [Page 7]
Internet-Draft GSS Names November 2004
5. Credential Extensions
An alternative to the name attributes proposal is to extend GSS-API
credentials with extensions labeled by OIDs. Interfaces would be
needed to manipulate these credential extensions and to retrieve the
credential extensions for credentials used to establish a context.
Even if name attributes are used, credential extensions may be useful
for other unrelated purposes.
It is possible to solve problems discussed in this document using
some credential extension mechanism. Doing so will have many of the
same open issues as discussed in the composite names proposal. The
main advantage of a credential extensions proposal is that it avoids
specifying how name attributes interact with name comparison or
target names.
The primary advantage of the name attributes proposal over credential
extensions is that name attributes seem to fit better into the
GSS-API authorization model. Names are already available at all
points when authorization decisions are made. In addition, for many
mechanisms the sort of information carried as name attributes will
also be carried as part of the name in the mechanism
Hartman Expires May 31, 2005 [Page 8]
Internet-Draft GSS Names November 2004
6. Mechanisms for Export Name
Another proposal is to define some GSS-API mechanisms whose only
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
ID with such a mechanism.
This solution works well especially for name information that can be
looked up in a directory. It was unclear from the p discussion
whether this solution would allow mechanism-specific name information
to be extracted from a context. If so, then this solution would meet
many of the goals of this document.
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.
Also, it is not clear how to handle mechanisms that do not have a
well defined name to export with this solution.
Hartman Expires May 31, 2005 [Page 9]
Internet-Draft GSS Names November 2004
7. Deferring Credential Binding
Currently GSS-API credentials represent a single mechanism name.
While working on other issues discussion focused around choosing the
correct credential for a particular target. There are several
situations where an implementation can do a better job of choosing a
default source name to use given the name of the target to connect
to. Currently, GSS-API does not provide a mechanism to do this.
Adding such a mechanism would be desirable.
Hartman Expires May 31, 2005 [Page 10]
Internet-Draft GSS Names November 2004
8. Security Considerations
GSS-API sets up a security context between two named parties. The
GSS-API names are security assertions that are authenticated by the
context establishment process. As such the GSS naming architecture
is critical to the security of GSS-API.
Currently GSS-API uses a simplistic naming model for authorization.
Names can be compared against a set of names on an access control
list. This architecture is relatively simple and its security
properties are well understood. However it does not provide the
flexibility and feature set for future deployments of GSS-API.
This proposal will significantly increase the complexity of the GSS
naming architecture. As this proposal is fleshed out, we need to
consider ways of managing security exposures created by this
increased complexity.
Hartman Expires May 31, 2005 [Page 11]
Internet-Draft GSS Names November 2004
9. Acknowledgements
John Brezak, Paul Leach and Nicolas Williams all participated in
discussions that lead to a desire to enhance GSS naming. Martin Rex
provided descriptions of the current naming architecture and pointed
out many ways in which proposed enhancements would create
interoperability problems or increase complexity. Martin also
provided excellent information on what aspects of GSS naming have
tended to be implemented badly or have not met the needs of some
customers.
Nicolas Williams helped describe the possible approaches for
enhancing naming.
10 Informative References
[1] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[2] Neuman, C., Yu, T., Hartman, S. and K. Raeburn, "The Kerberos
Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications-06.txt (work in
progress), June 2004.
[3] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
KDC Referrals to locate Kerberos realms",
draft-ietf-krb-wg-kerberos-referrals-03.txt (work in progress),
2004.
[4] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", rfc 3280, April 2002.
[5] Farrell, S. and R. Housley, "An Internet Attribute Certificate
Profile for Authorization.", rfc 3281, April 2002.
Author's Address
Sam Hartman
MIT
EMail: hartmans@mit.edu
Hartman Expires May 31, 2005 [Page 12]
Internet-Draft GSS Names November 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
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 (2004). 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
Internet Society.
Hartman Expires May 31, 2005 [Page 13]
Reference in New Issue View Git Blame Copy Permalink