H. S. Madhusudhana INTERNET-DRAFT V. R. Ramachandran Document: draft-madhu-tls-spki-00.txt Novell Expires: January 11 2002 July 11 2001 SPKI Certificate Integration with Transport Layer Security (TLS) for Client Authentication and Authorization 0. 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. 1. Abstract This document extends version 1.0 of the TLS specification [TLS] to support client SPKI certificates and associated public key algorithms, symmetric ciphers, hash algorithms and the appropriate trust model. The server is required to possess a X.509 certificate for authentication. The credentials of both the server's certificate and the client's SPKI certificate are used to achieve mutual authentication and to establish a master secret, which is in turn used to secure client-server communications. Integrating SPKI authorization framework with TLS authentication framework allows accessing of resources or services granted in a SPKI certificate, using a TLS connection to the server. This document uses the same notation as used in the TLS Protocol draft [TLS]. 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 [1]. 2. Introduction Flexibility and Extensibility is one of the main strengths of the TLS protocol. Many cipher suites have been added to TLS to satisfy diverse security needs. [TLS] supports X.509.v3 certificate based authentication and RFC 2712 [KERB-TLS] shows how to extend TLS to Madhusudhana et.al, [Page 1] INTERNET-DRAFT SPKI Certificate-TLS Integration July 11, 2001 Kerberos based authentication within an organization. [OpenPGP] explains extension of TLS to work with OpenPGP keys. A SPKI certificate signs authorization to key binding as against key to name binding of X.509 [SPKI-THEORY]. The SPKI certificate allows chained authorization, which is rooted in some implicit or explicit access control list (root ACL) on the server specifying rights of the first level subject in the authorization chain. SPKI framework does not specify any particular method or protocol for authenticating the subject of the SPKI certificate at the time of resource/service access. We propose to use TLS to provide server authentication to the client based on X.509.v3 certificate and client authentication to the server based on SPKI certificate. We also propose to use TLS for processing of SPKI certificates and related objects to get the authorization result as this computation is application independent. This takes the burden of authorization computation off application developers to the extent that the application developers only needs to validate the authorization result against the corresponding root ACL, as ACL is application dependent. 3. Handshake Message Sequence for SPKI Certificate Authentication This section describes the addition of the SPKI certificate option to the TLS protocol. An implementation SHOULD be able to support TLS with X.509.v3 certificates and TLS with SPKI certificates. For ease of reference, the basic TLS handshake is shown in Figure 1. For a review of the TLS handshake see [TLS]. CLIENT SERVER ClientHello ---------------------------> ServerHello Certificate* ServerKeyExchange* CertificateRequest* ServerHelloDone <--------------------------- Certificate* ClientKeyExchange CertificateVerify* change cipher spec Finished ---------------------------> change cipher spec Finished Application Data <---------------------> Application Data FIGURE 1: The TLS protocol. Note: This figure was taken from RFC 2246. The asterix * indicates that the message is optional. Madhusudhana et.al, [Page 2] INTERNET-DRAFT SPKI Certificate-TLS Integration July 11, 2001 The introduction of SPKI certificate does not require any change in the message sequence. The TLS security context is negotiated in the client and server hello messages. The security context will indicate SPKI based security context and also defines the means of initial authentication, key exchange method, cipher suite for session transfer and the algorithm for message integrity. The definitions of different Cipher Suites are given in Cipher Suite section of this document when SPKI certificates are used. SPKI does not require a server to possess a SPKI certificate. In order to facilitate server authentication, the server MUST have a X.509.v3 server certificate. This server certificate is sent during "Certificate" message of TLS protocol. The semantics of ServerKeyExchange is not changed from TLS protocol. If the server accepts a SPKI-based cipher suite from the client, it MUST send the CertificateRequest message to the client. This specification extends ClientCertificateType as shown in Figure 2 to include the server name and details of applications/services on it and to support different kinds of SPKI certificates. TLS defines several kinds of client certificates to facilitate different methods of key exchange and message authentication. The newly defined SPKI certificate types are semantically same as the corresponding X.509.v3 certificate types except for representation in S-expression format. When X.509.v3 client certificate is used, the DistinguishedName field of CertificateRequest message specifies acceptable CA's distinguished names. When SPKI certificate is used by the client, it is proposed to use the DistinguishedName field to specify server name/application name etc. in order to help the client to select the appropriate SPKI certificate. This is useful because a client may hold multiple SPKI certificates from many servers/applications. +----------------------------------------------------------+ | enum { | | rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), | | dss_fixed_dh(4), kerberos(5), | | spki_rsa_sign(6), spki_dss_sign(7), | | spki_rsa_fixed_dh(8), spki_dss_fixed_dh(9), | | (255) | | } ClientCertificateType; | | | | opaque DistinguishedName <1..2^16-1>; | | | | struct { | | ClientCertificateType certificate_types<1..2^8-1>; | | DistinguishedName certificate_authorities <3..2^16-1>; | |} CertificateRequest; | | | +----------------------------------------------------------+ FIGURE 2: Extended ClientCertificateType Madhusudhana et.al, [Page 3] INTERNET-DRAFT SPKI Certificate-TLS Integration July 11, 2001 +-----------------------------------------------+ | | | opaque Certificate <1..2^24-1>; | | | +-----------------------------------------------+ FIGURE 3: Certificate Message To get server authorization for access/service, the client MUST respond to the server by sending Certificate Message as in Figure 3 In case of SPKI, it is to be noted that Certificate is not an array of elementary certificates as in the case of X.509.v3. Instead, it is a single object which contains a sequence () of SPKI certificates encoded in S-expression format. The contains all component SPKI certificates along with their signatures which represent the authorization chain from server to client. For more details of refer to [SPKI-JUL 1999] and Appendix A. As shown in [SPKI-THEORY], processing of a SPKI authorization certificate involves verifying signatures on certificates, checking certificate validation and generating a 5-tuple for reduction to the final authorization result. A brief summary of deriving authorization result from the SPKI certificate is given in Appendix A. The authorization result is a by-product of SPKI certificate validation and can be used by server access control mechanism to grant/deny requests to access or service. Please note that access control mechanism is not part of this specification. This specification only requires that the enhanced TLS protocol should provide authorization result to the server. If no SPKI certificate is available from the client, the no- certificate alert is returned. The server MAY respond with fatal alert if appropriate. The ClientKeyExchange processing follows TLS specification. The CertificateVerify involves verification of client's signature on master_secret and other messages as in TLS specification. Finished messages for SPKI based mechanism are identical to TLS specification. 4. Cipher Suites The CipherSuite field is extended to indicate type of certificate whether SPKI or X509 or OpenPGP. The CipherSuite of the form {0x00, 0xMN} indicates use of X.509.v3 certificate and 0xMN indicates type of public key encryption, signature, shared key encryption and message digest algorithms employed; The CipherSuite {0x01, 0xYZ} is suggested for TLS extension with OpenPGP [OpenPGP]; The CipherSuite {0x02, 0xYZ} is proposed to denote the employment of SPKI certificates. The second byte of CipherSuite for SPKI takes the same value as defined in CipherSuites for X.509.v3 in [TLS] for Madhusudhana et.al, [Page 4] INTERNET-DRAFT SPKI Certificate-TLS Integration July 11, 2001 indicating types of public key encryption, signature, shared key encryption and message digest algorithms employed. For example, the CipherSuite TLS_DHE_DSS_WITH_DES_CBC_SHA has a value {0x00, 0x12}. The corresponding cipher suite for SPKI is {0x02, 0x12}. The interpretation of cipher suite for TLS 1.0 is that key exchange is based on ephemeral DH keys which is signed using DSS algorithm by a X.509.v3 certificate issued by CA, the hash algorithm is SHA and the encryption algorithm is DES in CBC mode. The interpretation for SPKI based security context remains the same except that a SPKI certificate signs the ephemeral DH key. 5. References [KERB-TLS] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999. [OpenPGP] W. Price, M. Elkins, " Extensions to TLS for OpenPGP keys", INTERNET-DRAFT, March 23 2001. [SPKI-THEORY] C. Ellison, B. Frantz, B. Lampson, R. Rivest, B. Thomas, T. Ylonen, "SPKI Certificate Theory", RFC 2693, September 1999. [SPKI-JUL 1999] C. Ellison, B. Frantz, R. Rivest, B. Thomas, T. Ylonen, "Simple Public Key Certificate", July 23 1999, http://world.std.com/~cme/spki.txt [TLS] T. Dierks and C. Allen, "The TLS Protocol, Version 1.0", RFC 2246, January 1999. A Tuple-reduction and authorization computation in a SPKI Certificate A is an ordered sequence of objects that the client should submit to the server (verifier). The decision on granting access involves reducing certificates in the sequence by the verifier to get the final authorization result the subject (key or object) has been granted through the sequence. The grammar for a sequence object is: :: "(" "sequence" * ")" ; :: | | | | | | ; :: | ; :: "(" "do" "hash" ")" ; :: "(" "do" * ")" ; For details of sub-type definitions refer [SPKI-JUL 1999]. The processing of SPKI certificates in a sequence to get authorization results involves the following steps: Madhusudhana et.al, [Page 5] INTERNET-DRAFT SPKI Certificate-TLS Integration July 11, 2001 1. Individual certificates are checked for the issuer signature. There are three kinds of certificates, namely, name certificates binding a name to a key, attribute certificates binding authorization to a name and authorization certificate binding authorization to a key. 2. The certificate validation is done. This could be done using one of three techniques like CRL, Re-validation and One-time validation as discussed in [SPKI-THEORY]. Intermediate authorization 5-tuple is obtained. 3. The names are replaced with keys based on name definitions. 4. Authorization 5-tuples are reduced to obtain Authorization result. The authorization 5-tuple is derived from SPKI certificate or ACL entry. Its elements are: Issuer: The public key Subject: A public key or Name associated with a public key Delegation: A boolean. If TRUE subject is permitted to re-delegate Authorization: An S-expression. Validity Dates: a not-before date and not-after date The reduction rule for 5-tuples is defined as follows. If there are two 5-tuples and , their reduction yields provided the two intersections succeed and S1=I2 and D1=TRUE. AIntersect is a method for automatic intersection of two authorizations, which are expressed as lists of strings or sub- lists. A special symbol * is introduced to allow for wild cards. AIntersect () is normal set intersection when *-forms are used. The expression, AIntersect ((tag (ftp ftp.clark.net (* set read write))), (tag (*))) evaluates to (tag (ftp ftp.clark.net (* set read write))). VIntersect involves determining the date range for validation. When on-line tests are conducted, their validity dates are to be intersected with validity dates of certificates to get the final VIntersect result. Date range intersection is straight-forward, where V = VIntersect (X,Y) is defined as Vmin = max(Xmin, Ymin) and Vmax = min(Xmax, Ymax). The intersection fails if Vmin > Vmax. Author's Addresses Dr. Madhusudhana H. S. Novell Software Development (I) Ltd., 49/1 & 49/3, Garvebhavipalya, 7th Mile, Hosur Road, Bangalore - 560 068, INDIA Phone: 91-080-573-1856 Email: mmadhusudhana@novell.com Madhusudhana et.al, [Page 6] INTERNET-DRAFT SPKI Certificate-TLS Integration July 11, 2001 Ramachandran V. R. Novell Software Development (I) Ltd., 49/1 & 49/3, Garvebhavipalya, 7th Mile, Hosur Road, Bangalore - 560 068, INDIA Phone: 91-080-573-1856 Email: vrramachandran@novell.co Madhusudhana et.al, [Page 7]