From a3f06cb5e10ae284024968e4199f376dae2bf7b7 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Thu, 24 Feb 2005 09:28:55 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@14595 ec53bebd-3082-4978-b11e-865c3cabbd6b --- .../draft-ietf-kitten-gss-naming-01.txt | 727 ++++++++++++++++++ 1 file changed, 727 insertions(+) create mode 100644 doc/standardisation/draft-ietf-kitten-gss-naming-01.txt diff --git a/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt b/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt new file mode 100644 index 000000000..51771e593 --- /dev/null +++ b/doc/standardisation/draft-ietf-kitten-gss-naming-01.txt @@ -0,0 +1,727 @@ +Network Working Group S. Hartman +Internet-Draft MIT +Expires: August 21, 2005 February 20, 2005 + + + Desired Enhancements to GSSAPI Naming + draft-ietf-kitten-gss-naming-01.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 August 21, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +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. As people move within an + organization or change their names, the name authenticated by GSS-API + may change. Using some sort of constant identifier would make ACLs + + + +Hartman Expires August 21, 2005 [Page 1] + +Internet-Draft GSS Names February 2005 + + + more stable. Some mechanisms such as public-key mechanisms do not + have a single name to be used across all environments. Other + mechanisms such as Kerberos include may include group membership or + role information as part of authentication. This document motivates + extensions to GSS-API naming and describes the extensions under + discussion. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires August 21, 2005 [Page 2] + +Internet-Draft GSS Names February 2005 + + +1. Introduction + + The Generic Security Services API [2] 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 are provided including 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. + + 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. + + 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 + 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. + + Also, as GSS-API is used in more complex environments, there is a + desire to use attribute certificates [6], Kerberos authorization data + [3], 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 document discusses the particular naming problems with two + important classes of GSS-API mechanisms. It also discusses the set + of proposed solutions and open issues with these solutions. This + draft limits discussion to these solutions and provides a description + of the problem against which the solutions can be judged. + + + + + +Hartman Expires August 21, 2005 [Page 3] + +Internet-Draft GSS Names February 2005 + + +2. Kerberos Naming + + The Kerberos mechanism demonstrates both the naming stability problem + and the authorization extension problem. + + The Kerberos Referrals draft [4] 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. Even authenticated + services may not be authorized to perform this mapping except for + their own name. 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 for greater ACL stability. At first glance this could + be accomplished by including 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 the exported 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 August 21, 2005 [Page 4] + +Internet-Draft GSS Names February 2005 + + +3. X.509 Names + + X.509 names are more complicated than Kerberos names. In the + Kerberos case there is a single principal carried in all Kerberos + messages. X.509 certificates have multiple options. 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 [5] 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. + + Experience so far has not lead to sufficient interoperability with + 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 + said that he was aware of several SPKM [1] implementations but no two + were fully interoperable on names. + + Also, as discussed in the introduction, it is desirable to support + X.509 attribute certificates. + + + + + + + + + + + + + + + + + + + + + +Hartman Expires August 21, 2005 [Page 5] + +Internet-Draft GSS Names February 2005 + + +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 an attribute to name. + 2. Query attributes of name. + 3. Query values of an attribute. + 4. Delete an attribute from a name. + 5. Export a complete composite name and all its attributes for + transport between processes. + + Note that an exported composite name would not be suitable for binary + comparison. Avoiding confusion between this operation and the + existing gss_export_name operation will require careful work. + +4.1 Usage of Name Attributes + + Since attributes are part of GSS-API names, the acceptor can retrieve + the attributes of the initiator's and acceptor'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. Components of these + mechanism specific credentials may come from platform or + environment-specific names. 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. + + + +Hartman Expires August 21, 2005 [Page 6] + +Internet-Draft GSS Names February 2005 + + + 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 + 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 August 21, 2005 [Page 7] + +Internet-Draft GSS Names February 2005 + + +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 August 21, 2005 [Page 8] + +Internet-Draft GSS Names February 2005 + + +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 August 21, 2005 [Page 9] + +Internet-Draft GSS Names February 2005 + + +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 August 21, 2005 [Page 10] + +Internet-Draft GSS Names February 2005 + + +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. + + One area where the complexity may lead to security problems is + composite names with attributes from different sources. This may be + desirable so that name attributes that carry their own + authentication. However the design of any solutions needs to make + sure that applications can assign appropriate trust to name + components. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hartman Expires August 21, 2005 [Page 11] + +Internet-Draft GSS Names February 2005 + + +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] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", rfc + 2025, October 1996. + + [2] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [3] 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. + + [4] 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. + + [5] 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. + + [6] 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 August 21, 2005 [Page 12] + +Internet-Draft GSS Names February 2005 + + +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 (2005). 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 August 21, 2005 [Page 13] + +