Request for Comments: 3760 Future Foundation
Category: Informational M. Just
Treasury Board of Canada
M. Nystrom
RSA Security
April 2004
Securely Available Credentials (SACRED) - Credential Server Framework
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). 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 document responds to
the requirements on protocols for secure exchange of credentials
listed in RFC 3157, by presenting an abstract protocol framework.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Overview. . . . . . . . . . . . . . . . . . . . . . 2
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Credentials. . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Network Architecture . . . . . . . . . . . . . . . . . . 5
3. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Credential Upload. . . . . . . . . . . . . . . . . . . . 8
3.2. Credential Download. . . . . . . . . . . . . . . . . . . 10
3.3. Credential Removal . . . . . . . . . . . . . . . . . . . 11
3.4. Credential Management. . . . . . . . . . . . . . . . . . 12
4. Protocol Considerations. . . . . . . . . . . . . . . . . . . . 12
4.1. Secure Credential Formats. . . . . . . . . . . . . . . . 12
4.2. Authentication Methods . . . . . . . . . . . . . . . . . 13
4.3. Transport Protocol Suites. . . . . . . . . . . . . . . . 16
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
5.1. Communications Security. . . . . . . . . . . . . . . . . 17
5.2. Systems Security . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 21
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 22
1 Introduction
Digital credentials, such as private keys and corresponding
certificates, 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 credentials on different end-user devices. 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 document proposes a general framework for secure exchange of
such credentials and provides a high level outline that will help
guide the development of one or more securely available credentials
(SACRED) credential exchange protocols.
2. Functional Overview
Requirements for SACRED are fully described in [RFC3157]. These
requirements assume that two distinctly different network
architectures will be created to support credential exchange for
roaming users:
a) Client/Server Credential Exchange
b) Peer-to-Peer Credential Exchange
This document describes the framework for one or more client/server
credential exchange protocols.
In all cases, adequate user authentication methods will be used to
ensure credentials are not divulged to unauthorized parties. As
well, adequate server authentication methods will be used to ensure
that each client’s authentication information (see Section 2.1) is
not compromised, and to ensure that roaming users interact with
intended/authorized credential servers.
2.1. Definitions
This section provides definitions for several terms or phrases used
throughout this document.
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED" and "MAY" in this document are to be interpreted as
described in [RFC2119].
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 signature
key belonging to the client (e.g., as part of TLS [RFC2246]
client authentication).
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. Several standardized formats for the
representation of credentials exist, e.g., [PKCS12], [PKCS15]
(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). During 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 (see e.g., [SPEKE] for a more detailed
definition of this), 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 "account password" and a "credential
password." An account password (and corresponding password token) is
used to authenticate to a Credential Server and to negotiate a key
that provides session level encryption between client and server.
A credential password is used to derive a passkey that’s used to
provide persistent encryption and authentication for a stored
credential. Applicable secured credential standards documents (e.g.,
[PKCS15]) describe the technical details of specific password-based-
encryption (pbe) techniques that are used to protect credentials from
unauthorized use.
Although the same password value may be used to provide both
services, it is likely that different, algorithm specific passkeys
would be generated from this password (i.e., because of different
salt values, etc.).
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
issuers may result in a user having to remember multiple passwords.
2.2. Credentials
This document is concerned with the secure exchange and online
management 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 special hardware devices that provide enhanced portability and
protection for user credentials.
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
document 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 any other
data objects that must be protected from disclosure or modification.
Typically, these security capabilities are part of the basic
credential format such that the credential (e.g., a data file) is
protected when stored on hard drives, flexible diskettes, etc.
During network transmission, the secured credential is protected with
a second (outer) encryption layer. The outer encryption layer is
created using a session-level encryption key that was derived during
the mutual authentication process. Effectively, secured credentials
traverse an "encrypted tunnel" that provides an additional layer of
privacy protection for credentials (and any other) information
exchanged.
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).
This framework describes the high level design for protocol 1.
Protocols 2 and 3 are closely related (but out of scope 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 SACRED protocols exchanged with the
credential server. Depending on credential server design, user
credentials may flow through the credential server to the credential
store or directly between the client and 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. 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". The
secured credential exchange protocol is accomplished as follows:
connect - the client initiates a connection to a credential server
for the purpose of secure credential exchange.
mutual authentication/key negotiation - using a strong password
protocol (or equivalent) the client authenticates to the
server, the server authenticates to the client, and a
session level encryption key is negotiated. The details
of the mutual authentication protocol exchange are
dependent upon the particular authentication method used.
In all cases, the end result is to authenticate the client
to the server and server to the client, and establish a
strong, shared secret between the two parties.
client request(s) - the SACRED client issues one or more high
level credential exchange requests (e.g., GET, PUT, or
DELETE).
server response(s) - the SACRED credential server responds to each
request, either performing the operation successfully or
indicating an appropriate error.
close - the client indicates it has no more requests for the
server at this time. The security context between client
and server is no longer needed. Close is a logical,
session management operation.
disconnect - the parties disconnect the transport level connection
between client and server. Note that "connect" and
"disconnect" are logical, transport-layer dependent
operations that enclose the protocol exchange between the
two communicating processes.
Each high-level credential exchange operation is made up of a
series of request-response pairs. The client initiates each
request, which the server processes before returning an
appropriate response. Each request must complete (server reports
success or failure) before the client issues the next request. The
server SHOULD be willing to service at least one upload or
download request following successful mutual authentication but
either party can terminate the logical connection at any time.
In the following sections, secured credentials and related values are
represented using the following notation:
SC-x is the secured credential file, which includes a format
identifier field and credential data. The credential data
is an opaque, encrypted data object (e.g., PKCS#15 or
PKCS#12 file). The format identifier is needed to
correctly parse the credential data.
Name-x is an account-defined selector or locator (a user friendly
name) that is used to indicate a specific secured
credential. The name of each credential stored under a
given user account MUST be unique e.g., there may be one
credential called "financial" and another called
"healthcare", etc. At a minimum, credential names MUST be
unique across a given account/user name. When no name is
supplied for a GET operation, all credentials stored for
the given username will be returned.
ID-x is a distinct credential version indicator that MAY be used
to request a conditional GET/PUT/DELETE operation. This
credential-ID value SHOULD contain the server’s "last-
modified" date and time (e.g., the time that this
particular credential version was stored on the server)
and MAY contain additional information such as a sequence
number or a (complete or partial) credential fingerprint
that is used to ensure the credential-ID is unique from
other credential versions stored under the same user
account and credential name.
All named credentials may be accessed by authenticating under a
single username. If a user needs or prefers to use more than one
distinct authentication password (and/or authentication method) to
protect access to several secured credentials, he/she SHOULD register
those credentials under distinct user/account names, one for each
different authentication method used.
3.1. Credential Upload
The purpose of a credential upload operation is to allow a client to
register new credentials, or replace currently stored credentials
(e.g., credentials that may have been updated by the client using
appropriate key management software).
The framework for the credential upload, as implemented using the PUT
operation, is:
- The client and server establish a mutually authenticated session
and negotiate a shared secret.
- The client will then issue a PUT message that contains the upload
credential and related data fields.
- The server will respond to the PUT, indicating the credential was
successfully stored on the server or that an error occurred.
The client’s PUT request MAY contain an optional identifier
(credential-ID) field. If present, the new credential will only be
stored if a credential with the same name and credential-ID is
currently stored on the server (e.g., a logical REPLACE operation is
performed). The server MUST return an error if a client attempts to
replace a credential that does not exist on the server.
The credential server’s response to a PUT request MUST contain a
credential version identifier (credential-ID) for the newly stored
credential that MAY be used by clients to optimize subsequent
download operations and avoid credential version mismatches.
3.1.1. Credential Upload Protocol Sequence
The following gives an example of a "credential upload" protocol
sequence:
client server
------- -------
< connect > -->
<--- mutual authentication --->
< PUT SC-1, Name-1, [ID-1] > -->
<-- < Name-1, new-ID-1 >
< PUT SC-2, Name-2, [ID-2] > -->
<-- < Name-2, new-ID-2 >
...
< close > -->
<-- OK (+ disconnect)