Network Working Group M. StJohns Internet-Draft Network Associates Labs Expires: March 26, 2003 September 25, 2002 The PKIX UserGroupName GeneralName Type draft-ietf-pkix-usergroup-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 March 26, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract A number of systems which understand X.509 client certificates have developed various ad hoc mechanisms to map a certificate to a 'userid'/'group(s)' value which can then be used for access control. The mechanisms include idiosyncratic name forms for the SubjectName field such as encoding the userid as a CommonName and the group as an OrganizationalUnit, or mapping the certificate against an entry in a directory system. This document describes an otherName extension of the GeneralName type which can be used in the SubjectAltName extension or IssuerAltName extension to directly encode userid and group information. Conformance StJohns Expires March 26, 2003 [Page 1] Internet-Draft PKIX UserGroupName September 2002 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Use Within a Leaf (End User) Certificate . . . . . . . . . . . 4 3.2 Use Within an Intermediate (CA) Certificate . . . . . . . . . 5 4. Path Validation Considerations . . . . . . . . . . . . . . . . 5 4.1 Trust Mappings . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2 Domain Matching . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Multiple UserGroupNames . . . . . . . . . . . . . . . . . . . 7 5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1 Web Server with Client Certificates . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 7. Design Discussion . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Attribute Certificate . . . . . . . . . . . . . . . . . . . . 10 7.2 Certificate Extension . . . . . . . . . . . . . . . . . . . . 10 7.3 otherName GeneralName type . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 A. ASN.1 Definitions . . . . . . . . . . . . . . . . . . . . . . 11 A.1 1988 Module . . . . . . . . . . . . . . . . . . . . . . . . . 11 A.2 Notional ASN.1 Encoding . . . . . . . . . . . . . . . . . . . 13 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 14 StJohns Expires March 26, 2003 [Page 2] Internet-Draft PKIX UserGroupName September 2002 1. Introduction This document defines a proposed extension of the acceptable otherName instantiations of the GeneralName type within the Subject and IssuerAltName extensions described in [RFC3280]. It is applicable to the X.509 Public Key Infrastructure for the Internet family of standards. The definitions described herein extend and depend on those described in RFC 3280 which, in turn, defines the underlying certificate formats needed for a full implementation of this otherName definition. This document describes a method of encoding Unix-style userid and group information directly within an X.509 certificate. Currently, a number of systems (e.g. web servers which accept or depend upon SSL/ TLS [RFC2246] client certificate authentication) use ad hoc methods for either mapping from or encoding names within the X.509 SubjectName RDN (Relative Distinguished Name). For example, one system uses a CommonName element within the SubjectName to represent a userid and an OrganizationalUnit element to represent one or more groups. Another system stores a mapping from a particular certificate to a set of userid and group information within an LDAP database. Neither of the above approaches are standardized, nor are they substantially interoperable across many systems. The approach described in this document does not necessarily enable any additional functionality over that available in existing systems. However, it does standardize and specify a single common encoding for userid and group names and this appears to be a useful goal. Code and products which work across a broad spectrum of applications can be designed once a standard semantic and syntactic definition exists. 2. Definition This name is defined as a form of otherName from the GeneralName structure in SubjectAltName. The basic definition of the UserGroupName type is: id-on-userGroup AttributeType ::= { id-on 2 } UserGroupName ::= SEQUENCE { domain UTF8String, user UTF8String, groups SEQUENCE OF UTF8String OPTIONAL } The UserGroupName otherName consists of three fields: o The domain field indicates the domain under which the other fields StJohns Expires March 26, 2003 [Page 3] Internet-Draft PKIX UserGroupName September 2002 are evaluated. Although it is encoded as a UTF8String to permit future expansion, by convention this SHOULD be specified as a valid, '.' (dot) separated tokens, domain name system (DNS) style domain name. The domain is used to differentiate userids on various systems and within various organizations. For example, 'smith' on the host yoohoo.entera.com might be different than 'smith' on the host (or within the domain) bigbank.org. See Section 4 below for more information on the treatment of the domain field. o The user field encodes the userid represented by this certificate within the domain specified. In general, this SHOULD be in the subset of UTF8 common to the target domain. o The groups field is optional and encodes the groups the holder of this certificate is permitted access to within the specified domain. As above, this SHOULD be in the subset of UTF8 common to the target domain. 3. Usage 3.1 Use Within a Leaf (End User) Certificate For an end user certificate (i.e. a client certificate), the UserGroupName element is encoded within a SubjectAltName extension (SANE). The SANE SHOULD be marked as critical, and MUST be marked as critical if the SubjectName field is empty. The UserGroupName represents an identity for the certificate. In general, there SHOULD NOT be any other non-UserGroupName names within the SANE and the SubjectName field SHOULD be empty. If a leaf certificate with both a SubjectName and a UserGroupName OtherName SANE is presented, the certificate SHOULD be considered invalid for the purposes of determining a userid or group mapping. NOTE: Multiple UserGroupName elements are permitted with the SANE of a leaf certificate. Each is valid as an identity if and only if the acceptor can establish that the client certificate chains back to a CA certificate with a trust relationship for the domain indicated in that UserGroupName element. For any given acceptor context where the client certificate has multiple UserGroupNames, some of the UserGroupNames may be valid and some may not. The selection of which of a number of valid UserGroupName elements is accepted by the server or other acceptor is an implementation decision. Possibilities include accepting the userid with the most access, with the least access, prioritizing it based on an ordered StJohns Expires March 26, 2003 [Page 4] Internet-Draft PKIX UserGroupName September 2002 list of domains or only accepting a specific single domain. 3.2 Use Within an Intermediate (CA) Certificate For a CA certificate, one or more UserGroupName otherNames MAY be included within a SANE. The SANE MUST be marked as critical in that event. The inclusion of the UserGroupName element acts to restrict the set of groups which this CA (and its subsidiary CA's) may certify. The userid field MAY be non-empty, but is ignored for most purposes. If a UserGroupName element is present in the SANE of a CA certificate, then the BasicConstraints extension MUST also be included and the BasicConstraints.cA flag MUST be set to true. As per normal usage, the contents of the issuer's SANE are generally copied to the IssuerAltName extension of an issued certificate as part of the certificate signature process. However, only the UserGroupName SANEs are consulted during UserGroupName path validation. N.B.: A certificate where the BasicConstraints.cA flag is set to true MUST NOT be accepted as a client or leaf certificate for the purposes of UserGroupName processing. 4. Path Validation Considerations 4.1 Trust Mappings Each system (server, application) which accepts certificates with a UserGroupName element within the certificate's SANE must establish one or more trust mappings between the specified domain tags and root or intermediate CA certificates. During path validation, the accepting system MUST verify that the offered certificate chains back to a root or intermediate CA that has a trust mapping which contains the certificate's SubjectAltName UserGroup domain. The specific mechanism for establishing or describing the trust mapping is outside of the scope of this document. However, it could be something as simple as a text file with the first column listing the domain and the second column listing a certificate fingerprint. labs.nai.com \ 1B:D1:AD:17:8B:7F:22:13:24:F5:26:E2:5D:4E:B9:10 tislabs.com \ 63:1B:66:93:8C:F3:66:CB:3C:79:57:DC:05:49:EA:DB Another possibility might be to identify the trusted certificate by subjectName and the subjectKeyIdentifier. This latter approach may be more useful as it allows expired roots to be easily superceded. StJohns Expires March 26, 2003 [Page 5] Internet-Draft PKIX UserGroupName September 2002 In addition to establishing a mapping between a trust root and a domain, each implementing acceptor must decide whether to accept all, some or none of the validated group information as authoritative. Again, the specific mechanism for describing this is outside the scope of the document, but SHOULD include a global on/off switch for group processing which defaults to off (i.e. group information is not provided to the acceptor); an on/off switch for group processing for each trust anchor which defaults to off; and the ability to limit the groups accepted by each trust anchor to a specific maximum set or to prohibit a set of groups. See Section 6 below for discussion of the appropriate use of group information. :groups=true labs.nai.com 1B:..:10 [ANY:^system:^wheel] tislabs.com 63:..:DB [] 4.2 Domain Matching As mentioned above, the domain field SHOULD be a DNS structured, dot separated string (see 2.3.1 in [RFC1035]). To be valid a client certificate MUST chain back to a trusted certificate where the domain specified by the trust mapping is either equal to the domain of the client certificate or contains the domain of the client certificate. The specific matching algorithm is: if trustDomain(CA) == userGroupName.domain then match else if tail (userGroupName.domain, length(trustDomain(CA))+1) == concat (".", trustDomain) then match else no match trustDomain(CA) looks up the domain for the root certificate's trust mapping tail (string, len) returns the last len characters of a string concat (string,string) returns a concatenation of two strings The addition of the '.' (dot) to the trust domain in the algorithm ensures that an invalid match like "mystupiddomain.com" matching "stupiddomain.com" doesn't happen. Also, as is normal for DNS style names, matching is done without respect to case. Note that there may be multiple trust mappings for a single root and that all MUST be tried for the match. Obviously, using the above matching algorithm, if the userGroupName.domain does not contain a '.', the only match possible is an exact match. StJohns Expires March 26, 2003 [Page 6] Internet-Draft PKIX UserGroupName September 2002 Note: The matching algorithm will need to be readdressed when and if a standard for internationalized domain names is completed and approved. The specific phrase "without respect to case" may be meaningless or may not have a simple canonical resolution in some character sets or under some languages. 4.3 Multiple UserGroupNames CA certificates may contain a SANE with one or more UserGroupNames with a non-null domain and a empty or non-empty set of groups. If a CA certificate does have a such a SANE, it acts to restrict the set of groups that can be 'certified' by that CA certificate. The final set of groups output from the path validation processing of the UserGroupName elements is the MIN of the sets of all the group elements from each UserGroupName (and, if specified, from the group list for root trust mapping). The algorithm is: for each UserGroupName (UGN) in the client certificate SANE set maxGroups to client's UGN.groups for each UGN in the CA certificate in the path if the CA's UGN.domain contains or equals the clients UGN.domain then set maxGroups to MIN (maxGroups, CAs UGN.groups, [trustRoot(CA).groups]) output {domain, maxGroups and userid} For example, the client has a certificate issued by his host with a UserGroupName containing a user of 'stjohns', a group field of ['system', 'security', 'atg'], and a domain field of 'labs.nai.com'. It validly chains back to a root CA certificate that has a trust relationship for 'nai.com'. The CA which signed the client certificate has a SANE with one UserGroupName containing a domain of 'nai.com' and groups of ['system', 'atg', 'admin'] and another UserGroupName containing a domain of 'labs.nai.com' with groups of ['atg']. The certificate would be valid for the domain 'labs.nai.com', the user 'stjohns' and the groups ['atg']. 5. Scenarios Userids are used as a compact representation of identity on computer systems. It's generally much easier to remember "stjohns" than UID:23645 or a certificate finger print. It's also easier to use the userid (vice the other identity forms) as a handle for creating, deleting, or evaluating an access control entry. The UserGroupName provides a straightforward way to map a certificate into a userid. The following section suggests some possible applications for the UserGroupName approach to certificate/userid mapping. StJohns Expires March 26, 2003 [Page 7] Internet-Draft PKIX UserGroupName September 2002 5.1 Web Server with Client Certificates In one particular web-based system which depends upon client certificates for authentication, there are four distinct actions that have to take place before a user is fully enrolled (i.e. before client certificate authorization can take place automatically). First, a user must have a client certificate issued. Second, the administrator must create an account for the user. Third, the administrator of the web service must issue a userid and password for that service account to the user. Finally, the user connects to a secure web page which does a client certificate SSL/TLS exchange. If the web server has a mapping between a userid and this certificate already the interaction is complete and the access rights of the mapped userid are used when considering access to the resources. Otherwise, the web server prompts for a userid and password which is then validated. If valid, the web server stores the userid/ certificate mapping for future reference as above. This last step, in conjunction with the client certificate exchange results in a semi-permanent mapping between the client certificate and the userid. In later interactions between client and server, the client may do automatic client side authentication using its certificate-based credential. The user is granted access to whatever resources the access control system permissions allow for the userid which is associated with the client (user) certificate. In a UserGroupName alternative for this, the user is issued a credential consisting of an X.509 certificate with an appropriate UserGroupName SANE and its associated private key. The credential can be issued in many ways including at least through a certificate signing request, central generation (e.g. a PKCS12 blob), or through the distribution of a hardware token. The administrator must also still create an account on the service. Upon connection to the protected server, the userid (and/or the groups field if permitted by policy) is extracted from the validated client certificate and used as the basis for access control decisions. The process of issuing a PKCS12 blob (containing certificate and private key) or hardware token is roughly equivalent to the single step of issuing a userid and password as described above. As an alternative to having an administrator explicitly create an account for a user, the policy of the web server could allow an account to be created based on the contents of the group field of the UserGroupName. In other words, the web server consults the group field once during the first interaction between the user and the server. If the interaction is authenticated and policy authorizes it, the web server can create an account specific to the userid StJohns Expires March 26, 2003 [Page 8] Internet-Draft PKIX UserGroupName September 2002 contained within the user certificate. The groups field is not consulted once the server creates the account. 6. Security Considerations The use of the UserGroupName in most situations has roughly the same level of threat as that for any X.509 certificate and the Security Considerations text in [RFC3280] is applicable. However, the use of the groups element of the UserGroupName may have some unforeseen side effects in certain systems. The user tags (along with the private keys of the certificates) are just credentials. They can be used to prove the identity of a client, but don't of themselves grant a client access to data or other resources. An access control system is used to map credentials to rights. Revocation of access of a client to a resource is as simple as removing or changing the access control entry and doesn't necessarily require the use of a Certificate Revocation List (CRL) to revoke the certificate. Indeed, the revocation of the certificate may be undesirable as the removal of access may be only temporary. However, the use of group tags is problematic in systems which do not consider Certificate Revocation Lists as part of their path validation processing. Since group access by definition covers a group of people, its difficult or impossible to remove access for a single member of the group without removing the user from the group. If the group information is encoded in the certificate, use of CRLs is pretty much mandatory. One possible approach where groups are desired, but CRLs are not available is to not encode the group information within the certificate. Instead, do the user to group mapping as part of the access control processing (ala Unix). In that manner, a user could be deleted from a group simply by updating the user to group mappings on all accepting systems. Another related approach might be to have a user and group hotlist where you would add a user only if you wanted to remove them from a group that's listed in the client certificate. 7. Design Discussion There are many possible ways of accomplishing the goals of directly encoding user and group information within a certificate. This section provides some insight into the author's reasoning to adopt the otherName approach. StJohns Expires March 26, 2003 [Page 9] Internet-Draft PKIX UserGroupName September 2002 7.1 Attribute Certificate Attribute certificates (ACs) were offered by a couple of members of the PKIX community as one solution for this problem. The argument was made that attribute certificates were the appropriate approach for things that looked like authorization tokens. This approach was rejected for a couple of reasons. First, that ACs had no defined mechanism for encoding the user and group information. This otherName extension would still be required to provide the encoding. Second, ACs were neither in wide use, nor widely understood. Without this knowledge, there is a lack of software on both the issuer and acceptor ends which could deal with the ACs. Third, the author didn't completely agree with the argument that userid and group credentials are authorization tokens. Userid and group assignments for most users tend to be fairly static. The author, for example, held the same userid and the same group assignments for over four years at his previous job. (Except, see Section 6 above.) If ACs gain acceptability, there should be no bars to incorporating this otherName extension as one of the possible attributes allowed within an AC. 7.2 Certificate Extension The approach of encoding the user and group information as a new CertificateExtension was initially attractive for a number of reasons. First, most software and toolkits had at least rudimentary support for new extensions. Second, the actual ASN1 encoding of the information was a bit less clumsy than if encoded as an otherName. This option was also rejected when the author tried to consider the interactions between this extension, the Subject and IssuerNames, and the Subject and IssuerAltName extensions. Having a third place for possibly authoritative name information might make the rules for resolving which name should be used for various authorization activities a bit difficult. 7.3 otherName GeneralName type Encoding the user and group information as an otherName appears to be the mostly right choice. It doesn't add additional extensions which might further conflict with the SubjectName field and SubjectAltName extension. The usage is well within the appropriate field of use for the otherName type. References StJohns Expires March 26, 2003 [Page 10] Internet-Draft PKIX UserGroupName September 2002 [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2246] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC3280] 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 Michael StJohns Network Associates Labs 15204 Omega Drive Rockville, MD 20850 USA Phone: +1-301-947-7162 EMail: msj@tislabs.com Appendix A. ASN.1 Definitions N.B. Any assignments within this section should not be relied upon until and if this document is published either as an experimental RFC or until it enters the standards track. A.1 1988 Module PKIXusergroup {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-user-group (20) } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS StJohns Expires March 26, 2003 [Page 11] Internet-Draft PKIX UserGroupName September 2002 id-pkix, AttributeType, UTF8String FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit-88(1)} -- Object Identifiers -- Externally defined OIDs -- Arc for other name forms id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- userGroupName id-on-userGroup AttributeType ::= { id-on 2 } UserGroupName ::= SEQUENCE { domain UTF8String, user UTF8String, groups SEQUENCE OF UTF8String OPTIONAL } END StJohns Expires March 26, 2003 [Page 12] Internet-Draft PKIX UserGroupName September 2002 A.2 Notional ASN.1 Encoding The following represents how a UserGroupName otherName would be encoded within an SubjectAltName Extension. The notation "'[" means to encode the enclosed items and return the octets. [SEQUENCE -- Extension OID id-ce-subjectAltName -- extnID BOOLEAN true -- critical OCTET STRING -- extnValue -- Encode the following and provide as value for OCTET STRING '[SEQUENCE -- GeneralNames [0 -- otherName type tag [SEQUENCE -- otherName OID id-on-userGroup -- type-id [0 [SEQUENCE -- UserGroupName UTF8String 'tislabs.com' -- domain UTF8String 'stjohns' -- userid [SEQUENCE OF -- groups UTF8String 'system' UTF8String 'atg' ] ] ] ] ] ]' ] StJohns Expires March 26, 2003 [Page 13] Internet-Draft PKIX UserGroupName September 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. StJohns Expires March 26, 2003 [Page 14]