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