Transport Layer Security Working Group S. Farrell INTERNET-DRAFT SSE Expires Feb. 20, 1999. August 20, 1998 TLS extensions for AttributeCertificate based authorization Status of this memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document describes extensions to [TLS] providing authorization support based on the use of X.509 AttributeCertificates. 1. Introduction TLS provides authentication, data integrity and confidentiality services for Internet protocols. In many applications these services are not sufficient to provide the type of authorization services required. For example, it may be that access to a resource should be controlled on the basis of the client's clearance or role. An additional requirement is support for delegation, where a intermediate TLS server acts as a client but where the final target TLS server must make its access decision on the basis of the initial client's rights. Farrell, S. Expires Feb. 20, 1999 [Page 1] INTERNET-DRAFT AC PROF August 20 1998 While TLS doesn't provide support for these features, AttributeCertificates (ACs) in conjunction with TLS do provide a solution. [AC509] defines a profile of the X.509 AttributeCertificate which can be used in this context. In the remainder of this document we describe the operational models, then the new messages and data structures and finally describe a method for embedding AC exchange into the TLS handshake. 2. Operational Models In some environments it is suitable for the client to "push" an AC to a server. This means that no new connections between the client and server domains are required. It also means that no search burden is imposed on servers, which improves performance. In other cases it is more suitable for the client simply to authenticate to the server and for the server to request ("pull") the client's AC from the AC issuer or a repository. A major benefit of the "pull" model is that it can be implemented without changes to the client. It is also more suitable for some extranet cases, where the client's rights should be assigned within the server's domain. There are a number of possible exchanges which can occur and three entities involved (client, server and AC issuer). In addition the use of a directory service as a repository for AC retrieval may be supported. Farrell, S. Expires Feb. 20, 1999 [Page 2] INTERNET-DRAFT AC PROF August 20 1998 The diagram below shows the exchanges defined which are described in later sections. +--------------+ +---------------+ | | | | | AC Issuer +----+ | Directory | | | | | | +--+-----------+ | Server +-------+-------+ | | Acquisition | |Client | |Server |Acquisition +----------------------+ |Lookup | | | +--+-----------+ +--+----+-------+ | | AC "push" | | | Client +------------------------+ Server | | | (part of TLS h/shake) | | +--------------+ +---------------+ | | Client Lookup +--+-----------+ | | | Directory | Figure 1: AC Exchanges | | +--------------+ Of the above exchanges, the most important to embed in the TLS protocol is that between client and server. AC acquisition (from an issuer or directory) is handled as a higher layer protocol (a payload protocol from the TLS perspective). An AC carrier structure (acinfo) is defined which allows for requests for ACs, responses to same and for pushing ACs plus external controls in a standard manner. This structure is used in all messages. Farrell, S. Expires Feb. 20, 1999 [Page 3] INTERNET-DRAFT AC PROF August 20 1998 3. Data Structures acinfo is the data structure which is used to "push" or "pull" an AC and/or associated control information. acinfo may also be used when requesting an AC from an issuer. A set of public key certificates may also be "pushed" with an acinfo in order to assist the recipient in certificate handling. ACInfo ::= SEQUENCE { type INTEGER { clientAcquire (0), clientAcquireResp (1), serverAcquire (2), serverAcquireResp (3), acRequest (4), acResponse (5) }, peer [0] GeneralName OPTIONAL, template [1] SEQUENCE OF Attribute OPTIONAL, -- only one occurrence of each attr type ac [2] AttributeCertificate OPTIONAL, pps [3] PairingProofs OPTIONAL, certs [4] Certificates OPTIONAL } When an intermediate server (IS) delegates an AC to a target server (TS) then the target (TS) must be able to verify that the intermediate (IS) hasn't "stolen" the AC. This is achieved by having the IS produce the following signed ASN.1 structure: PairingProof ::= SIGNED SEQUENCE { init GeneralName, target GeneralName, issuer GeneralName, serial INTEGER, time GeneralizedTime, nonce BIT STRING, sigalg AlgorithmIdentifier } If traced delegation is required (ensuring that no entity in the chain stole the AC) then a sequence of pairing proofs must be sent (with the current one left most): PairingProofs ::= SEQUENCE OF PairingProof Farrell, S. Expires Feb. 20, 1999 [Page 4] INTERNET-DRAFT AC PROF August 20 1998 So long as TS can verify this data then it can check (via whatever targeting is included in the AC) that IS hasn't stolen the AC. <> <> 4. AC Acquisition 4.1 Client Acquisition This exchange occurs when a client requires a new AC from an issuer. The AC issuer MUST ensure that the client is authenticated, most simply via TLS with client authentication. This exchange may occur at network login time or may happen automatically during (or before) the client handshake with a TLS server (e.g. upon receipt of the ACRequest message from the server - see section 8 below). <> The client sends the following message to the server (the syntax used is described in [TLS]): struct { opaque acinfo<1..2^24-1> } ClientACRequest acinfo field contents are specified below. Field Description ===== =========== type clientAcquireResp peer server name or missing template attributes which the client wishes to be present in the AC ac missing pps missing certs missing Farrell, S. Expires Feb. 20, 1999 [Page 5] INTERNET-DRAFT AC PROF August 20 1998 The server responds with: struct { enum { success(0), success_with_changes(1), failure(2), denied(3), (255) } acstatus; opaque acinfo<1..2^24-1> } ClientACResponse acinfo field contents are specified below. Field Description ===== =========== type clientAcquireResp peer missing template missing ac the AC or missing pps missing certs missing 4.2 Server Acquisition Server acquisition occurs where a client has established a TLS connection to the server, but hasn't provided (or can't provide) an AC. The case where the client provides a PairingProof is also supported. Note that the server may keep a TLS session open (or resume a session) with the issuer for multiple exchanges. AC issuers MUST support this feature, servers MAY make use of this feature. Farrell, S. Expires Feb. 20, 1999 [Page 6] INTERNET-DRAFT AC PROF August 20 1998 The server sends the following message to the issuer: struct { opaque acinfo<1..s^24-1> } ServerACRequest Field Description ===== =========== type serverAcquire peer missing if pps supplied mandatory containing client name if pps missing template missing ac missing pps missing if peer supplied mandatory if peer missing certs may be present if pps supplied The issuer responds with: struct { enum { success(0), success_with_changes(1), failure(2), denied(3), (255) } acstatus; opaque acinfo<1..2^24-1> } ServerACResponse The fields here are as described for the ClientACResponse except that the type is serverAcquireResp. 4.3 Client and Server Lookup ACs are retrieved via LDAP. The LDAP connection MAY be secured with TLS according to local policy. Given a GeneralName for the peer a client or server will perform the following lookup. <> Farrell, S. Expires Feb. 20, 1999 [Page 7] INTERNET-DRAFT AC PROF August 20 1998 Once the directory entry has been identified then the value(s) of the attributeCertificateAttribute should be retrieved. This is defined in [X.509] as: attributeCertificateAttribute ATTRIBUTE ::= { WITH SYNTAX AttributeCertificate EQUALITY MATCHING-RULE certificateExactMatch ID id-at-attributeCertificate } id-at-attributeCertificate ::= OBJECT IDENTIFIER { 2 5 4 58 } The selection of which of the values of the attribute are to be read is out of scope of this specfication. 5. TLS Protocol Extensions The basic requirement is to be able to include an acinfo structure into TLS handshakes. 5.1 Session Management The TLS session state (section 7, p22) now requires a new item: authorization information An acinfo structure containing the authorization information for the session. This element of the state may be null. 5.2 Use of TLS Alerts No new TLS alerts are required. 5.3 Handshake Protocol Extensions The basic approach is to handle the acinfo structure in the same way as X.509 public key certificates are handled. This means that we define an ACRequest which the server can send to the client and an ACInfo with which the client can respond. These are analogous to the existing CertificateRequest and CertificateResponse messages. The extension to the interworking diagram from TLS (section 7.3) is shown on the next page. Farrell, S. Expires Feb. 20, 1999 [Page 8] INTERNET-DRAFT AC PROF August 20 1998 Client Server ClientHello -----> ServerHello Certificate* ServerKeyExchange* CertificateRequest* ACRequest* <----- ServerHelloDone Certificate* ACInfo* ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished -----> [ChangeCipherSpec] Finished ApplicationData <----> ApplicationData <> It is to be expected that a typical scenario would be where a client establishes a session with a server without authorization support. At some point the client requests access to a resource which can only be granted if a client AC is verified. At this point the server may cause a renegotiation using a HelloRequest message. This is similar to cases where a client first establishes anonymously and is then forced into mutual authentication. The following sections define the new messages in more detail. 5.3.1 ACRequest message When this message will be sent: A server can optionally request an AC from the client. This message, if sent, will immediately follow the CertificateRequest (if it is sent). Structure of this message: struct { opaque acinfo<1..2^24-1> } ACRequest Farrell, S. Expires Feb. 20, 1999 [Page 9] INTERNET-DRAFT AC PROF August 20 1998 Field Description ===== =========== type acRequest peer missing template a hint to show the client which attributes are required ac missing pps missing certs missing The client MAY ignore the template field if present. 5.3.2 ACInfo message When this message will be sent: This message must be sent if the client has received an ACRequest message from the server. If sent, it will immediately follow the Certificate message sent by the client (if sent). Structure of this message: struct { opaque acinfo<1..2^24-1> } ACInfo Field Description ===== =========== type acResponse peer missing template missing ac the AC ; may be missing if a pps is present pps optionally present certs optionally present If the ac is missing but the pps is present then the server may attempt to acquire or lookup the AC on the basis of validation of the pps signature. Note however that the pps signature does not authenticate the client to the server as it is not necessarily tied to the TLS session. Upon receipt of this message the server can now validate the AC. However the server may have to wait until after the Finished message in order to trust the AC (i.e. when the client is authenticated). Farrell, S. Expires Feb. 20, 1999 [Page 10] INTERNET-DRAFT AC PROF August 20 1998 6. Conformance Both clients and servers MUST support the AC "push" and the relevant acquisition exchanges. Client and servers MAY support the lookup exchanges. A signing algorithm is required for the PairingProof structure, dsaWithSHA1 MUST be supported. Other signature algorithms specified in [CMS] MAY be supported. 7. Security Considerations A server which accepts an AC from an unauthenticated client may be using a stolen AC. For this reason it is strongly recommended that servers only accept ACs from authenticated clients. A server which is presented with an AC which is delegatable will be able to masquerade as the AC owner to any of the other servers to which the AC can be delegated. This means that the client is effectively trusting the server to the extent that the AC is delegatable by that server. For this reason it is recommended to limit the delegation scope of ACs to the minimum required. 8. References [AC509] Farrell, S,"An Internet AttributeCertificate Profile for Authorization", draft-ietf-tls-ac509prof-00.txt, August 1998. [CMS] Housley, R., "Cryptographic Message Syntax", draft-ietf-smime-cms-05.txt, May 1998. [TLS] Dierks, T., Allen C., "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-05.txt, November 1997. [X.509] ITU-T Recommendation X.509 (1997 E): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, June 1997. Author's Address Stephen Farrell, SSE Ltd. Fitzwilliam Court, Leeson Close, Dublin 2, IRELAND tel: +353-1-676-9089 email: stephen.farrell@sse.ie Farrell, S. Expires Feb. 20, 1999 [Page 11]