Securely Available Credentials (SACRED) - Credential Server Framework
A framework for moving private keys safely between a user's devices
Gustafson, D., Just, M., and M. Nystrom, "Securely Available Credentials (SACRED) - Credential Server Framework", RFC 3760, DOI 10.17487/RFC3760, April 2004, <https://www.rfc-editor.org/info/rfc3760>.
@misc{rfc3760,
series = {Request for Comments},
number = 3760,
howpublished = {RFC 3760},
publisher = {RFC Editor},
doi = {10.17487/RFC3760},
url = {https://www.rfc-editor.org/info/rfc3760},
author = {D. Gustafson and M. Just and M. Nystrom},
title = {{Securely Available Credentials (SACRED) - Credential Server Framework}},
pagetotal = 22,
year = 2004,
month = apr,
} RFC text
Contents
Network Working Group D. Gustafson
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)
new-ID-x is the credential-ID of the newly stored credential.
3.2. Credential Download
Roaming clients can download their credentials at any time after they
have been uploaded to the server.
The framework for a credential download, as implemented using the GET
operation, is:
- The client SHOULD authenticate the server.
- The user MUST be authenticated (by the server).
- 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 by
name 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.
If the user issues a GET request with a NULL credential name field,
the server SHOULD return all credentials stored under the current
user account.
Optionally, the client MAY include a credential-ID to indicate a
conditional download request. In this case, the server will return
the requested credential if and only if the ID of the credential
currently stored on the server does NOT match the ID specified.
The server should return either the requested credential or a
distinct response indicating that the conditional download was not
performed (e.g., the client already has a copy of this exact
credential).
3.2.1. Credential Download Protocol Sequence
The following gives an example of a "credential download" protocol
sequence:
client server
------- --------
< connect > -->
<--- mutual authentication -->
< GET Name-1, [ID-1] > -->
<-- < SC-1, ID-1' >
< GET Name-2, [ID-2] > -->
<-- < GET response >
...
< close > -->
<-- OK (+ disconnect)
Notice that for the second request, no credential has been returned
since ID-2, as included in the client's request, matched the
identifier for the Name-2 credential.
3.3. Credential Removal
The framework for the credential removal, as implemented with the
DELETE operation, is:
- The credential server MUST be authenticated (by the client) using
a method-dependent protocol sequence.
- The user MUST be authenticated (by the server) using a method-
dependent protocol sequence.
- The user then sends a DELETE request message that contains the
credential name indicating which credential to remove.
- Optionally, the client may include a credential-ID in the DELETE
request. In this case, the credential will be deleted if the
request ID matches the ID of the credential currently stored on
the server. This may be done to ensure that a client intending to
delete their stored credential does not mistakenly delete a
different version of the credential.
3.3.1. Credential Removal Protocol Sequence
The following gives an example of a "credential removal" protocol
sequence:
client server
------- --------
< connect > -->
<-------- mutual authentication -------->
< DEL Name-1, [ID1] > -->
<-- < Name-1 deleted >
< DEL Name-2, [ID2] > -->
<-- < Name-2 deleted >
...
< close > -->
<-- OK (+ disconnect)
3.4. Credential Management
Note that the three operations defined above (GET, PUT, DELETE) can
be used to perform the basic credential management operations:
- add a new credential on the server,
- update (replace) an existing credential, and
- delete an existing credential.
The information provided for these basic operations might be used to
help guide the design of more complex operations such as user
registration (add account), user deregistration (remove account),
change account password, or list all credentials.
Note that, in the case where a credential with the same name exists
on the server, uploading a NULL credential is logically equivalent to
removing a previously stored credential.
4. Protocol Considerations
4.1. Secure 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 implementations.
At least two well-defined credential formats are available today:
[PKCS12] and [PKCS15].
Other optional credential formats may also be supported if necessary.
For example, additional credential formats might be defined for use
with specific (compatible) client devices. Each credential format
MUST provide adequate privacy protection for user credentials when
they are stored on flexible diskettes, hard disks, etc.
Throughout this document, the credential is treated as an opaque
(encrypted) data object and, as such, the credential format does not
affect the basic credential exchange protocol.
4.2. 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
that has been substituted by an attacker (e.g., an attacker might
replace a newer credential with an older credential belonging to the
same user).
Ideally, the list of authentication methods should be open ended,
allowing new methods to be added as needs are identified and as they
become available. For all credentials, the user authentication
method and 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 Requirements [RFC3157], 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 (or derive) a
cryptographically strong, secret key (e.g., a session key).
- The exchange of one or more user credentials is protected
using this session key.
It is expected that all SACRED client/server protocols will provide
each of these basic security functions. Some existing authentication
protocols that might be used for this purpose include:
- Strong password protocols
- TLS
Sections 4.2.1 and 4.2.2 provide some guidance about when to use
these authentication methods based on the generic security
capabilities they provide and the security elements (passwords, key
pairs, user certificates, CA certificates) that must be available to
the SACRED client.
4.2.1. Strong Password Protocols
Strong password protocols such as those described in [RFC2945],
[BM92], [BM94], and [SPEKE] MAY be used to provide mutual
authentication and privacy for SACRED protocols.
All strong password protocols require that user-specific values
(i.e., a passtoken and related values) be configured within the
server. Only a party who knows the password can calculate the
verifier value. It must be securely delivered to the server at a
time when the client 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. Both parties
derive a strong (symmetric) key that may be used to secure
communications between the two parties.
4.2.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 described in the next two subsections.
In both cases, TLS can be used to authenticate the server whenever
the TLS client has been pre-configured with the necessary
certificates needed to validate the server's certificate chain
(including revocation status checking).
TLS Server Authentication (sTLS)
TLS provides a basic secure session capability (sometimes called
server-side TLS) whereby the client authenticates the server and a
pair of session level encryption keys is securely exchanged between
client and server. Following server authentication and security
context setup, all client requests and server responses exchanged are
integrity and privacy protected.
Protocol designers and implementors should be aware that the
flexibility of the certificate-based TLS server authentication method
creates security risks that need to be mitigated. Specifically, the
need to ensure the user is connected to the intended credential
server (secure site), and no other. The TLS v1.0 standard [RFC2246]
identifies the basis for managing this risk in section F.3 (see also
Section 5.2 in this document):
"Implementations and users must be careful when deciding which
certificates and certificate authorities are acceptable; a
dishonest certificate authority can do tremendous damage."
Note also that a faulty implementation of (increasingly complex) TLS
server certificate chain processing, by the SACRED client, could lead
to similar compromise, allowing successful credential server
masquerade or man-in-the-middle attacks.
An engineering approach that provides an enhanced or augmented server
authentication method may be warranted for SACRED protocol designs.
It is also important to understand that simple layering of
independently developed security protocols (e.g., using BEEP or
similar layering techniques) produces a complex, multilayer security
protocol that might be easily defeated by a combination-specific
attack that is able to expose and exploit known weaknesses of the
individual protocol(s).
When necessary, and after a TLS session has been established between
the two parties, the credential server can request that the client
provide her user id and password information to authenticate the
remote user. Preferably, client and server can cooperate to perform
an authentication operation that allows the server to authenticate
the client (and perhaps vice-versa) in a "zero knowledge manner". In
such cases, the client need not have a security credential.
TLS with Client Authentication (cTLS)
TLS provides an optional, secure session capability (sometimes called
client-side TLS) whereby the TLS server can request client
authentication by verifying the client's digital signature.
In order to use cTLS to provide mutual authentication, the client
must also be configured with at least one security credential that is
acceptable to the TLS server for remote client authentication
purposes.
4.2.3. Other Authentication Methods
Other authentication methods that provide the necessary security
capabilities MAY also be suitable for use with SACRED credential
exchange protocols.
4.3. Transport Protocol Suites
It is intended that one or more underlying protocol stacks may carry
the SACRED credential exchange protocols. It is recognized at the
outset that the use of several underlying protocol suites, although
not ideal from an interoperability standpoint, may well be required
to support the wide variety of needs anticipated.
The SACRED list members have discussed several protocol suites that
have been considered on their technical merits, each with distinct
benefits and protocol design/implementation costs. Among these
protocols are:
- TCP
- BEEP
- HTTP
All protocol suites listed here depend on TCP to provide a reliable,
end-to-end transport layer protocol. Each of these building block
approaches provides a different way of handling the remaining
application layer issues (basic session management, session level
security, presentation/formatting, application functionality).
4.3.1. TCP
This approach (layering a SACRED credential exchange protocol
directly on top of a TCP connection) requires the development of a
custom credential exchange messaging protocol that interfaces to a
TCP connection/socket. The primary benefit of this approach is the
ability to provide exactly the protocol functionality needed and no
more. Most server and client development environments already
provide the socket level API needed.
4.3.2. BEEP
This approach builds on the Blocks Extensible Exchange Protocol
(BEEP) described in [RFC3080]. BEEP provides general purpose, peer-
to-peer message exchange over any of several transport mechanisms
where the necessary transport layer mappings have been defined for
operation over TCP, TLS, etc. See also [RFC3081].
BEEP provides the necessary user authentication/session security and
session management capabilities needed to support SACRED credential
exchange operations.
4.3.3. HTTP
This approach builds on the Hypertext Transport Protocol (HTTP)
described in [RFC1945] and [RFC2616]. HTTP provides general purpose
typing and negotiation of data representation, allowing systems to be
built independently of the data objects being transferred. HTTP
support is available in a wide variety of server and client
platforms, including portable devices that apply to roaming
environments (laptop PCs, PDAs, mobile phones, etc.).
HTTP is layered over TCP and can be used, optionally, with TLS to
provide authenticated, session level security. Either or both TLS
authentication options, sTLS or cTLS, may be used whenever TLS is
supported.
5. Security Considerations
The following security considerations identify general observations
and precautions to be considered for a framework supporting
credential mobility. When designing or implementing a protocol to
support this framework, one should recognize these security
considerations, and furthermore consult the SACRED Requirements
document [RFC3157] Security Considerations.
5.1. Communications Security
A SACRED PDU will contain information pertaining to client or server
authentication, or communication of credentials. This information is
subject to the traditional security concerns identified below.
5.1.1. Confidentiality
The password or password verifier should be protected when
communicated from the client to credential server. The communicated
value should be resistant to a dictionary attack.
Similarly, the entity credentials must be confidentiality protected,
when communicated from the client to the server and vice-versa. The
communicated value should also resist a dictionary attack.
5.1.2. Integrity
Communication integrity between the client and the credential server
is required. In this way, intended client operations may not be
altered (e.g., from an update to a deletion of credentials), nor may
clients be maliciously given "old" credentials (e.g., possibly by an
attacker replaying a previous credential download).
5.1.3. Entity Authentication
Proper authentication of the client and server is required to achieve
communication confidentiality and integrity.
The server must properly authenticate the client, so that credentials
are not mistakenly revealed to an attacker. The client must ensure
the proper identification of the credential server so as to prevent
revealing their password to an attacker. These goals may be achieved
implicitly with a strong password-based protocol or explicitly. If
the server is identified explicitly, the user or client must ensure
that the user password is conveyed to a trusted server. This might
be achieved by installing appropriate trusted key(s) in the client.
5.1.4. Non-repudiation
There are no requirements upon the SACRED protocol itself to support
non-repudiation, although the context in which the credentials are
being used may have such requirements.
5.2. Systems Security
Systems security is concerned with protection of the protocol
endpoints (i.e., the client and server) and information stored at the
server in support of the SACRED protocol.
5.2.1. Client Security
As with most security protocols, secure use of the client often
relies, in part, upon secure behavior by the user. In the case of a
password-based SACRED protocol, users should be educated, or enforced
through policy, to choose passwords with a reasonable amount of
entropy. Additionally, users should be made aware of the importance
of protecting the confidentiality of their account password.
In addition, the client interface should be designed to thwart
"shoulder surfing" where an attacker can observe the password as
entered by a user. This is often achieved by not echoing the exact
characters of the password when entered.
As well, the interface should encourage the entering of the password
in the appropriate interface field so that protections can be
properly enforced. For example, a user should be guided to not
mistakenly enter their password in the "username" field (since their
password would likely be echoed to the screen in this case, and might
not be encrypted when communicated to the server). This might be
accomplished via the automatic insertion of the user name or several
user name choices in the appropriate on-screen dialog field, for
example.
5.2.2. Client Security, TLS Server Authentication
When TLS is used as the SACRED transport protocol, the client
interface should be designed to allow the user to verify that she is
connected to the intended credential server. For example, client
software should allow for the visual display of identifying
components from the TLS server's X.509 certificate, like the server's
name, the certificate fingerprint, etc.
Users should be guided to verify this information regularly, allowing
ready recognition of trusted credential servers. In addition, users
should be made aware of the importance of verifying their credential
server's identity before initiating any credential exchange
operations.
A SACRED client SHOULD only be configured with those SACRED trust
anchors that are to be used by the client. Re-use of trust anchors
from other applications, e.g., Internet browsers is NOT RECOMMENDED.
5.2.3. Server Security
Password verifiers and user credentials must be afforded a high level
of protection at the credential server. In addition to salting and
super-encrypting each (to ensure resistance to offline dictionary
attacks), a system should ensure that credential server keys are
protected using sufficient procedural and physical access controls.
The login to the credential server should be resistant to replay
attacks.
Online attempts to access a particular user account should be
controlled, or at least monitored. Control might be enforced by
incorporating a time delay after a number of unsuccessful logins to a
particular account, or possibly the locking of the account
altogether. Alternatively, one might simply log unsuccessful
attempts where an administrative notice is produced once a threshold
of unsuccessful credential access attempts is reached.
5.2.4. Denial of Service
As with most protocols, Denial of Service (DoS) issues must also be
considered. In the case of SACRED, most DoS issues are a concern for
the underlying transport protocol. However, some concerns may still
be mitigated.
Service to a user might be denied in case their account is locked
after numerous unsuccessful login attempts. Consideration of
protection against online attacks must therefore be considered (as
described above). Proper user authentication should ensure that an
attacker does not maliciously overwrite a user's credentials.
Credential servers should be wary of repeated logins to a particular
account (which also identifies a possible security breach, as
described above) or abnormal volumes of requests to a number of
accounts (possibly identifying a DoS attack).
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3157] Arsenault, A. and S. Farrell, "Securely Available
Credentials - Requirements", RFC 3157, August 2001.
6.2. Informative References
[BM92] Bellovin, S. 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] Bellovin, S. and M. Merritt, "Augmented Encrypted Key
Exchange: a Password-Based Protocol Secure Against
Dictionary Attacks and Password File Compromise, ATT Labs
Technical Report, 1994.
[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.
[RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol-- HTTP/1.0", RFC 1945, May 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter,
L., Leach, M. and 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.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", September 1996.
7. Authors' Addresses
Dale Gustafson
Future Foundation Inc.
EMail: degustafson@comcast.net
Mike Just
Treasury Board of Canada, Secretariat
EMail: Just.Mike@tbs-sct.gc.ca
Magnus Nystrom
RSA Security Inc.
EMail: magnus@rsasecurity.com
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
ISO Plain Language
On this page
§1The Problem: Credentials on Many Devices
Digital credentials, such as private keys and corresponding certificates, are used to support various Internet protocols, for example 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 and export of these credentials, but this is not very practical. In addition, with some devices, especially wireless and other more constrained devices, the tools required simply do not exist.
The document proposes a general framework for the secure exchange of such credentials and provides a high-level outline to guide the development of one or more securely available credentials, or SACRED, credential exchange protocols. The requirements for SACRED are fully described in RFC 3157, and they assume that two distinctly different network architectures will be created to support credential exchange for roaming users: client/server credential exchange and 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 are used to ensure credentials are not divulged to unauthorised parties. Adequate server authentication methods are used to ensure that each client's authentication information is not compromised, and that roaming users interact with the intended and authorised credential servers.
The framework answers a practical problem: a person has a private key on one machine and wants to use it on another, and the usual copying tools are clumsy or missing. The framework puts the key on a server and defines a careful way to fetch it.
§2.1The Vocabulary
The document defines the terms it uses. Client authentication information is the information a client presents to a server to authenticate itself, and it may include a password token, a registration string received out of band and possibly used for initially registering a roaming user, or data signed with a signature key belonging to the client. Credentials are the cryptographic objects and related data used to support secure communications over the Internet, and they may consist of public and private key pairs, symmetric keys, X.509 public key certificates, attribute certificates, or application data. A passkey is a symmetric key derived from a password, a password is a string of characters known only to a client, and a password token is a value derived from a password using a one-way function, for example a one-way hash.
Secured credentials are credentials that have been cryptographically secured, for example encrypted or MACed with a passkey. They may be protected with more than one layer of encryption: the credential is secured with a passkey corresponding to the user's password and also by a key known only to the server, which is the credential's stored form, and during network transfer the passkey-protected credential may be protected with an additional encryption layer using a symmetric key chosen by the credential server, which is the transmitted form.
A strong password protocol authenticates clients to servers securely, where the client needs to memorise only a small secret and carries no other secret information, and the server carries a verifier, the password token, which allows it to authenticate the client. A shared secret is negotiated between client and server and used to protect the data exchanged afterwards.
The document distinguishes an account password from a credential password. The account password, and its password token, authenticates to the credential server and negotiates a key that provides session-level encryption between client and server. The credential password is used to derive a passkey that provides persistent encryption and authentication for a stored credential. Although the same password value may be used for both, different algorithm-specific passkeys are likely to be generated from it, because of different salt values, and differing security policies between the credential server and the credential issuers may mean a user has to remember more than one password.
The document is careful about words that are easily confused. One password opens the account and protects the conversation, another protects the stored key itself. The key is encrypted twice: once with something derived from the user's password, and once with a session key that exists only during the exchange.
§2.3Client, Credential Server and Credential Store
Three components take part. The client is the entity that wants to retrieve its credentials from a credential server. The credential server downloads secure credentials to the client and uploads them from it; it is responsible for authenticating the client so that secured credentials are exchanged only with an appropriate end user, and it is itself authenticated to the client so that the client's authentication information is not compromised and the user can trust the credentials retrieved. The credential store is the repository for secured credentials. It may have access control features, but those generally are not sufficient in themselves for securing credentials, and the credential server may be capable of splitting credentials across multiple stores for redundancy or for additional protection.
Three protocols connect them. Protocol 1 is used to authenticate the client and the credential server and to download and upload user credentials between them. Protocol 2 is used by the credential server to store and retrieve user credentials, with LDAP, LDAP over SSL or other mechanisms. Protocol 3 is used by the client to store and retrieve user credentials from the credential store, again with LDAP or other mechanisms. The framework describes the high-level design for protocol 1; protocols 2 and 3 are closely related but out of scope and could be implemented with standard protocols. Administrator and credential server protocols are assumed to be server vendor specific and are not the subject of SACRED standardisation at this time.
Clients are not precluded from exchanging credentials directly with a credential store, or with any other server of its choosing, but mutual authentication with roaming users and a consistent level of protection for credential data while stored on network servers and in transit is provided by the SACRED protocols exchanged with the credential server. Depending on the design of the credential server, user credentials may flow through the credential server to the store or directly between the client and the store. Users may also upload their credentials to several credential servers to obtain enhanced availability, and the automatic replication of user information or credential data among several credential servers is beyond the scope of the document.
There are three parties. The device asks, the credential server checks who is asking, and the credential store keeps the protected keys. The exchange between device and server is the part the document designs; how the server reaches the store is left to standard directory protocols.
- ClientThe device that wants to retrieve its credentials from a credential server.
- Credential serverAuthenticates the client, is itself authenticated to the client, and moves protected credentials to and from it.
- Credential storeThe repository for secured credentials. It may hold access control, but that alone does not secure them.
- Protocol 1Between client and credential server: mutual authentication and the download and upload of credentials. This is the part the document designs.
- Protocol 2Between the credential server and the credential store, for example LDAP or LDAP over SSL.
- Protocol 3Between the client and the credential store, for example LDAP or LDAP over SSL.
§3GET, PUT and DELETE
The client/server credential exchange protocol is based on three basic and abstract operations: GET, PUT and DELETE. The exchange runs through a sequence of steps: connect, where the client initiates a connection to a credential server for the purpose of secure credential exchange; mutual authentication and key negotiation, where 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; client requests, which are one or more high-level credential exchange requests; server responses, in which the server performs the operation or indicates an error; close, where the client indicates it has no more requests and the security context is no longer needed; and disconnect, where the parties disconnect the transport connection. Each high-level operation is a series of request and response pairs, and each request must complete before the client issues the next.
Three kinds of value appear in the protocol. SC-x is the secured credential file, which includes a format identifier field and credential data, where the credential data is an opaque encrypted object such as a PKCS#15 or PKCS#12 file. Name-x is an account-defined selector or locator, a user friendly name, used to indicate a specific secured credential; the names stored under a given user account must be unique, and when no name is supplied for a GET operation all credentials stored for that username are returned. ID-x is a distinct credential version indicator that may be used to request a conditional GET, PUT or DELETE; it should contain the server's last-modified date and time and may contain additional information such as a sequence number or a credential fingerprint.
The upload operation, implemented with PUT, lets a client register new credentials or replace currently stored ones, for example credentials updated by the client using key management software. The client and server establish a mutually authenticated session and negotiate a shared secret, the client issues a PUT message containing the upload credential and related data fields, and the server responds saying whether the credential was stored or an error occurred. If the PUT carries an optional credential-ID, the new credential is only stored if a credential with the same name and credential-ID is currently stored, which is a logical replace operation, and the server must return an error if the client tries to replace a credential that does not exist. The response to a PUT must contain a credential version identifier for the newly stored credential.
The download operation, implemented with GET, is how a roaming client gets its credentials after they have been uploaded. The client should authenticate the server, the user must be authenticated by the server, the client issues a GET request, and the response contains the credential and its format identifier. If the client includes a credential-ID, the request is conditional: the server returns the credential only if the identifier of the credential currently stored does not match the one supplied, and otherwise returns a distinct response saying the conditional download was not performed.
The removal operation, implemented with DELETE, requires the credential server to be authenticated by the client and the user by the server. The user then sends a DELETE request containing the credential name, and may include a credential-ID so that the credential is deleted only if the request identifier matches the one currently stored, which stops a client from deleting a different version by mistake. Together the three operations can perform the basic credential management tasks of adding a new credential on the server, updating or replacing an existing one, and deleting an existing one, and their information can guide more complex operations such as user registration, deregistration, changing an account password, or listing all credentials. Uploading a NULL credential where a credential with the same name exists is logically equivalent to removing the previously stored credential.
Three verbs do the work: upload a key, fetch a key, and remove a key. Each request carries an optional version marker, so a client can ask for a key only if it has changed, or delete a key only if it is the version the client thinks it is.
- PUTCredential upload — Registers new credentials or replaces stored ones. The server answers with the new version identifier.
- GETCredential download — Fetches a stored credential by name. With a version identifier it becomes a conditional download.
- DELETECredential removal — Removes a stored credential by name, optionally only if the version identifier matches.
- connectThe client opens a connection for secure credential exchange.
- mutual authenticationBoth ends prove who they are and a session key is negotiated.
- GET Name-1The client asks for the credential called Name-1.
- SC-1, ID-1The server returns the secured credential and its version identifier.
- GET Name-2, ID-2The client asks for another credential, this time conditionally.
- No credentialThe version identifier matches, so nothing is sent back.
- closeThe client ends the session and the security context is dropped.
§4.2How the Two Ends Prove Who They Are
Authentication is vitally important, so that credentials are accepted from and delivered to the authorised end user only. If an unsecured credential is delivered to another party it may be more easily compromised, and if a credential is accepted from an unauthorised party the user might be tricked into using one that has been substituted by an attacker, for example an older credential of the same user put back in place. Ideally the list of authentication methods should be open ended, and for all credentials the user authentication method and data is defined when a user is first registered with the credential server and may be updated later by the authorised user.
At a minimum, each SACRED authentication method should ensure that the server authenticates the client, the client authenticates the server, the two securely negotiate or derive a cryptographically strong secret key such as a session key, and the exchange of one or more user credentials is protected using that session key.
Strong password protocols may be used to provide mutual authentication and privacy. They require user-specific values, a password token and related values, to be configured within the server, and only a party who knows the password can calculate the verifier value. At connect time messages are exchanged and complementary algorithms compute a shared common value known only to the legitimate user and the server, and both derive a strong symmetric key that may be used to secure the communications.
TLS authentication may be mutual or unilateral, where only the server is authenticated to the client. With server authentication, TLS provides a secure session in which the client authenticates the server and a pair of session level encryption keys is exchanged, after which all client requests and server responses are integrity and privacy protected. The document warns that the flexibility of certificate-based server authentication creates risks that need to be mitigated, notably the need to ensure the user is connected to the intended credential server and no other, and that a faulty implementation of increasingly complex TLS server certificate chain processing could allow a credential server masquerade or a man-in-the-middle attack. It also warns that simple layering of independently developed security protocols produces a complex multilayer protocol that might be defeated by a combination-specific attack.
With TLS client authentication, the server can request client authentication by verifying the client's digital signature, and the client must be configured with at least one security credential acceptable to the server. Other authentication methods with the necessary capabilities may also be suitable.
For the transport, one or more underlying protocol stacks may carry the credential exchange protocols, and although the use of several suites is not ideal for interoperability it may be required. The suites considered are TCP, which needs a custom credential exchange messaging protocol but gives exactly the functionality needed and no more, and most environments already provide the socket API; BEEP, which provides general-purpose peer-to-peer message exchange over several transport mechanisms and supplies the user authentication, session security and session management needed; and HTTP, which provides general purpose typing and negotiation of data representation and is available in a wide variety of server and client platforms, including portable devices, and can be used with TLS for authenticated session-level security.
The document lists what any authentication method must achieve: both ends prove who they are, and a fresh key is agreed for that session. It then compares the candidates, from a password-based protocol through TLS, and the transports they could run over.
§5Security Considerations
The security considerations identify general observations and precautions for a framework supporting credential mobility, and a designer should also consult the security considerations in the SACRED requirements document.
On communications security, the password or password verifier should be protected when communicated from the client to the credential server, and the communicated value should resist a dictionary attack; the entity credentials must be confidentiality protected in both directions, with the same resistance to dictionary attack. Communication integrity between client and credential server is required, so that intended client operations cannot be altered, for example from an update to a deletion of credentials, nor may clients be maliciously given old credentials, for example by an attacker replaying a previous credential download. Proper authentication of the client and the server is required to achieve confidentiality and integrity: the server must authenticate the client so that credentials are not mistakenly revealed to an attacker, and the client must ensure the proper identification of the credential server so as to prevent revealing the password to an attacker. There are no requirements on the SACRED protocol itself to support non-repudiation, although the context in which the credentials are used may have such requirements.
On systems security, secure use of the client often relies in part on secure behaviour by the user. Users should choose passwords with a reasonable amount of entropy and protect the confidentiality of their account password, and the client interface should be designed to thwart shoulder surfing, often by not echoing the exact characters of the password as it is entered. When TLS is used, the client interface should let the user verify that she is connected to the intended credential server, for example by displaying identifying components of the server's X.509 certificate such as its name and fingerprint, and a SACRED client should only be configured with the trust anchors it is to use; re-use of trust anchors from other applications such as Internet browsers is NOT RECOMMENDED.
On the server, password verifiers and user credentials must be afforded a high level of protection, with salting and super-encrypting each to ensure resistance to offline dictionary attacks, and credential server keys protected using sufficient procedural and physical access controls. The login should be resistant to replay attacks, and online attempts to access a particular user account should be controlled or at least monitored, for example by delaying or locking the account after a number of unsuccessful logins, or by logging unsuccessful attempts so that an administrative notice is produced once a threshold is reached. Denial of service issues must also be considered: most are a concern for the underlying transport, but service to a user might be denied if the account is locked after numerous unsuccessful logins, and credential servers should be wary of repeated logins to a particular account or of abnormal volumes of requests to many accounts.
The security rules cover the conversation and the machines at both ends. The key must be protected in transit and at rest, the user must be able to tell which server they are talking to, and the server should lock or watch accounts that are being guessed at.