Sacred Working Group D. Gustafson
INTERNET-DRAFT Future Foundation
Expires May 2001 M. Nystrom
RSA Security
November 2000
Securely Available Credentials - Framework
draft-ietf-sacred-framework-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright (C) The Internet Society (2000). 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 draft responds to the
requirements listed in [SACRED}. It presents a strawman framework and
outlines protocols for securely available credentials.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
Please send comments on this document to the ietf-sacrede@imc.org
mailing list.
Gustafson & Nystrom Expires: May 2001 [Page 1]
INTERNET DRAFT SACRED - Framework November 2000
Table of Contents
1. Introduction 2
2. Functional Overview 3
2.1 Client/Server Network Architecture 4
2.2 Peer-to-Peer Network Architecture 4
3. Protocol Framework 5
3.1 Client/Server Protocol 5
3.1.1 Credential Upload 5
3.1.2 Credential Download 7
3.1.3 Credential Removal 8
3.1.4 Credential Management 9
3.2 Peer-to-Peer Protocol 10
4. User Authentication Methods 10
4.1 One-time Password (OTP) Algorithms 10
4.2 Strong Password Algorithms 11
4.3 TLS Remote Client Authentication 11
4.4 Conclusions 11
5. Credential Formats 12
5.1 A note on interoperability 12
5.2 PKCS #12 12
5.3 PKCS #15 12
6. Open Issues 13
7. Security Considerations 13
8. References 13
9. Author's Addresses 14
10. Full Copyright Statement 15
1. Introduction
Private credentials are used to support various Internet protocols,
e.g. S/MIME, IPSec, and TLS. In a number of environments end users
wish to use the same set of private credentials from different end
user equipment. In a "typical" desktop environment, the user already
has many tools available to allow import/export of these credentials.
However, with some devices, especially wireless and other more
constrained devices, the tools required simply do not exist.
This draft proposes a general framework for secure exchange of user
credentials and provide an outline of a protocol to meet requirements
stated in [SACRED].
<<editorial comments are in angle brackets, like this>>
Gustafson & Nystrom Expires: May 2001 [Page 2]
INTERNET DRAFT SACRED - Framework November 2000
2. Functional Overview
Requirements for Securely Available Credentials are fully described
in [SACRED]. These requirements assume that two distinctly different
network architectures will be supported to exchange credentials
between different end user systems:
a) Client/Server Credential Exchange
b) Peer-to-Peer Credential Exchange
These requirements also assume that, in all cases, adequate user
authentication methods will be used to ensure credentials are not
divulged to unauthorized parties.
A security credential consists of cryptographic objects and related
data that are needed to support secure communications over the
Internet, such as:
- public/private key pairs
- secret keys
- x.509 public key certificates
- attribute certificates
- application data
Since the credential usually contains sensitive information that is
known only to the credential holder, such information MUST be
encrypted during network transmission and SHOULD be encrypted when
stored on an end user device such as a diskette or hard drive. These
security 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.
Logically, there is no limit to the number of data objects that may
be included within a credential or the number of credentials that may
be utilized by any particular end user. Throughout this document we
assume that a 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, the end user system may,
optionally, store its credential information on other special
hardware devices that provide additional portability and protection.
Gustafson & Nystrom Expires: May 2001 [Page 3]
INTERNET DRAFT SACRED - Framework November 2000
2.1 Client/Server Network Architecture
The network diagram below shows the components involved in the sacred
client/server framework. The numbers refer to protocols that already
exist or will be described in this document.
+--------+ +------------+
| Client +-----------| Credential |
+--------+ 1. | Server |
\ +-----+------+
\ |
3.\ | 2.
\ |
\ +-----+------+
+-----| Repository |
+------------+
Client: The entity that wants the credential.
Credential Server: The server that downloads credentials to and
uploads them from the client. The server
is responsible for authenticating the client
to ensure credentials are exchanged only
with end users who are allowed to use them.
Repository: Where the credentials are stored. The
repository might have access control features
but those generally aren't sufficient in
themselves for protecting credentials.
Protocol 3 is, likely, not supported
by all clients.
Protocol 1: The protocol used to download and upload
user credentials from a credential server.
Described in this document.
Protocol 2: The protocol used to store and retrieve
user credentials in a repository (LDAP,
LDAP/SSL, or other).
Protocol 3: The protocol used by the client to exchange
credentials (upload or download) directly
with a credential repository (LDAP or
LDAP/SSL).
2.2 Peer-to-Peer Network Architecture
<<TBS - Add a picture and description of a peer-to-peer connection>>
Gustafson & Nystrom Expires: May 2001 [Page 4]
INTERNET DRAFT SACRED - Framework November 2000
3. Protocol Framework
This section provides a high level description of client/server and
peer-to-peer protocols that can be used to exchange and manage SACRED
credentials.
3.1 Client/Server Protocol
The client/server credential exchange protocol is based on three
basic and abstract operations; "GET", "PUT", and "DELETE". For all
client/server protocol messages it is assumed that:
- credential servers MUST NOT be presented with credentials (e.g, a
sensitive object such as a private key) in plaintext form
- all user, credential server communications MUST be able to use
HTTP [RC2616] over TLS [RC2246]
- when TLS is used, only cipher suites providing strong
confidentiality MAY be used
While the following sections assume the use of HTTP over TLS
transport service other transport protocol options are certainly
feasible.
3.1.1 Credential Upload
The framework for credential upload (PUT operation) is:
- the credential server MUST be authenticated, that is only TLS
cipher suites providing strong confidentiality and server
authentication MAY be used
- prior to credential upload, the user SHOULD be authenticated (by
the server) using a method-dependent protocol sequence
- the user then sends a PUT message that contains the credentials
and other required information
- upload of credentials can either be authenticated, or
unauthenticated
- if credential upload is unauthenticated, the PUT data MUST include
information which will be used for user authentication during
download, this information may take various forms
<<Note: In this case, PKI credentials could be used for user
authentication, this will however probably not be possible for
downloads>>
The credential server should determine whether user authentication is
required. Whenever necessary, the remote user MUST be authenticated.
The user authentication protocol exchange is method-dependent and
Gustafson & Nystrom Expires: May 2001 [Page 5]
INTERNET DRAFT SACRED - Framework November 2000
will typically involve the exchange of several messages between
client and server. See Section 4 of this document for more detailed
information on user authentication methods.
The user then issues a "PUT" command containing the credential upload
message. This message contains the following data fields:
- Credential Format ID and Data
The user's protected credential and a format identifier that is
needed to parse the credential after it has been downloaded.
- Download Authentication Method ID and Data
The authentication data and an identifier that specifies how
the user will authenticate to the server for downloads.
The credential server's response to this PUT message SHOULD contain
an identifier of the (version of the) credential, which MAY be used
to optimize later downloads. Note that this message format allows
each credential stored on the server to be protected by a different
password.
The TLS protocol provides an "encrypted tunnel" that protects the
data only during transmission between client and server. The client
MAY provide an additional layer of encryption (as defined by the
credential format) to ensure the credential is not exposed within the
credential server or repository.
The "credential upload" protocol sequence is:
client server
------- --------
connect -->
...
< auth-0 > -->
<-- < auth-1 >
< auth-2 > -->
...
<-- < auth-n >
< cred-1 > -->
<-- < cred-1 URL, ID >
< cred-2 > -->
<-- < cred-2 URL, ID >
Gustafson & Nystrom Expires: May 2001 [Page 6]
INTERNET DRAFT SACRED - Framework November 2000
...
< done > -->
<-- OK (+ connection dropped)
where,
{ auth-0 ... auth-x } is the method-dependent user authentication
sequence.
Cred-x URL is a locator that can be used to access the credential for
download.
Cred-x ID is an indicator that may be used for conditional download
(e.g. http/1.1 "if modified-since")
<< For extensibility, we use the connection as if it were a point-to-
point link. Should work well for arbitrary links and transports --
is this appropriate for a TLS connection? >>
3.1.2 Credential Download
The framework for a credential download (GET operation) is:
- TLS server authentication SHOULD be used to authenticate the
server
- the user MUST be authenticated (by the server) using a method-
dependent protocol sequence
- a GET request for the credential download is issued
- the response contains the credential and format identifier
The specific user credential being requested is identified in the
message sent to the credential server. If successful, the response
MUST contain the requested credential data element (format ID and
data) as defined above.
Optionally, the user agent MAY include a previously obtained
fingerprint (see above) to find out if a download is necessary. If
the server finds that the credential has not been modified, it MAY
indicate this in its response.
The "credential download" protocol sequence is:
client server
------- --------
connect -->
...
Gustafson & Nystrom Expires: May 2001 [Page 7]
INTERNET DRAFT SACRED - Framework November 2000
< auth-0 > -->
<-- < auth-1 >
< auth-2 > -->
...
<-- < auth-n >
< GET cred-1 URL
[Fingerprint]> -->
<-- < GET response 1 (credential-1) >
< GET cred-2 URL
[Fingerprint] > -->
<-- < GET response 2 (credential-2) >
...
< done > -->
<-- OK (+ connection dropped)
where,
{ auth-0 ... auth-x } is a method-dependent user authentication
sequence.
cred-x URL is a locator for a specific credential. Each download
request may be conditional.
<< Issue: We need to decide if uploading and downloading multiple
credentials needs to be included. Implies that multiple credentials
are accessed using a common authentication method and password rather
than maintaining a separate password for each. >>
3.1.3 Credential Removal
The framework for credential removal (DELETE operation) is:
- the credential server MUST be authenticated, that is only TLS
ciphersuites providing strong confidentiality and server
authentication MAY be used
- the user MUST be authenticated (by the server) using a method-
dependent protocol sequence
- the user then sends a DELETE message that contains the credential
Identifier indicating which credential to remove.
The "credential removal" protocol sequence is:
Gustafson & Nystrom Expires: May 2001 [Page 8]
INTERNET DRAFT SACRED - Framework November 2000
client server
------- --------
connect -->
...
< auth-0 > -->
<-- < auth-1 >
< auth-2 > -->
...
<-- < auth-n >
< DEL cred-1 URL > -->
<-- < cred-1 deleted >
< DEL cred-2 URL > -->
<-- < cred-2 deleted >
...
< done > -->
<-- OK (+ connection dropped)
where,
{ auth-0 ... auth-n } is a method-dependent user authentication
sequence.
cred-x URL is a locator for a specific credential.
3.1.4 Credential Management
Note that the three basic operations defined above (GET, PUT, DELETE)
can be used to perform the necessary management operations:
- create a new credential on the server
- update an existing credential
- delete an existing credential
- change password
The credential is an opaque (encrypted) data object with user defined
format. Section 5 mentions some possible credential formats.
However, no credential format is excluded in this memo. There is no
restriction on the data that may be included in a user credential or
the credential storage format seen by the server.
Gustafson & Nystrom Expires: May 2001 [Page 9]
INTERNET DRAFT SACRED - Framework November 2000
3.2 Peer-to-Peer Protocol
<< TBS - define the peer-to-peer protocol >>
4. User Authentication Methods
User authentication is vitally important to ensure that credentials
are accepted from and delivered to the authorized end user only. If
a credential is delivered to some other party, the credential may be
more easily compromised. If a credential is accepted from an
unauthorized party, the user might be tricked into using a credential
which was substituted by an attacker.
Ideally, the list of authentication methods should be open ended,
allowing new methods to be added as needs are identified and as new
methods become available. For all credentials, the user
authentication method/data is defined when the credential is first
stored on the server and may be updated from time to time thereafter
by the authorized user.
The following classes of user authentication methods are applicable
(at different times) to the credential exchange protocols described
earlier:
- one-time password (OTP)
- strong password
- TLS client authentication
4.1 One-time Password (OTP) Algorithms
RFC 2289 [RFC2289] describes a password-based authentication method
that protects the user's password from eavesdroppers. The client and
server disguise the secret pass-phrase by using it to generate a
sequence of one-time (single use) passwords each of which cannot be
derived from any previously used OTP. With OTP, the user's secret
pass-phrase never crosses the network and is not vulnerable to replay
attacks. In addition, since each OTP is (effectively) a hash of the
password, no secret information need be stored on any system. The
user's password canot be derived from any of the OTPs that might be
stored on a server.
RFC 2444 [RFC2444] describes a One-Time-Password SASL (Simple
Authentication and Security Layer) mechanism that provides a formal
way to integrate OTP into SASL-enabled protocols such as IMAP, ACAP,
POP3 and LDAPv3.
Gustafson & Nystrom Expires: May 2001 [Page 10]
INTERNET DRAFT SACRED - Framework November 2000
4.2 Strong Password Algorithms
Strong password algorithms (e.g. [RFC2945], [PRANDOM], [SPEKE]) may
be used to authenticate clients to servers securely, in cases where
the client must only memorize a small secret (like a password) and
carries no other secret information, and where the server carries a
verifier which allows it to authenticate the client but which, if
compromised, would not allow someone to impersonate the client.
Strong password methods require that user-specific information (e.g.,
a "verifier", which is derived from the user's password) be
configured within the server. This verifier value can only be
calculated by a party who knows the password (the user) and must be
securely delivered to the server. At connect time, messages are
exchanged between the two parties and complementary algorithms are
used to compute a common value that can be used to verify the user's
password (even though the password is never divulged). Both parties
also derive a strong (symmetric) key that could be used to secure
subsequent communications between the two parties.
Kaliski and Ford [ROAMING] have suggested that an attacker who is
able to gain access to "password verifier" value(s) can easily derive
the user's password by mounting a dictionary attack against the
verifier. They suggest that the verification function should be
spread across multiple servers since several servers are less likely
to be compromised, at the same time, than any single server. Doing
so would provide another level of protection for user passwords.
4.3 TLS Remote Client Authentication
A web server application can (optionally) request that the remote
client authenticate to the server using a digital signature. In this
case, the server requests client authentication and issues a random
challenge which is signed and returned (with the client's certificate
chain) by the client. The user is strongly authenticated if the
digital signature can be verified.
TLS client authentication is not possible when the client currently
has no credentials that are suitable for use with TLS.
4.4 Conclusions
- User passwords need never be stored "in the clear" on credential
servers.
- Credential servers SHOULD first request TLS remote client
authentication whenever it is necessary to establish the identity
of credential users.
- If client authentication is not possible (e.g., the user currently
Gustafson & Nystrom Expires: May 2001 [Page 11]
INTERNET DRAFT SACRED - Framework November 2000
has no valid credentials), a strong password should be used to
authenticate the user.
- In all cases, a different password should be used to derive the
secret key used protect the credential data per se. The key
derivation formula should maximize the effort needed to mount a
dictionary attack on the credential password (given a copy of the
credential).
- The effective level of protection afforded user passwords, no
matter how they are transformed by one-way hash operations, etc.
is directly proportional to how well passwords or their derived
values are protected by the server.
- It is expected that credential users will make use of physical
security or additional encryption layers (or both) to further
protect their credentials, whenever appropriate.
5. Credential Formats
5.1 Background
In order to ensure that credentials created on, and uploaded from,
one device are possible to download to, and be used on, another
device, there is a need to mandate support for at least one
credential format. This section describes two possible candidate
formats, both unencumbered. While other formats (and even new ones)
certainly are conceivable, it appears as if selection of an existing
format offers the best approach.
<<An accompanying document, describing the SACRED protocol in detail,
should/will also mandate a credential format.>>
5.2 PKCS #12
PKCS #12 [PKCS12] provides a transfer syntax for personal identity
information, including private keys, certificates, and miscellaneous
secrets. It is widely used and would therefore constitute a natural
choice for a mandated SACRED credential format.
5.3 PKCS #15
PKCS #15 [PKCS15] specifies a file and directory format for storing
security-related information on cryptographic tokens (which are
defined as portable devices capable of storing persistent data). PKCS
#15 has seen its main use as a smart card application where it
facilitates interoperability and credential portability. Among things
speaking in favor of PKCS #15 are:
- Capable of carrying more certificate types (e.g. WAP WTLS [WTLS]
certificates]
Gustafson & Nystrom Expires: May 2001 [Page 12]
INTERNET DRAFT SACRED - Framework November 2000
- Capable of carrying "raw" public keys
- Standardized set of secret key types
Among things speaking against selection of PKCS #15 as SACRED's
mandated credential format are:
- The software token format has recently been defined and is not
widely used
6. Open Issues
This document is intended to foster further discussion of the
framework and protocols that might be used to support credential
mobility. However, the authors recognize that there are many issues
that remain to be resolved. Some of the most pressing are (in
addition to those mentioned in [SACRED]:
-Flexibility: Users should be able to access their credentials from
any device using any supported authentication method
-Peer-to-Peer protocol: not described
-The possibility of coupling (or not coupling) credential protection
to the security provided by transport protocols has not been
discussed
-Is the triplet <PUT, GET, DELETE> enough for now?
-Authentication for download - http/1.1 is not very flexible here
7. Security Considerations
The Security Considerations section of [SACRED] applies to this memo
as well. In particular, and as mentioned in [SACRED], mobile
credentials will never be as secure as tamper-resistant hardware
solutions. However, reasonable security may be accomplished through
some relatively simple means, as outlined above and in [SACRED].
For uploads, if the user is not authenticated, the server MUST make
sure not to accidentally overwrite another users' credentials.
For downloads, if the server is not authenticated, the user MUST be
aware of risks associated with this fact.
8. References
[SACRED] Arsenault, A., Farrell, S., "Securely Available
Credentials - Requirements", Internet Draft
<draft-sacred-reqs-00.txt>, November 2000.
[PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax",
RSA Laboratories, June 24, 1999
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Gustafson & Nystrom Expires: May 2001 [Page 13]
INTERNET DRAFT SACRED - Framework November 2000
Standard", RSA Laboratories, June 2000.
[RFC2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC 2026, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0," RFC
2246, January 1999.
[RFC2289] Haller, N., Metz, P., Nesser, P., & Straw, M., "A One-Time
Password System", RFC 2289.
[RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC
2444, November 1997.
[RFC2616] R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter,
Leach, 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.
[PRANDOM] Perlman, R., Kaufman, C., "Strong Password-Based
Authentication Using Pseudorandom Moduli", Internet Draft
<draft-perlman-strong-pass-00.txt>, June 2000.
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", September 1996
[ROAMING] Ford, W., Kaliski, B., "Server-Assisted Generation of a
Strong Secret from a Password", June 2000.
[WTLS] WAP, "Wireless Application Protocol - Wireless Transport
Layer Security Specification," Approved version
18-Feb-2000.
9. Author's Addresses
Dale Gustafson
Future Foundation
Eagan, MN 55122
USA
tel: +1 651-452-8369
email: dale.gustafson@bpsi.net
Magnus Nystrom
RSA Security
Box 10704
121 29 Stockholm
Sweden
tel: +46 8 725 0900
email: magnus@rsasecurity.com
Gustafson & Nystrom Expires: May 2001 [Page 14]
INTERNET DRAFT SACRED - Framework November 2000
10. Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. In addition,
the ASN.1 module presented in Appendix B may be used in whole or in
part without inclusion of the copyright notice. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process shall be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Gustafson & Nystrom Expires: May 2001 [Page 15]
