D. Gustafson Future Foundation M. Just Entrust Internet Draft M. Nystrom Document: draft-ietf-sacred-framework-02.txt RSA Security Expires: December 2001 July 2001 Securely Available Credentials - Credential Server Framework 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 responds to the credential server framework 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 [1]. Please send comments on this document to the ietf-sacred@imc.org mailing list. Gustafson, Nystrom, & Just [page 1] Securely Available Credentials - July 2001 Credential Server Framework Table of Contents STATUS OF THIS MEMO ............................................... 1 ABSTRACT .......................................................... 1 1 INTRODUCTION .................................................... 3 2 FUNCTIONAL OVERVIEW ............................................. 3 2.1 DEFINITIONS .................................................. 3 2.2 CREDENTIALS .................................................. 5 2.3 NETWORK ARCHITECTURE ......................................... 6 3 AUTHENTICATION METHODS .......................................... 7 3.1 STRONG PASSWORD PROTOCOLS .................................... 8 3.2 TLS AUTHENTICATION ........................................... 8 3.2.1 MUTUAL TLS AUTHENTICATION ................................. 8 3.2.2 TLS SERVER AUTHENTICATION ................................. 9 4 AUTHENTICATION OPTIONS .......................................... 9 4.1 CLIENT INITIALIZATION ........................................ 9 4.1.1 UNINITIALIZED CLIENT STATE ................................ 9 4.1.2 INITIALIZED CLIENT STATE .................................. 9 4.2 CLIENT AUTHENTICATION ....................................... 10 4.2.1 USER REGISTRATION ........................................ 10 4.2.2 CREDENTIAL DOWNLOAD ...................................... 10 4.2.3 POST CREDENTIAL DOWNLOAD OPERATIONS ...................... 11 5 PROTOCOL FRAMEWORK ............................................. 11 5.1 CREDENTIAL UPLOAD ........................................... 11 5.1.1 CREDENTIAL UPLOAD PROTOCOL SEQUENCE ...................... 12 5.2 CREDENTIAL DOWNLOAD ......................................... 12 5.2.1 CREDENTIAL DOWNLOAD PROTOCOL SEQUENCE .................... 13 5.3 CREDENTIAL REMOVAL .......................................... 14 5.3.1 CREDENTIAL REMOVAL PROTOCOL SEQUENCE ..................... 14 5.4 CREDENTIAL MANAGEMENT ....................................... 14 6 CREDENTIAL FORMATS ............................................. 15 6.1 PKCS #12 .................................................... 15 6.2 PKCS #15 .................................................... 16 7 OPEN ISSUES .................................................... 16 REFERENCES ....................................................... 17 AUTHOR'S ADDRESSES ............................................... 19 FULL COPYRIGHT STATEMENT ......................................... 19 Gustafson, Nystrom, & Just [page 2] Securely Available Credentials - July 2001 Credential Server Framework 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 on different end-user equipment. In a "typical" desktop environment, the user already has many tools available to allow import/export of these credentials. However, this is not very practical. In addition, 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 provides an outline of a protocol to meet requirements stated in [SACRED]. 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 This draft describes only the client/server architecture framework. A separate framework draft may describe the peer-to- peer architecture. In all cases, adequate user authentication methods will be used to ensure credentials are not divulged to unauthorized parties. As well, adequate server authentication ensures that client authentication information (see Section 2.1) is not compromised, and so that the user retrieves their intended credentials (i.e. so that a user isn't maliciously given an "older" set of credentials to use). 2.1 Definitions This section provides definitions for several terms or phrases used throughout this draft. client authentication information: information that is presented by the client to a server to authenticate the client. This may include a password token, a registration string that may have been received out-of-band (and possibly used for initially registering a roaming user) or data signed with a private signing key credential belonging to the client (e.g. as part of TLS client authentication). Gustafson, Nystrom, & Just [page 3] Securely Available Credentials - July 2001 Credential Server Framework credentials: cryptographic objects and related data used to support secure communications over the Internet. Credentials may consist of public/private key pairs, symmetric keys, X.509 public key certificates, attribute certificates, and/or application data. Credentials are cryptographically protected for confidentiality and integrity by encoding them in a standard format (e.g. PKCS#12 or PKCS#15). (See secured credentials below.) passkey: a symmetric key, derived from a password. password: a string of characters known only to a client and used for the purposes of authenticating to a server and/or securing credentials. A user may be required to remember more than one password. password token: a value derived from a password using a one-way function that may be used by a client to authenticate to a server. A password token may be derived from a password using a one-way hash function, for example. secured credentials: a set of one or more credentials that have been cryptographically secured, e.g. encrypted/MACed with a passkey. Secured credentials may be protected using more than one layer of encryption, e.g. the credential is secured with a passkey corresponding to a user's password and also by a key known only to the server (the credential's stored form). Prior to network transfer, the passkey-protected credential may be protected with an additional encryption layer using a symmetric key chosen by the Credential Server (e.g., the transmitted form). strong password protocol: a protocol that authenticates clients to servers securely, where the client need only memorize a small secret (a password) and carries no other secret information, and where the server carries a verifier (password token) which allows it to authenticate the client. A shared secret is negotiated between client and server and is used to protect data subsequently exchanged. Note the distinction between an "authentication password" and a "credential password." An authentication password (and corresponding token) may be used by a user to authenticate to a Credential Server. A credential password may be used to generate a passkey used to secure credentials. Although the same password may be used to both authenticate and protect all credentials, it is likely that different passkeys would be generated from this password to protect credentials (i.e. because of different salt values). In addition, although it may be more convenient for a user to remember only a single password, differing security policies (e.g. password rules) between the credential server and the credential Gustafson, Nystrom, & Just [page 4] Securely Available Credentials - July 2001 Credential Server Framework issuers may result in a user having to remember multiple passwords. 2.2 Credentials This document is concerned with the secure use of credentials in a roaming or mobile environment. 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. The end user system may, optionally, store its credential information on other special hardware devices that provide additional portability and protection. Since the credential usually contains sensitive information that is known only to the credential holder, credentials MUST NOT be sent in the clear during network transmission and SHOULD NOT be in the clear when stored on an end user device such as a diskette or hard drive. For this reason, a secured credential is defined. Throughout this draft we assume that, at least from the point of view of the protocol, a secured 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, clients must be able to recover their credentials from this opaque format. At a minimum, all supported credential formats SHOULD provide privacy and integrity protection for private keys, secret keys, and other objects that must be protected from disclosure or modification. Typically, these capabilities are part of the basic credential format such that the credential (file) is protected when stored on hard drives, flexible diskettes, etc. Prior to network transmission, the full credential will be protected with a second layer of encryption. This outer encryption layer uses a negotiated, secret key that is shared between sender and receiver only and provides an additional level or protection from disclosure to unauthorized parties during network transmission. Gustafson, Nystrom, & Just [page 5] Securely Available Credentials - July 2001 Credential Server Framework 2.3 Network Architecture The network diagram below shows the components involved in the sacred client/server framework. +--------+ +------------+ | Client +-----------| Credential | +--------+ 1 | Server | \ +-----+------+ \ | \ | 2 \ | \ 3 +-----+------+ -----------| Credential | | Store(s) | +------------+ Client - The entity that wants to retrieve their credentials from a credential server. Credential Server - The server that downloads secure credentials to and uploads them from the client. The server is responsible for authenticating the client to ensure that the secured credentials are exchanged only with an appropriate end user. The credential server is authenticated to the client to ensure that the client's authentication information is not compromised and so that the user can trust the credentials retrieved. Credential Store - The repository for secured credentials. There might be access control features but those generally aren't sufficient in themselves for securing credentials. The credential server may be capable of splitting credentials across multiple credential stores for redundancy or to provide additional levels of protection for user credentials. Protocol 1 - The protocol used to authenticate the client and credential server, and download and upload user credentials from a credential server. Protocol 2 - The protocol used by the Credential Server to store and retrieve user credentials (LDAP, LDAP/SSL, or other). Protocol 3 - The protocol used by the client to store and retrieve user credentials from the credential store (LDAP, LDAP/SSL, or other). The high level design for protocol 1 is described by this framework. Protocols 2 and 3 are closely related (but out of scope Gustafson, Nystrom, & Just [page 6] Securely Available Credentials - July 2001 Credential Server Framework for this document) and could be implemented using standard protocols, such as LDAP or secure LDAP, or other standard or proprietary protocols. Note also that any administrator- credential server protocols are assumed to be server vendor specific and are not the subject of SACRED standardization efforts at this time. Clients are not precluded from exchanging credentials directly with a credential store (or any other server of it's choosing). However, mutual authentication with roaming users and a consistent level of protection for credential data while stored on network servers and while in transit is provided by the credential server. Depending on credential server design, user credentials may flow through the credential server to the credential store or directly from the client to/from the credential store. Also, users may upload their credentials to several credential servers to obtain enhanced levels of availability. Coordination (automatic replication) of user information or credential data among several credential servers is currently beyond the scope of this document. 3 Authentication Methods Authentication is vitally important to ensure that credentials are accepted from and delivered to the authorized end user only. If an unsecured 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 (e.g. an older credential for the user). 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 a user is first registered with the credential server and may be updated from time to time thereafter by the authorized user. To adequately protect user credentials from unauthorized disclosure or modification in a roaming environment, all SACRED authentication methods MUST provide protection for user credentials in network environments where attackers might attempt to exploit potential security vulnerabilities. See [SACRED] Section 3.1, Vulnerabilities. At a minimum, each SACRED authentication method SHOULD ensure that: - The server authenticates the client - The client authenticates the server - The client and server securely negotiate a cryptographically strong, shared secret (a session key). Gustafson, Nystrom, & Just [page 7] Securely Available Credentials - July 2001 Credential Server Framework - The exchange of one or more user credentials is protected using this session key. It is expected that even highly optimized SACRED protocols will provide each of these logical functions (although the methods for providing them may overlap substantially). Some existing authentication protocols that might be used for this purpose include: - strong password - TLS authentication Section 4 gives some guidance as to the use of each authentication method. The specifics of each supported authentication protocol is (or will be) defined in a separate draft. 3.1 Strong Password Protocols Strong password protocols such as those described in [RFC2945], [BM92], [BM94], [PDM], and [SPEKE] will be used within SACRED protocols. These strong password methods require that a user- specific value (i.e. a password token) 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 a time when the user establishes a relationship with the server. At connect time, messages are exchanged between the two parties and complementary algorithms are used to compute a shared common value known only to the legitimate user and the server. In all cases, both parties derive a strong (symmetric) key that may be used to secure subsequent communications between the two parties. For the purpose of initial registration a secret shared out-of- band between the user and the Credential Server may be used to strongly authenticate both parties. 3.2 TLS Authentication TLS authentication may either be mutual between the client and server or unilateral where only the server is authenticated to the client. These options are indicated in the following two subsections. In either case, authentication of the server requires that the user possesses at least one trusted root (in addition to their password). 3.2.1 Mutual TLS Authentication Following server authentication, the server MAY request TLS client authentication. If the client is currently configured with a suitable certificate, this operation can be used to authenticate the client. TLS client authentication is not possible whenever the client device has no such credential. Note also the requirement Gustafson, Nystrom, & Just [page 8] Securely Available Credentials - July 2001 Credential Server Framework that the server must be able to successfully validate the user's certificate. 3.2.2 TLS Server Authentication In the case that a client does not have a certificate with which to mutually authenticate with the server, then subsequent to a server authentication, the client may authenticate with a password token. This is a viable option whenever the client certificate cannot be validated by the Credential Server. 4 Authentication Options The choice of authentication mechanism depends very much upon the client state, and in particular, what information is available to them. This section provides some guidance as to what general authentication methods might be more appropriate given the client's environment and operation that they intend to perform. 4.1 Client initialization Authentication of the server, by the client depends on whether the client possesses any trusted roots or not. We distinguish such client state as follows. 4.1.1 Uninitialized client state In order to use http/TLS transport protocol, client software must be configured with one or more root certificates. Root certificates, sometimes called self-signed or self-issued certificates must be protected by some external means (e.g. other than the certificate's digital signature) at all times. Typically, each secure application installs one or more root certificates during the software installation process then protects them using application-specific methods. Prior to client initialization, strong password authentication can be used to authenticate client and server and protect user credential(s) while in transit. Once received, client software can install and configure root certificates, client credentials, and other data as appropriate. 4.1.2 Initialized client state Once root certificates have been installed, http/TLS capability is available and the client device can utilize a wider range of authentication and credential exchange options to upload credentials, download additional credentials, etc. Several combinations of strong password authentication and http/TLS (see section 4.2 for details) can be used to mutually authenticate client and server then exchange credentials. Gustafson, Nystrom, & Just [page 9] Securely Available Credentials - July 2001 Credential Server Framework 4.2 Client authentication The authentication method used by the client to the server depends on the information currently available to the client. It is helpful to distinguish based on the operation that is being performed. There are essentially three different macro-level operations that may be performed by a client interacting with the credential server. This classification of operations is given in the following subsections. Note that in all cases, the user may either be "self registered" or may be registered through the facilities of an administrative process or method that is associated with the credential server. The administrative process or method operates as a user with special create/update privilege. 4.2.1 User Registration A user registering with a credential server will likely currently possess credentials that may be used to authenticate to the Credential Server. In this case, mutual TLS authentication (see Section 3.2.1) may be used (provided the user has been initialized - see Section 4.1.2). However, the use of the client certificate also requires that the Credential Server is able to establish trust in this certificate. Alternatively, a user might register using a secret shared out-of- band with the credential server, and used in a strong-password- based protocol (see Section 3.1). This alternative supports an uninitialized user (see Section 4.1.1) but requires an out-of-band sharing. In the case that identification of the user is not required as part of their registration, an initialized user (see Section 4.1.2) may upload the appropriate registration information to the Credential Server over a server-authenticated TLS session (see Section 3.2.2). 4.2.2 Credential Download An uninitialized user (see Section 4.2.1) not currently possessing any certificate information may use a strong-password-based protocol (see Section 3.1) as authentication for downloading their credentials. Alternatively, an initialized user (see Section 4.2.2) may use a server authenticated session and user password to authenticate to the Credential Server (see Section 3.2.2). An initialized user already possessing a certificate that is verifiable by the Credential Server may establish a mutually authenticated TLS session (see Section 3.2.1) prior to download. Gustafson, Nystrom, & Just [page 10] Securely Available Credentials - July 2001 Credential Server Framework 4.2.3 Post Credential Download Operations Once a client has retrieved their credentials, an initialized client (see Section 4.2.2) may use mutual TLS authentication (see Section 3.2.1) to perform any subsequent operations (so long as the credential server is able to determine the validity of the user certificate). Alternatively, an initialized user (see Section 4.2.2) may use a server authenticated session and user password to authenticate to the Credential Server (see Section 3.2.2). An uninitialized user (see Section 4.2.1) may use a strong- password-based protocol (see Section 3.1) as authentication for any post credential download operations. 5 Protocol Framework This section provides a high level description of client/server protocols that can be used to exchange and manage SACRED credentials. The client/server credential exchange protocol is based on three basic and abstract operations; "GET", "PUT", and "DELETE". Access to credentials is based on a user supplying at least a user name and appropriate client authentication information. Successful authentication by the user allows access to the secured credentials corresponding to the authenticate user name. For each user name, different "handles" may be assigned to different secured credentials, e.g. there may be one handle for "financial" and one for "healthcare" credentials. If a user would like to have a distinct (authentication) password in order to obtain different secured credentials, then they may register credentials under distinct user names. 5.1 Credential Upload The purposes of a credential upload capability are: - to allow a client to register new credentials with a credential server, and - to allow a client to modify currently stored credentials with new credentials, e.g. credentials that may have been updated by the client using appropriate key management software. The framework for credential upload (PUT operation) is: - The client and server establish a mutually authenticated session and negotiate a shared secret. Gustafson, Nystrom, & Just [page 11] Securely Available Credentials - July 2001 Credential Server Framework - The client will then issue a PUT message that contains the upload credential and 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. - Credential Handle: The handle or alias associated with the credential. 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. 5.1.1 Credential Upload Protocol Sequence The following gives an example of a "credential upload" protocol sequence: client server ------- ------- < connect > --> <--- mutual authentication ---> < Cred-1 > --> <-- < Cred-1 URL, ID > < Cred-2 > --> <-- < Cred-2 URL, ID > ... < done > --> <-- OK (+ connection dropped) where, The protocol exchange is dependent upon the authentication method used. In any case, its end result is to authenticate the client to the server and server to the client, and establish a symmetric key shared between the two parties. Cred-x URL is a locator that can be used to access the secured credential for download. Cred-x ID is a indicator that may be used for conditional download (e.g. http/1.1 "if modified-since"). 5.2 Credential Download Gustafson, Nystrom, & Just [page 12] Securely Available Credentials - July 2001 Credential Server Framework Roaming clients can download their credentials at any time after they have been uploaded to the server. The framework for a credential download (GET operation) is: - The server SHOULD be authenticated to the client - 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 may be 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. In the case that a credential handle is not specified, all credentials associated with the given user name may be returned. Optionally, the user agent MAY include a previously obtained fingerprint (see above) to determine whether a download is necessary. If the server finds that the credential has not been modified, it MAY indicate this in its response. 5.2.1 Credential Download Protocol Sequence The following gives an example of a "credential download" protocol sequence: client server ------- -------- < connect > --> <--- mutual authentication ---> < GET Cred-1 URL [Fingerprint]> --> <-- < GET response 1 (Cred-1) > < GET Cred-2 URL [Fingerprint]> --> <-- < GET response 2 (Cred-2) > ... < done > --> <-- OK (+ connection dropped) where, Gustafson, Nystrom, & Just [page 13] Securely Available Credentials - July 2001 Credential Server Framework Cred-x URL is a locator for a specific credential. Each download request may be conditional. Fingerprint is an optional value that may be used to indicate that a specific version or revision level of Cred-x is already available to the client. 5.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 in the case that TLS authentication is 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. 5.3.1 Credential Removal Protocol Sequence The following gives an example of a "credential removal" protocol sequence: client server ------- -------- < connect > --> <-------- mutual authentication --------> < DEL Cred-1 URL > --> <-- < Cred-1 deleted > < DEL Cred-2 URL > --> <-- < Cred-2 deleted > ... < done > --> <-- OK (+ connection dropped) where, Cred-x URL is a locator for a specific credential. 5.4 Credential Management Gustafson, Nystrom, & Just [page 14] Securely Available Credentials - July 2001 Credential Server Framework 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 These basic operations might also be used to construct more complex operations such as registration, de-registration, change- password, or list-credentials. The credential is an opaque (encrypted) data object with user defined format. Section 6 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. 6 Credential Formats To ensure that credentials created on, and uploaded from, one device can be downloaded and used on any other device, there is a need to define a single "mandatory to implement" credential format that must be supported by all conforming client and server implementations. Other optional credential formats may also be supported. Each credential format must provide adequate privacy protection for user credentials when they are stored on flexible diskettes, hard disks, etc. This section describes two possible candidate formats, both (believed to be) unencumbered, and both engineered for widespread use and able to carry and store credential information with adequate privacy protection. Thoughout this document, the credential is treated as an opaque (encrypted) object and, as such, the credential format does not affect the basic credential exchange protocol. Additional credential formats may be defined for use with specific (compatible) client devices as needed. Whenever needed, adequate care should be taken to ensure that similar levels of privacy protection are afforded by each credential format used. 6.1 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 SACRED credential format. PKCS #12 is capable of providing a highly flexible, secure credential format that may contain any number of public/private key pairs, PKCS #8 shrouded key pairs, EE or CA certificates, and Gustafson, Nystrom, & Just [page 15] Securely Available Credentials - July 2001 Credential Server Framework miscellaneous secrets. The entire credential is integrity protected using a digital signature or SHA-1 HMAC. It is expected that sensitive Credential objects will be privacy protected using the password-based-encryption option defined in PKCS #12. 6.2 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] - Capable of carrying "raw" public keys - Standardized set of secret key types Among things speaking against PKCS #15 are: - The software token format has recently been defined and is not widely used 7 Open Issues This document is intended to foster further discussion of the framework and protocols that might be used to support credential mobility. Some open issues that remain are: - Flexibility: Users should be able to access their credentials from any device using any supported authentication method 8 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 nor as tamper-resistant as hardware solutions. However, reasonable security may be accomplished through some relatively simple means, as outlined above and in [SACRED]. Some additional security considerations are: - For uploads, if the user is not authenticated, the server MUST make sure not to accidentally overwrite another user's credentials. - For downloads, if the server is not authenticated, the user MUST be made aware of risks associated with this fact. For example, the user may unknowingly reveal information regarding their authentication password (in the case a password token is supplied Gustafson, Nystrom, & Just [page 16] Securely Available Credentials - July 2001 Credential Server Framework over a server authenticated TLS channel). As well, a user might be unknowingly given an old credential to use. - Using any password-based techniques, user passwords need never be stored "in the clear" on credential servers. - Credential servers SHOULD provide mechanisms to protect against remote dictionary attacks on user passwords, either by repeated access attempts to a single user account or by testing many user accounts using the exact same password. Since such mechanisms may include temporarily locking user accounts, adequate status reporting provisions should be included in affected SACRED protocols. - Clients SHOULD provide mechanisms to protect against a user inadvertently entering her password in the "user name" field or otherwise causing her password to be sent "in the clear" over the network. - 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 (e.g., password verifiers) are protected by the server. - To ensure the integrity of mutual authentication and transaction privacy, credential servers SHOULD protect "password verifiers" with the same rigor that they protect their private key. - It is expected that credential users will make use of physical security or additional encryption layers (or both) to further protect their locally stored credentials, whenever appropriate. References [SACRED] Arsenault, A., Farrell, S., "Securely Available Credentials - Requirements", Internet Draft < draft- sacred-reqs-03.txt>, June 2001. [PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax", RSA Laboratories, June 24, 1999 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax 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. Gustafson, Nystrom, & Just [page 17] Securely Available Credentials - July 2001 Credential Server Framework [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, M. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616. [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", RFC 2945, September 2000. [PDM] Perlman, R., Kaufman, C., Rescorla, E. "Strong Password- Based Credentials Download Using Pseudorandom Moduli , December 2000. [SPEKE] Jablon, D., "Strong Password-Only Authenticated Key Exchange", September 1996 [BM92] S. Bellovin and M. Merritt, "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, May 1992. [BM94] S. Bellovin and M. Merritt, "Augmented Encrypted Key Exchange: a Password-Based Protocol Secure Against Dictionary Attacks and Password File Compromise, ATT Labs Technical Report, 1994. [FK00] 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. Gustafson, Nystrom, & Just [page 18] Securely Available Credentials - July 2001 Credential Server Framework Author's Addresses Dale Gustafson Future Foundation, Inc. 450 Pillsbury Center 200 South Sixth Street Minneapolis, MN 55402 Phone: +1 651-452-9033 USA Email: dale.gustafson@bpsi.net Mike Just Entrust, Inc. 1000 Innovation Drive Ottawa, ON K2K 3E7 Phone: +1 613-270-3685 Canada Email: mike.just@entrust.com Magnus Nystrom RSA Security Box 10704 121 29 Stockholm Phone: +46 8 725 0900 Sweden Email: magnus@rsasecurity.com Full Copyright Statement Copyright (C) The Internet Society (2001). 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. 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, & Just [page 19]