draft-hartman-gss-naming-00.txt [plain text]
Network Working Group S. Hartman
Internet-Draft MIT
Expires: January 10, 2005 July 12, 2004
GSSAPI Mechanisms without a Single Canonical Name
draft-hartman-gss-naming-00.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Generic Security Services API (GSSAPI) uses name-based
authorization. GSSAPI authenticates two named parties to each other.
Names can be stored on access control lists to make authorization
decisions. Advances in security mechanisms require this model to be
extended. Some mechanisms such as public-key mechanisms do not have
a single name to be used. Other mechanisms such as Kerberos allow
names to change as people move around organizations. This document
proposes expanding the definition of GSSAPI names to deal with these
situations.
Hartman Expires January 10, 2005 [Page 1]
Internet-Draft GSS Name Attributes July 2004
1. Introduction
The Generic Security Services API [1] provides a function called
gss_export_name that will flatten a GSSAPI 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.
As a side effect of this name-based authorization model, each
mechanism name needs to be able to be represented in a single
canonical form and anyone importing that name needs to be able to
retrieve the canonical form.
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. In addition, there is a desire to
have more complex authorization models in GSSAPI than the current
name based authorization model.
This draft discusses two different cases where the current GSSAPI
naming seems inadequate. Then, an extension to GSSAPI naming to meet
these concerns is sketched.
Hartman Expires January 10, 2005 [Page 2]
Internet-Draft GSS Name Attributes July 2004
2. Kerberos Naming
The Kerberos Referals draft [2] 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. So 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. However
then the exported name would change whenever the mapping changed,
defeating the purpose of including the enterprise name. So 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 currently possible.
Another development also complicates GSSAPI naming for Kerberos.
Several vendors have been looking at mechanisms to include group
membership information in Kerberos authorization data. Then it is
desirable to put these group names on ACLs. Again, GSSAPI currently
has no mechanism to use this information.
Hartman Expires January 10, 2005 [Page 3]
Internet-Draft GSS Name Attributes July 2004
3. X.509 Names
X.509 names are at least as complex as Kerberos names. It seems like
you might want to use the subject name as the name to be exported in
a GSSAPI mechanism. However RFC 3280 [3] 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 GSSAPI name that will be generally useful.
Hartman Expires January 10, 2005 [Page 4]
Internet-Draft GSS Name Attributes July 2004
4. Composite Names
I propose extending the concept of a GSSAPI name to include a
collection of 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 GSSAPI 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 general require protocol specification for each mechanism.
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 point of GSSAPI 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
assert name attributes and the authenticity of these assertions is
not validated by the mechanisms, then security problems may 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 GSSAPI'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
Hartman Expires January 10, 2005 [Page 5]
Internet-Draft GSS Name Attributes July 2004
attributes, then application authors will need to deal with different
implementations of the same mechanism that support different sets of
name attributes.
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.
For example 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 GSSAPI 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 Name Attributes Instead of Credential Extensions
An alternative to this proposal is to extend GSSAPI 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 this name attributes 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 GSSAPI
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 January 10, 2005 [Page 6]
Internet-Draft GSS Name Attributes July 2004
5. 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 GSSAPI
name-based authorization to continue to work. However it is probably
desirable to allow GSSAPI 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 GSSAPI.
Hartman Expires January 10, 2005 [Page 7]
Internet-Draft GSS Name Attributes July 2004
6. Security Considerations
GSSAPI sets up a security context between two named parties. The
GSSAPI names are security assertions that are authenticated by the
context establishment process. As such the GSS naming architecture
is critical to the security of GSSAPI.
Currently GSSAPI 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 GSSAPI.
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 January 10, 2005 [Page 8]
Internet-Draft GSS Name Attributes July 2004
7. Acknowledgements
John Brezak, Paul Leach and Nicolas Williams all participated in
discussions that defined the problem this proposal attempts to solve.
Nicolas Williams and I discussed details of proposals to solve this
problem. However the details and open issues presented here have
only been reviewed by me and so I am responsible for their errors.
8 Informative References
[1] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000.
[2] Jaganathan , K., Zhu, L., Swift, M. and J. Brezak, "Generating
KDC Referrals to locate Kerberos realms",
draft-ietf-krb-wg-kerberos-referals-03.txt (work in progress),
2004.
[3] 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.
Author's Address
Sam Hartman
MIT
EMail: hartmans@mit.edu
Hartman Expires January 10, 2005 [Page 9]
Internet-Draft GSS Name Attributes July 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 IETF's procedures with respect to rights in IETF 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 January 10, 2005 [Page 10]