aboutsummaryrefslogtreecommitdiff
path: root/doc/standardisation/draft-hartman-gss-naming-00.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/standardisation/draft-hartman-gss-naming-00.txt')
-rw-r--r--doc/standardisation/draft-hartman-gss-naming-00.txt561
1 files changed, 561 insertions, 0 deletions
diff --git a/doc/standardisation/draft-hartman-gss-naming-00.txt b/doc/standardisation/draft-hartman-gss-naming-00.txt
new file mode 100644
index 000000000000..9141e339dfbf
--- /dev/null
+++ b/doc/standardisation/draft-hartman-gss-naming-00.txt
@@ -0,0 +1,561 @@
+
+
+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]
+
+
generated by cgit v1.2.3 (git 2.25.1) at 2025-10-13 12:07:16 +0000