INTERNET-DRAFT S. Farrell Expires: January 2001 Baltimore Technologies M. Nystr÷m RSA Security July 2000 Securely Available Credentials 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 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 presents some requirements, a strawman framework and outlines a protocol for securely available credentials. Table Of Contents Status of this Memo.............................................1 Abstract........................................................1 Table Of Contents...............................................1 1. Introduction.................................................2 2. Requirements.................................................2 3. Framework....................................................3 4. Outline Protocol.............................................5 5. A "strong" password scheme...................................5 6. Open Issues..................................................6 7. Security Considerations......................................7 8. References...................................................7 Author's Addresses..............................................7 Full Copyright Statement........................................8 Farrell & Nystr÷m [Page 1] INTERNET-DRAFT July 2000 1. Introduction. Private credentials are used to support various Internet protocols, e.g. S/MIME, IPSec, 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 leads to a high level requirement for protocol(s) that allow these private credentials to be made available over the Internet. Such credentials are highly sensitive, since they are the basis for many of the security features of the Internet protocols referred to above. There are therefore stringent security requirements that any proposed protocol(s) must meet. The typical credential envisaged here is often either the entirety or just the private part of what is often called a personal security environment or PSE [RFC2459]. Other forms of credential are of less direct interest here. Since the credential concerned may be required to be present in order to use PKI based authentication mechanisms, we cannot rely on such mechanisms, at least for "download" (towards the end user) operations. Note also that since PSEs often include "root" CA information, (as well as private keys), it may not be possible to depend on PKI based authentication of network servers. In the remainder of this draft we present a set of requirements, propose a general framework and provide an outline of a protocol to meet the requirements. The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119]. <> 2. Requirements The following requirements assume that the is a credential server from which credentials are downloaded to the end user device, and to which credentials are uploaded from an end user device. 1. Credential download (to end user) and upload (to credential server) MUST be supported 2. Credentials MUST only be downloadable following user authentication 3. Credential upload MAY require user authentication 4. Users MUST be able to manage their credentials stored on the credential server <> Farrell & Nystr÷m [Page 2] INTERNET-DRAFT July 2000 5. The protocol(s) MUST support a range of user authentication mechanisms 6. The protocol(s) MUST support a range of credential formats. 7. The protocol(s) MUST be extensible so as to be able to support a wide range of end user devices, accessed using a range of transport protocols 8. Different end user devices MAY be used to download/upload/manage the same set of credentials 9. Credentials MUST be protected whilst in transit 10. The credential server MUST NOT have easy access to the cleartext credentials 11. It MUST be possible to ensure the confidentiality/privacy of all interactions between users and credential servers 12. Credential servers MUST be authenticated to the user for all operations except (possibly) download 13. It MUST be possible to authenticate the credential server to the user prior to download (if the user is able to verify the authentication) 14. It MUST be possible to cache credentials locally on the end user device without unnecessarily exposing the private parts of the credential 15. The user SHOULD only have to enter a single secret value in order to download a credential. 3. Framework The diagram below shows the components involved in the sacred framework. The numbers refer to protocols that may be defined. +--------+ +------------+ | Client +-----------+ Credential | +--------+ 1. | Server | \ +-----+------+ \ | 3.\ | 2. \ | \ +-----+------+ +-----+ Repository | +------------+ Client: The entity that wants the credential. Credential Server: The server that knows how/who/when to give the credential to the client. Repository: Where the credentials are stored. The repository might have access control features but those generally aren't sufficient in themselves for protecting credentials. Private information in credentials must be protected by encryption. The key for this encryption can be derived from a password, but can also be something stronger. As an example of a stronger method, one Farrell & Nystr÷m [Page 3] INTERNET-DRAFT July 2000 could consider the user authenticating to the credential store using some strong authentication method (not requiring public-key cryptography) and then downloading (over a confidentiality-protected connection) not only the credentials but also (parts of) the key to unlock the card. This way, the key used to protect the credentials will not be derived from the user's password solely. Further, in order to make it harder for a credential store administrator to find out about users' private objects, the key stored at the operator's server may be combined with a user-derived key to form an actual key-encryption key. Credentials must be integrity protected, since it would otherwise be possible for an attacker to substitute parts of the credentials (e.g. trusted certificates) with something more advantageous for the attacker. Once again, the key for this integrity-protection may be derived from a user password, but in this case, it could also be the user's own private key (assuming that private objects on the token are decrypted before the integrity check is done). The basic framework is as follows: - credential servers MUST NOT be presented with credentials in cleartext form - all user, credential server communications MUST use HTTP over TLS - only TLS ciphersuites providing strong confidentiality MAY be used The framework for uploads is as follows: - the credential server MUST be authenticated, that is only TLS ciphersuites providing strong confidentiality and server authentication MAY be used - the user sends a POST message with the POST data containing the credentials and other required information - upload of credentials can either be authenticated, or unauthenticated, any authentication information (for the upload operation itself) is carried inside the POST data - the POST data MUST include information which will be used later for authentication during download, this information may take various forms <> This upload message is described in the following XML DTD: Farrell & Nystr÷m [Page 4] INTERNET-DRAFT July 2000 OperationUploadData, if present, is intended to authenticate the user for the upload operation. DownloadAuthenticationData, which MUST be present, contains indicates how the user will authenticate for subsequent downloads and contains method specific data. CredentialData contains the format information and the actual credential itself. The HTTP response to this POST message SHOULD be a text/html page containing a HREF, which indicates URL from which the credential MAY subsequently be downloaded. The download operation is as follows: - HTTP authentication is used to authenticate users to credential servers(*) - a simple GET request for the download URL is issued - the HTTP response contains the credential and information about the credential format (*) This assumes that an HTTP SASL authentication scheme is defined in addition to the current HTTP Basic and Digest authentication schemes [RFC2617]. Work on such a scheme is on-going [<>]. The HTTP response MUST contain a CredentialData element as defined in the above DTD. <> 4. Outline Protocol In terms of the framework above, the specific protocol proposed as mandatory to implement requires support for: - OTP [RFC2289] and, optionally, S/KEY [RFC1760] for user authentication - uploads are unauthenticated and contain the OTP or S/KEY username for downloads, and optionally the pass-phrase in the DownloadAuthenticationData - PKCS#15 [PKCS#15] is the credential format <> - the OTP (or S/KEY) passphrase is completely separate from any password based encryption keys used to protect the PKCS#15 credential <> 5. A "strong" password scheme In this section we present an idea for a "strong" password scheme. The idea here is to tie down the "MUST" implement mechanisms for the framework. <> Farrell & Nystr÷m [Page 5] INTERNET-DRAFT July 2000 Assumption: User has credential Cd. To secure a credential: Idea is to hash Cd and derive both a key and a password from the hash. The security of the key/password derivation is driven by a "level" (number of bits of hash used to derive password). H=hash(Cd) K=fold(H,level) PWD=password-generator(K) secured-credential=encrypt(K,Cd) password-generator can be the OTP six word picker scheme (apparently about 11 bits per word) fold function can fold/truncate the hash to a key, based on the number of bits indicated in the level (e.g. level1 is 40 bit; level 2 = 60 bit; level 3 = 80 bit) User uploads nickname + secured-credential to credential server. When roaming: user->server: nickname server->user: secured-credential To expose credential: K=reverse-password(PWD) recovered=decrypt(K,secured-credential) status=compare(fold(H(recovered)),K) 6. Open Issues This document is intended to foster discussion of the requirements, 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: IPR: Some of the useful mechanisms are encumbered Robustness: Credential stores should not unacceptably increase the potential for denial-of-service or other attacks Performance: Users should not typically have to wait too long for access to credentials Bootstrapping: The use of, e.g. TLS server authentication, depends on the client having a (set of) trusted root(s) - as the protocol Farrell & Nystr÷m [Page 6] INTERNET-DRAFT July 2000 may be providing these roots, there may be some hard bootstrapping issues. Finally, we note that whether or not the user authentication, credential protection and specific credential formats should be separated, or should be intertwined, is an open issue that warrants careful consideration. 7. Security Considerations Mobile credentials will never be as secure as a "pure" smart card solution. However, reasonable security may be accomplished through some simple means, as outlined above. One should keep in mind, however, that platforms to which credentials are downloaded usually cannot be regarded as tamper-resistant, and it therefore is not too hard to analyze contents of their memories. Further, storage of private keys, even if they are encrypted, on a credential server, will be unacceptable in some environments. 8. References [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026. [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", RFC 2459. [RFC2616] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616. Author's Addresses Stephen Farrell, Baltimore Technologies, 61/62 Fitzwilliam Lane, Dublin 2, IRELAND tel: +353-1-647-3000 email: stephen.farrell@baltimore.ie Magnus Nystr÷m RSA Security Box 10704 121 29 Stockholm Sweden Farrell & Nystr÷m [Page 7] INTERNET-DRAFT July 2000 tel: +46 8 725 0900 email: magnus@rsasecurity.com 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. 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. Farrell & Nystr÷m [Page 8]