PKIX Working Group S. Farrell INTERNET-DRAFT Baltimore Technologies Expires in six months D.W. Chadwick University of Salford October 1999 Limited AttributeCertificate Acquisition Protocol 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. Abstract The PKIX working group is profiling the use of X.509 attribute certificates. This document specifies a deliberately limited protocol for requesting an attribute certificate from a server. It is intended to be complementary to the use of LDAP for AC retrieval, covering those cases where use of an LDAP server is not suitable due to the type of authorization model being employed. For many other cases, the use of LDAP is preferred. Table Of Contents Status of this Memo.............................................1 Abstract........................................................1 Table Of Contents...............................................1 1. Introduction.................................................2 2. LAAP.........................................................3 2.1 Message Types..........................................3 2.1.1 Object Identifiers...............................3 2.1.2 LAAP Request Message.............................4 2.1.3 LAAP Response Message............................6 Farrell & Chadwick [Page 1] INTERNET-DRAFT October 1999 2.2 Encapsulation in CMP...................................6 2.3 Authentication.........................................7 2.4 Error Handling.........................................7 3. Transport Mechanisms.........................................7 3.5 UDP....................................................7 3.6 TCP & HTTP.............................................8 4. Security Considerations......................................8 5. References...................................................8 Author's Addresses..............................................9 Full Copyright Statement........................................9 Appendix A: "Compilable" ASN.1 module..........................10 Appendix B: Samples............................................11 Appendix C: Changes this version / Open Issues.................11 1. Introduction <> The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119]. [ACPROF] specifies the Internet profile of the X.509 attribute certificate (AC) for authorization purposes. This document specifies a deliberately limited protocol for requesting such an AC from a server. There is clearly a requirement for an AC management protocol (or protocols, like [CMP] and [CMC]). Such management protocols are not specified in this document. There is also a requirement for a specification of an LDAP schema to allow retrieval of ACs from LDAP servers, which is specified in [LDAP-SCHEMA]. In addition to such protocols, which may be more suited to management of long-term or more sensitive (i.e. more "powerful") ACs, there is a requirement for a very simple, explicitly limited AC acquisition protocol. We call this protocol the Limited AC Acquisition Protocol (LAAP). LAAP consists of a simple request/response protocol encapsulated in [CMP] messages. The entity which issues the request is called the LAAP requestor (LRQ), the entity which issues the response is called the LAAP responder (LRP). The LRQ is typically an AC owner or an AC verifier; the LRP is typically the AC issuer itself. Farrell & Chadwick [Page 2] INTERNET-DRAFT October 1999 The situations in which LAAP may be more suitable for use than LDAP include: - where ACs are very short lived and the latency involved in writing to the LDAP servers is relatively long (e.g. if a complex X.500 deployment is behind the LDAP server), - where a least privilege style of AC use is required, the LRP can modulate the AC content based on the context of the LAAP request, for example, if the LRQ is authenticated and the LRP is the AC issuer, then the LRP may choose to include only the minimal set of attributes (administered to be) required by that LRQ, - where there are potentially numerous ACs, many of which are never actually used during their lifetime (in which case they should only be generated if needed) e.g. many entities have permission to access some data, but only a subset of them actually do access it, - where ACs contain encrypted attributes and it may not be possible to search the LDAP directory for ACs with attributes of a specific type. LAAP is only intended to be used for cases where an LRQ wishes to acquire a "current" AC for an entity (possibly itself) leaving almost all details as to the content of the AC to the LRP. 2. LAAP The LAAP protocol consists of two new message types which are embedded in the PKIMessage structure, GenMsgContent field defined in [CMP]. Future specifications MAY enhance the request and/or response types defined here - any such enhancement MUST use a different object identifier to identify the GenMsgContent. The one and only feature of this protocol is to request an AC for a particular entity that may be either the LRQ or some other entity. The response is the requested AC or an error. 2.1 Message Types 2.1.1 Object Identifiers This section lists the object identifiers defined in this specification. The following object identifiers are inherited from [RFC2459] and [CMP]. id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-mod OBJECT IDENTIFIER ::= { id-pkix 0 } id-it OBJECT IDENTIFIER ::= { id-pkix 4 } The following new ASN.1 module identifier is defined: id-mod-laap OBJECT IDENTIFIER ::= { id-mod <> } Farrell & Chadwick [Page 3] INTERNET-DRAFT October 1999 << probably { id-mod 13 }>> The LAAP message types are defined as follows: id-laap OBJECT IDENTIFIER ::= { id-it <> } << probably { id-it 7 } >> id-laap-req OBJECT IDENTIFIER ::= { id-laap 1 } id-laap-rep OBJECT IDENTIFIER ::= { id-laap 2 } 2.1.2 LAAP Request Message The request MAY specify the identity of the AC owner (for the third party case), with an optional "profile". A profile is to be interpreted as a bilaterally agreed string that may be mapped to a set of AC contents by the LRP. In the third party case, the LRQ, MAY also include some evidence that the AC owner has requested the LRQ to retrieve an AC belonging to the AC owner. LACRequestMessage ::= SEQUENCE { owner [0] CHOICE{ baseCertificateID [0] IssuerSerial, -- the issuer and serial number of -- the owner's Public Key Certificate entityName [1] GeneralNames, -- the name of the claimant or role objectDigestInfo [2] ObjectDigestInfo -- if present, version must be v2 } OPTIONAL, profile [1] UTF8String OPTIONAL, ownerAuth [2] SEQUENCE { authMethod OBJECT IDENTIFIER, authInfo ANY } OPTIONAL } Each field is described below. "owner": when present this specifies that the LRQ wishes to acquire an AC for this owner. When absent, it means that the LRQ is requesting an AC for itself (the LRP SHOULD use the identity established from whatever authentication is available). The rules for the owner field specified in [ACPROF] apply here (e.g. constrained use of entityName). "profile": when present this is a request to the LRP that an AC matching the supplied profile is returned. The definition of profiles is not in scope for this specification and is expected to be a local matter. There are two main uses envisaged for this field: - Where an LRQ requests its own AC, then the profile field can be used for those entities which require a non-default AC. The typical case here is where a user requests her AC in order to "push" it to a Farrell & Chadwick [Page 4] INTERNET-DRAFT October 1999 relying party via some protocol (like CMS). In most such cases, the user can use a default AC whose content has been selected for her by an administrator. Occasionally, such users will require a different AC, perhaps for use in some application environment that is seldom used. In such cases the profile field can contain a value provided to the user by the AA administrator. It is often the case that a profile maps well to a role in this scenario. - When a relying party requests an AC for another entity it needs the AC to contain a set of attributes which will enable the relying party to make a "good" authorization decision. In most such cases, the identity of the relying party will determine (for the AA) the set of attribute types required. However, in cases where the identity of the relying party is not known, or where a single relying party makes "different" types of authorization decision, (say where two applications run from a single account), then the profile allows the relying party to specify which "type" of authorization decision it wishes to make. It is often the case that the profile maps well to an application or function in this scenario. Where it is desirable that the profile contain a globally unique value, the profile string MAY contain a string encoded object identifier as specified in LDAP [RFC2252], for example, "1.2.5.5.2" is a valid string encoded object identifier. Conformant implementations MUST be able to accept profiles containing such string encoded object identifiers. One possible implementation model which can usefully use this string encoded OID is for the profile to contain the OID of an LDAP or X.500 object class ([X.501], [RFC2526]) and for the LRP to produce an AC containing the relevant attribute values specified by that object class. Note that in all cases where a profile is specified by an LRQ, the resulting AC may or may not meet the LRQ's expectation for ACs which "match" the requested profile. The LRQ MUST check the resulting AC, if it needs to check this "matching". Note also, that in addition to selecting the "attributes" field, an LRP MAY also use the profile to determine other AC fields, e.g. validity or extensions. <> "ownerAuth": this field provides an indirect mechanism for the owner to authenticate the AC request to the LRP (via the LRQ). This is intended to handle the third party case, but where the LRP also requires some proof that the AC should be issued/delivered. For example, authInfo could contain a signature from the owner over the LRQ name and a timestamp. Since the types of authentication which Farrell & Chadwick [Page 5] INTERNET-DRAFT October 1999 can be used will depend on the client/server protocol in use between the owner and LRQ, no authentication methods are defined here. Protocols which make use of LAAP and which allow the use of ownerAuth MUST specify the details of the authentication which is allowed. <> Note that this definition means that the minimal LAAP request structure consists of the octets æ3000ÆH, an empty ASN.1 sequence. This means "give me my current default AC please". 2.1.3 LAAP Response Message The response message consists of an AC (errors are handled at the CMP level). LACResponseMessage ::= AttributeCertificate When an LRQ receives an AC from an LRP it SHOULD verify the AC. In addition the LRQ SHOULD ensure that the AC "matches" the LAAP request issued, i.e. that the owner in the AC matches that in the request (if present). Implementations may of course include additional checks. The AC in the response MUST conform to the profile specified in [ACPROF]. <> 2.2 Encapsulation in CMP LAAP requests and responses are carried within a PKIMessage, as defined in [CMP]. PKIMessage ::= SEQUENCE { header PKIHeader, body PKIBody, protection [0] PKIProtection OPTIONAL, extraCerts [1] SEQUENCE SIZE (1..MAX) OF Certificate OPTIONAL } The GenMsgContent CHOICE of the PKIBody contains the LAAP request or response. Each GenMsgContent consists of an OID and an ANY. We use separate OIDs for LAAP requests and responses. Errors are handled using the ErrorMsgContent form of PKIBody. Farrell & Chadwick [Page 6] INTERNET-DRAFT October 1999 A conformant implementation is NOT REQUIRED to be able to handle any other form of PKIBody. Of course, an LRQ or LRP MAY also handle other forms of PKIBody, e.g. the mandatory profile specified in [CMP]. The fields of the PKIHeader MUST be used as specified in section 3.1.1 of [CMP]. <> 2.3 Authentication Though the PKIMessage construct supports the use of various forms of authentication, the security required for a specific LAAP request or response is not specified here. In order to provide a basic level of interoperability LRPs MUST be able to handle requests authenticated with either the PasswordBasedMac or signature methods described in [CMP] section 3.1.3. LRPs MUST also be able to handle requests which contain no PKIProtection (though they MAY always return an error). LRQs MAY implement either PKIProtection method, but MUST support one, and MUST also support production of requests without any PKIProtection (for cases where the transport provides authentication). 2.4 Error Handling If an LRP receives any CMP message which it does not support (e.g. a public key certification request), then it MUST respond with an error containing "rejection" as the PKIStatus, and "badRequest" as the PKIFailureInfo. The status string MAY contain any implementation specific value (though note that this field is intended to be human readable). For all other error conditions the PKIStatus MUST be "rejection". For example, an LRP MUST NOT respond with a "waiting" PKIStatus. LAAP is not intended to handle cases where production of an AC requires operator intervention. 3. Transport Mechanisms LAAP can be carried via a number of transport mechanisms. We define three. Firstly, directly over UDP, secondly directly over TCP, thirdly by encoding within HTTP. LRQ implementations MUST support the TCP transport and SHOULD support the UDP transport. LRP implementations MUST support both the TCP and UDP transports. Either MAY support the HTTP transport. 3.5 UDP <> 3.6 TCP & HTTP [CMP] already defines TCP and HTTP transports. These MAY also be used for LAAP. Some changes based on implementation experience have been developed in [CMP-TCP] and [CMP-HTTP]. These changes supercede the equivalent transports defined in [CMP] and MUST be supported by compliant implementations. LRQs and LRPs are NOT REQUIRED to support polling, as either an AC or an error is expected to be produced immediately in response to a request. This means that even if an LRP does support other forms of [CMP] requests, it cannot use the polling mechanism in response to a LAAP request. 4. Security Considerations The LRQ MUST verify the AC using the rules given in [ACPROF] before making an authorization decision based on the AC. LAAP (like all such protocols) is vulnerable to denial-of-service attacks, this should be taken into account before deployment. If the LRP is the actual AC issuer, then it should be very careful about handing out ACs in response to unauthenticated requests. One model would be to manage the authentication "strength" required before issuing a given (type of) AC. 5. References [ACPROF] Farrell, S., Housley, R. "An Internet AttributeCertificate Profile for Authorization", draft-ietf-pkix-acprof-01.txt, September 1999. [CMC] Myers, M., et al. "Certificate Management Messages over CMS", draft-ietf-pkix-cmc-03.txt, March 1999. [CMP] Adams, C., Farrell, S., "Internet X.509 Public Key Infrastructure - Certificate Management Protocols", RFC2510. [CMP-TCP] Tschalar, R. et al, "Using TCP as a Transport Protocol for CMP", draft-ietf-pkix-cmp-tcp-00.txt, September 1999, work-in-progress. [CMP-HTTP] Tschalar, R. et al, "Using HTTP as a Transport Protocol for CMP", draft-ietf-pkix-cmp-http-00.txt, August 1999, work-in-progress. [LDAP-SCHEMA]Chadwick, D., "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv3" draft-pkix-ldap-v3- 01.txt, August 1999, work-in-progress. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. Farrell & Chadwick [Page 8] INTERNET-DRAFT October 1999 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet Public Key Infrastructure - X.509 Certificate and CRL profile", RFC2459. [RFC2252] Wahl, M., et al., " Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC2252. [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use with LDAPv3", RFC2256. [X.501] ITU-T Recommendation X.501 : Information Technology - Open Systems Interconnection - The Directory: Models, 1993. Author's Addresses Stephen Farrell, Baltimore Technologies, 61/62 Fitzwilliam Lane, Dublin 2, IRELAND tel: +353-1-647-3000 email: stephen.farrell@baltimore.ie David Chadwick IS Institute University of Salford Salford England M5 4WT email: d.w.chadwick@salford.ac.uk Full Copyright Statement Copyright (C) The Internet Society (date). 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. In addition, the ASN.1 module presented in Appendix B may be used in whole or in part without inclusion of the copyright notice. 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 shall be followed, or as required to translate it into languages other than English. Farrell & Chadwick [Page 9] INTERNET-DRAFT October 1999 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. Appendix A: "Compilable" ASN.1 module PKIXLaap {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) -- temporary, still tbs -- id-mod-laap(13)} DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS IssuerSerial, ObjectDigestInfo, AttributeCertificate FROM PKIXAttributeCertificate {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-attribute-cert(12)} id-pkix 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)} GeneralNames FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-pkix1-implicit-88(2)}; -- this is referenced, but not defined in [CMP] id-it OBJECT IDENTIFIER ::= { id-pkix 4 } id-laap OBJECT IDENTIFIER ::= { id-it -- temporary, still tbs -- 7 } -- these OIDs are used as the infoType of the respective -- GenMsgContent PKIBody fields id-laap-req OBJECT IDENTIFIER ::= { id-laap 1 } id-laap-rep OBJECT IDENTIFIER ::= { id-laap 2 } Farrell & Chadwick [Page 10] INTERNET-DRAFT October 1999 LACRequestMessage ::= SEQUENCE { owner [0] CHOICE{ baseCertificateID [0] IssuerSerial, -- the issuer and serial number of -- the owner's Public Key Certificate entityName [1] GeneralNames, -- the name of the claimant or role objectDigestInfo [2] ObjectDigestInfo -- if present, version must be v2 } OPTIONAL, profile [1] UTF8String OPTIONAL, ownerAuth [2] SEQUENCE { authMethod OBJECT IDENTIFIER, authInfo ANY } OPTIONAL } LACResponseMessage ::= AttributeCertificate END Appendix B: Samples <> Appendix C: Changes this version / Open Issues Changes this version: 1. This is the first issue, previously LAAP was specified as part of the AC profile [ACPROF] 2. Changed LAAP so its now encapsulated in [CMP] 3. Added more definition of profile field 4. Added ownerAuth field (probably temporarily) 5. Added requirement for UDP transport 6. Added compiled ASN.1 module Open issues: 1. register new OIDs 2. Use of profile, esp. OIDs & mapping to AC content 3. ownerAuth: leave in or delete? 4. CMP encapsulation: use or not? 5. Does the LRQ need a way to tell the LRP how much of [ACPROF] it supports? (Probably yes, & include this as an optional field in the request structure.) 6. UDP transport: needed? define where? 7. Samples. Farrell & Chadwick [Page 11]