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]