Sacred Working Group D. Gustafson INTERNET-DRAFT Future Foundation Expires May 2001 M. Nystrom RSA Security November 2000 Securely Available Credentials - Framework draft-ietf-sacred-framework-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [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. Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract As the number, and more particularly the number of different types, of devices, connecting to the Internet increases, credential mobility becomes an issue for IETF standardization. This draft responds to the requirements listed in [SACRED}. It presents a strawman framework and outlines protocols for securely available credentials. 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. Please send comments on this document to the ietf-sacrede@imc.org mailing list. Gustafson & Nystrom Expires: May 2001 [Page 1] INTERNET DRAFT SACRED - Framework November 2000 Table of Contents 1. Introduction 2 2. Functional Overview 3 2.1 Client/Server Network Architecture 4 2.2 Peer-to-Peer Network Architecture 4 3. Protocol Framework 5 3.1 Client/Server Protocol 5 3.1.1 Credential Upload 5 3.1.2 Credential Download 7 3.1.3 Credential Removal 8 3.1.4 Credential Management 9 3.2 Peer-to-Peer Protocol 10 4. User Authentication Methods 10 4.1 One-time Password (OTP) Algorithms 10 4.2 Strong Password Algorithms 11 4.3 TLS Remote Client Authentication 11 4.4 Conclusions 11 5. Credential Formats 12 5.1 A note on interoperability 12 5.2 PKCS #12 12 5.3 PKCS #15 12 6. Open Issues 13 7. Security Considerations 13 8. References 13 9. Author's Addresses 14 10. Full Copyright Statement 15 1. Introduction Private credentials are used to support various Internet protocols, e.g. S/MIME, IPSec, and TLS. In a number of environments end users wish to use the same set of private credentials from different end user equipment. In a "typical" desktop environment, the user already has many tools available to allow import/export of these credentials. However, with some devices, especially wireless and other more constrained devices, the tools required simply do not exist. This draft proposes a general framework for secure exchange of user credentials and provide an outline of a protocol to meet requirements stated in [SACRED]. <> Gustafson & Nystrom Expires: May 2001 [Page 2] INTERNET DRAFT SACRED - Framework November 2000 2. Functional Overview Requirements for Securely Available Credentials are fully described in [SACRED]. These requirements assume that two distinctly different network architectures will be supported to exchange credentials between different end user systems: a) Client/Server Credential Exchange b) Peer-to-Peer Credential Exchange These requirements also assume that, in all cases, adequate user authentication methods will be used to ensure credentials are not divulged to unauthorized parties. A security credential consists of cryptographic objects and related data that are needed to support secure communications over the Internet, such as: - public/private key pairs - secret keys - x.509 public key certificates - attribute certificates - application data Since the credential usually contains sensitive information that is known only to the credential holder, such information MUST be encrypted during network transmission and SHOULD be encrypted when stored on an end user device such as a diskette or hard drive. These security credentials MAY be usable with any end user device that can connect to the Internet, such as: - desktop or laptop PC - mobile phone - personal digital assistant (PDA) - etc. Logically, there is no limit to the number of data objects that may be included within a credential or the number of credentials that may be utilized by any particular end user. Throughout this document we assume that a credential is an opaque (and at least partially privacy- and integrity-protected) data object that can be used by a network connected device. Once downloaded, the end user system may, optionally, store its credential information on other special hardware devices that provide additional portability and protection. Gustafson & Nystrom Expires: May 2001 [Page 3] INTERNET DRAFT SACRED - Framework November 2000 2.1 Client/Server Network Architecture The network diagram below shows the components involved in the sacred client/server framework. The numbers refer to protocols that already exist or will be described in this document. +--------+ +------------+ | Client +-----------| Credential | +--------+ 1. | Server | \ +-----+------+ \ | 3.\ | 2. \ | \ +-----+------+ +-----| Repository | +------------+ Client: The entity that wants the credential. Credential Server: The server that downloads credentials to and uploads them from the client. The server is responsible for authenticating the client to ensure credentials are exchanged only with end users who are allowed to use them. Repository: Where the credentials are stored. The repository might have access control features but those generally aren't sufficient in themselves for protecting credentials. Protocol 3 is, likely, not supported by all clients. Protocol 1: The protocol used to download and upload user credentials from a credential server. Described in this document. Protocol 2: The protocol used to store and retrieve user credentials in a repository (LDAP, LDAP/SSL, or other). Protocol 3: The protocol used by the client to exchange credentials (upload or download) directly with a credential repository (LDAP or LDAP/SSL). 2.2 Peer-to-Peer Network Architecture <> Gustafson & Nystrom Expires: May 2001 [Page 4] INTERNET DRAFT SACRED - Framework November 2000 3. Protocol Framework This section provides a high level description of client/server and peer-to-peer protocols that can be used to exchange and manage SACRED credentials. 3.1 Client/Server Protocol The client/server credential exchange protocol is based on three basic and abstract operations; "GET", "PUT", and "DELETE". For all client/server protocol messages it is assumed that: - credential servers MUST NOT be presented with credentials (e.g, a sensitive object such as a private key) in plaintext form - all user, credential server communications MUST be able to use HTTP [RC2616] over TLS [RC2246] - when TLS is used, only cipher suites providing strong confidentiality MAY be used While the following sections assume the use of HTTP over TLS transport service other transport protocol options are certainly feasible. 3.1.1 Credential Upload The framework for credential upload (PUT operation) is: - the credential server MUST be authenticated, that is only TLS cipher suites providing strong confidentiality and server authentication MAY be used - prior to credential upload, the user SHOULD be authenticated (by the server) using a method-dependent protocol sequence - the user then sends a PUT message that contains the credentials and other required information - upload of credentials can either be authenticated, or unauthenticated - if credential upload is unauthenticated, the PUT data MUST include information which will be used for user authentication during download, this information may take various forms <> The credential server should determine whether user authentication is required. Whenever necessary, the remote user MUST be authenticated. The user authentication protocol exchange is method-dependent and Gustafson & Nystrom Expires: May 2001 [Page 5] INTERNET DRAFT SACRED - Framework November 2000 will typically involve the exchange of several messages between client and server. See Section 4 of this document for more detailed information on user authentication methods. The user then issues a "PUT" command containing the credential upload message. This message contains the following data fields: - Credential Format ID and Data The user's protected credential and a format identifier that is needed to parse the credential after it has been downloaded. - Download Authentication Method ID and Data The authentication data and an identifier that specifies how the user will authenticate to the server for downloads. The credential server's response to this PUT message SHOULD contain an identifier of the (version of the) credential, which MAY be used to optimize later downloads. Note that this message format allows each credential stored on the server to be protected by a different password. The TLS protocol provides an "encrypted tunnel" that protects the data only during transmission between client and server. The client MAY provide an additional layer of encryption (as defined by the credential format) to ensure the credential is not exposed within the credential server or repository. The "credential upload" protocol sequence is: client server ------- -------- connect --> ... < auth-0 > --> <-- < auth-1 > < auth-2 > --> ... <-- < auth-n > < cred-1 > --> <-- < cred-1 URL, ID > < cred-2 > --> <-- < cred-2 URL, ID > Gustafson & Nystrom Expires: May 2001 [Page 6] INTERNET DRAFT SACRED - Framework November 2000 ... < done > --> <-- OK (+ connection dropped) where, { auth-0 ... auth-x } is the method-dependent user authentication sequence. Cred-x URL is a locator that can be used to access the credential for download. Cred-x ID is an indicator that may be used for conditional download (e.g. http/1.1 "if modified-since") << For extensibility, we use the connection as if it were a point-to- point link. Should work well for arbitrary links and transports -- is this appropriate for a TLS connection? >> 3.1.2 Credential Download The framework for a credential download (GET operation) is: - TLS server authentication SHOULD be used to authenticate the server - the user MUST be authenticated (by the server) using a method- dependent protocol sequence - a GET request for the credential download is issued - the response contains the credential and format identifier The specific user credential being requested is identified in the message sent to the credential server. If successful, the response MUST contain the requested credential data element (format ID and data) as defined above. Optionally, the user agent MAY include a previously obtained fingerprint (see above) to find out if a download is necessary. If the server finds that the credential has not been modified, it MAY indicate this in its response. The "credential download" protocol sequence is: client server ------- -------- connect --> ... Gustafson & Nystrom Expires: May 2001 [Page 7] INTERNET DRAFT SACRED - Framework November 2000 < auth-0 > --> <-- < auth-1 > < auth-2 > --> ... <-- < auth-n > < GET cred-1 URL [Fingerprint]> --> <-- < GET response 1 (credential-1) > < GET cred-2 URL [Fingerprint] > --> <-- < GET response 2 (credential-2) > ... < done > --> <-- OK (+ connection dropped) where, { auth-0 ... auth-x } is a method-dependent user authentication sequence. cred-x URL is a locator for a specific credential. Each download request may be conditional. << Issue: We need to decide if uploading and downloading multiple credentials needs to be included. Implies that multiple credentials are accessed using a common authentication method and password rather than maintaining a separate password for each. >> 3.1.3 Credential Removal The framework for credential removal (DELETE operation) is: - the credential server MUST be authenticated, that is only TLS ciphersuites providing strong confidentiality and server authentication MAY be used - the user MUST be authenticated (by the server) using a method- dependent protocol sequence - the user then sends a DELETE message that contains the credential Identifier indicating which credential to remove. The "credential removal" protocol sequence is: Gustafson & Nystrom Expires: May 2001 [Page 8] INTERNET DRAFT SACRED - Framework November 2000 client server ------- -------- connect --> ... < auth-0 > --> <-- < auth-1 > < auth-2 > --> ... <-- < auth-n > < DEL cred-1 URL > --> <-- < cred-1 deleted > < DEL cred-2 URL > --> <-- < cred-2 deleted > ... < done > --> <-- OK (+ connection dropped) where, { auth-0 ... auth-n } is a method-dependent user authentication sequence. cred-x URL is a locator for a specific credential. 3.1.4 Credential Management Note that the three basic operations defined above (GET, PUT, DELETE) can be used to perform the necessary management operations: - create a new credential on the server - update an existing credential - delete an existing credential - change password The credential is an opaque (encrypted) data object with user defined format. Section 5 mentions some possible credential formats. However, no credential format is excluded in this memo. There is no restriction on the data that may be included in a user credential or the credential storage format seen by the server. Gustafson & Nystrom Expires: May 2001 [Page 9] INTERNET DRAFT SACRED - Framework November 2000 3.2 Peer-to-Peer Protocol << TBS - define the peer-to-peer protocol >> 4. User Authentication Methods User authentication is vitally important to ensure that credentials are accepted from and delivered to the authorized end user only. If a credential is delivered to some other party, the credential may be more easily compromised. If a credential is accepted from an unauthorized party, the user might be tricked into using a credential which was substituted by an attacker. Ideally, the list of authentication methods should be open ended, allowing new methods to be added as needs are identified and as new methods become available. For all credentials, the user authentication method/data is defined when the credential is first stored on the server and may be updated from time to time thereafter by the authorized user. The following classes of user authentication methods are applicable (at different times) to the credential exchange protocols described earlier: - one-time password (OTP) - strong password - TLS client authentication 4.1 One-time Password (OTP) Algorithms RFC 2289 [RFC2289] describes a password-based authentication method that protects the user's password from eavesdroppers. The client and server disguise the secret pass-phrase by using it to generate a sequence of one-time (single use) passwords each of which cannot be derived from any previously used OTP. With OTP, the user's secret pass-phrase never crosses the network and is not vulnerable to replay attacks. In addition, since each OTP is (effectively) a hash of the password, no secret information need be stored on any system. The user's password canot be derived from any of the OTPs that might be stored on a server. RFC 2444 [RFC2444] describes a One-Time-Password SASL (Simple Authentication and Security Layer) mechanism that provides a formal way to integrate OTP into SASL-enabled protocols such as IMAP, ACAP, POP3 and LDAPv3. Gustafson & Nystrom Expires: May 2001 [Page 10] INTERNET DRAFT SACRED - Framework November 2000 4.2 Strong Password Algorithms Strong password algorithms (e.g. [RFC2945], [PRANDOM], [SPEKE]) may be used to authenticate clients to servers securely, in cases where the client must only memorize a small secret (like a password) and carries no other secret information, and where the server carries a verifier which allows it to authenticate the client but which, if compromised, would not allow someone to impersonate the client. Strong password methods require that user-specific information (e.g., a "verifier", which is derived from the user's password) be configured within the server. This verifier value can only be calculated by a party who knows the password (the user) and must be securely delivered to the server. At connect time, messages are exchanged between the two parties and complementary algorithms are used to compute a common value that can be used to verify the user's password (even though the password is never divulged). Both parties also derive a strong (symmetric) key that could be used to secure subsequent communications between the two parties. Kaliski and Ford [ROAMING] have suggested that an attacker who is able to gain access to "password verifier" value(s) can easily derive the user's password by mounting a dictionary attack against the verifier. They suggest that the verification function should be spread across multiple servers since several servers are less likely to be compromised, at the same time, than any single server. Doing so would provide another level of protection for user passwords. 4.3 TLS Remote Client Authentication A web server application can (optionally) request that the remote client authenticate to the server using a digital signature. In this case, the server requests client authentication and issues a random challenge which is signed and returned (with the client's certificate chain) by the client. The user is strongly authenticated if the digital signature can be verified. TLS client authentication is not possible when the client currently has no credentials that are suitable for use with TLS. 4.4 Conclusions - User passwords need never be stored "in the clear" on credential servers. - Credential servers SHOULD first request TLS remote client authentication whenever it is necessary to establish the identity of credential users. - If client authentication is not possible (e.g., the user currently Gustafson & Nystrom Expires: May 2001 [Page 11] INTERNET DRAFT SACRED - Framework November 2000 has no valid credentials), a strong password should be used to authenticate the user. - In all cases, a different password should be used to derive the secret key used protect the credential data per se. The key derivation formula should maximize the effort needed to mount a dictionary attack on the credential password (given a copy of the credential). - The effective level of protection afforded user passwords, no matter how they are transformed by one-way hash operations, etc. is directly proportional to how well passwords or their derived values are protected by the server. - It is expected that credential users will make use of physical security or additional encryption layers (or both) to further protect their credentials, whenever appropriate. 5. Credential Formats 5.1 Background In order to ensure that credentials created on, and uploaded from, one device are possible to download to, and be used on, another device, there is a need to mandate support for at least one credential format. This section describes two possible candidate formats, both unencumbered. While other formats (and even new ones) certainly are conceivable, it appears as if selection of an existing format offers the best approach. <> 5.2 PKCS #12 PKCS #12 [PKCS12] provides a transfer syntax for personal identity information, including private keys, certificates, and miscellaneous secrets. It is widely used and would therefore constitute a natural choice for a mandated SACRED credential format. 5.3 PKCS #15 PKCS #15 [PKCS15] specifies a file and directory format for storing security-related information on cryptographic tokens (which are defined as portable devices capable of storing persistent data). PKCS #15 has seen its main use as a smart card application where it facilitates interoperability and credential portability. Among things speaking in favor of PKCS #15 are: - Capable of carrying more certificate types (e.g. WAP WTLS [WTLS] certificates] Gustafson & Nystrom Expires: May 2001 [Page 12] INTERNET DRAFT SACRED - Framework November 2000 - Capable of carrying "raw" public keys - Standardized set of secret key types Among things speaking against selection of PKCS #15 as SACRED's mandated credential format are: - The software token format has recently been defined and is not widely used 6. Open Issues This document is intended to foster further discussion of the framework and protocols that might be used to support credential mobility. However, the authors recognize that there are many issues that remain to be resolved. Some of the most pressing are (in addition to those mentioned in [SACRED]: -Flexibility: Users should be able to access their credentials from any device using any supported authentication method -Peer-to-Peer protocol: not described -The possibility of coupling (or not coupling) credential protection to the security provided by transport protocols has not been discussed -Is the triplet enough for now? -Authentication for download - http/1.1 is not very flexible here 7. Security Considerations The Security Considerations section of [SACRED] applies to this memo as well. In particular, and as mentioned in [SACRED], mobile credentials will never be as secure as tamper-resistant hardware solutions. However, reasonable security may be accomplished through some relatively simple means, as outlined above and in [SACRED]. For uploads, if the user is not authenticated, the server MUST make sure not to accidentally overwrite another users' credentials. For downloads, if the server is not authenticated, the user MUST be aware of risks associated with this fact. 8. References [SACRED] Arsenault, A., Farrell, S., "Securely Available Credentials - Requirements", Internet Draft , November 2000. [PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax", RSA Laboratories, June 24, 1999 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Gustafson & Nystrom Expires: May 2001 [Page 13] INTERNET DRAFT SACRED - Framework November 2000 Standard", RSA Laboratories, June 2000. [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0," RFC 2246, January 1999. [RFC2289] Haller, N., Metz, P., Nesser, P., & Straw, M., "A One-Time Password System", RFC 2289. [RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444, November 1997. [RFC2616] R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter, Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [PRANDOM] Perlman, R., Kaufman, C., "Strong Password-Based Authentication Using Pseudorandom Moduli", Internet Draft , June 2000. [SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", September 1996 [ROAMING] Ford, W., Kaliski, B., "Server-Assisted Generation of a Strong Secret from a Password", June 2000. [WTLS] WAP, "Wireless Application Protocol - Wireless Transport Layer Security Specification," Approved version 18-Feb-2000. 9. Author's Addresses Dale Gustafson Future Foundation Eagan, MN 55122 USA tel: +1 651-452-8369 email: dale.gustafson@bpsi.net Magnus Nystrom RSA Security Box 10704 121 29 Stockholm Sweden tel: +46 8 725 0900 email: magnus@rsasecurity.com Gustafson & Nystrom Expires: May 2001 [Page 14] INTERNET DRAFT SACRED - Framework November 2000 10. Full Copyright Statement Copyright (C) The Internet Society (2000). 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. 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. Gustafson & Nystrom Expires: May 2001 [Page 15]