Internet DRAFT - draft-farrell-sacred
draft-farrell-sacred
INTERNET-DRAFT S. Farrell
Expires: January 2001 Baltimore Technologies
M. Nystr÷m
RSA Security
July 2000
Securely Available Credentials
<draft-farrell-sacred-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].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
As the number, and more particularly the number of different types,
of devices, connecting to the Internet increases, credential
mobility becomes an issue for IETF standardization. This draft
presents some requirements, a strawman framework and outlines a
protocol for securely available credentials.
Table Of Contents
Status of this Memo.............................................1
Abstract........................................................1
Table Of Contents...............................................1
1. Introduction.................................................2
2. Requirements.................................................2
3. Framework....................................................3
4. Outline Protocol.............................................5
5. A "strong" password scheme...................................5
6. Open Issues..................................................6
7. Security Considerations......................................7
8. References...................................................7
Author's Addresses..............................................7
Full Copyright Statement........................................8
Farrell & Nystr÷m [Page 1]
INTERNET-DRAFT July 2000
1. Introduction.
Private credentials are used to support various Internet protocols,
e.g. S/MIME, IPSec, 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 leads to a high level requirement for protocol(s) that allow
these private credentials to be made available over the Internet.
Such credentials are highly sensitive, since they are the basis for
many of the security features of the Internet protocols referred to
above. There are therefore stringent security requirements that any
proposed protocol(s) must meet.
The typical credential envisaged here is often either the entirety
or just the private part of what is often called a personal security
environment or PSE [RFC2459]. Other forms of credential are of less
direct interest here.
Since the credential concerned may be required to be present in
order to use PKI based authentication mechanisms, we cannot rely on
such mechanisms, at least for "download" (towards the end user)
operations. Note also that since PSEs often include "root" CA
information, (as well as private keys), it may not be possible to
depend on PKI based authentication of network servers.
In the remainder of this draft we present a set of requirements,
propose a general framework and provide an outline of a protocol to
meet the requirements.
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC2119].
<<editorial comments are in angle brackets, like this>>
2. Requirements
The following requirements assume that the is a credential server
from which credentials are downloaded to the end user device, and to
which credentials are uploaded from an end user device.
1. Credential download (to end user) and upload (to credential
server) MUST be supported
2. Credentials MUST only be downloadable following user
authentication
3. Credential upload MAY require user authentication
4. Users MUST be able to manage their credentials stored on the
credential server <<not further developed so far>>
Farrell & Nystr÷m [Page 2]
INTERNET-DRAFT July 2000
5. The protocol(s) MUST support a range of user authentication
mechanisms
6. The protocol(s) MUST support a range of credential formats.
7. The protocol(s) MUST be extensible so as to be able to support a
wide range of end user devices, accessed using a range of
transport protocols
8. Different end user devices MAY be used to download/upload/manage
the same set of credentials
9. Credentials MUST be protected whilst in transit
10. The credential server MUST NOT have easy access to the cleartext
credentials
11. It MUST be possible to ensure the confidentiality/privacy of all
interactions between users and credential servers
12. Credential servers MUST be authenticated to the user for all
operations except (possibly) download
13. It MUST be possible to authenticate the credential server to the
user prior to download (if the user is able to verify the
authentication)
14. It MUST be possible to cache credentials locally on the end user
device without unnecessarily exposing the private parts of the
credential
15. The user SHOULD only have to enter a single secret value in
order to download a credential.
3. Framework
The diagram below shows the components involved in the sacred
framework. The numbers refer to protocols that may be defined.
+--------+ +------------+
| Client +-----------+ Credential |
+--------+ 1. | Server |
\ +-----+------+
\ |
3.\ | 2.
\ |
\ +-----+------+
+-----+ Repository |
+------------+
Client: The entity that wants the credential.
Credential Server: The server that knows how/who/when to give
the credential to the client.
Repository: Where the credentials are stored. The
repository
might have access control features but
those generally aren't sufficient in
themselves for protecting credentials.
Private information in credentials must be protected by encryption.
The key for this encryption can be derived from a password, but can
also be something stronger. As an example of a stronger method, one
Farrell & Nystr÷m [Page 3]
INTERNET-DRAFT July 2000
could consider the user authenticating to the credential store using
some strong authentication method (not requiring public-key
cryptography) and then downloading (over a confidentiality-protected
connection) not only the credentials but also (parts of) the key to
unlock the card. This way, the key used to protect the credentials
will not be derived from the user's password solely. Further, in
order to make it harder for a credential store administrator to find
out about users' private objects, the key stored at the operator's
server may be combined with a user-derived key to form an actual
key-encryption key.
Credentials must be integrity protected, since it would otherwise be
possible for an attacker to substitute parts of the credentials
(e.g. trusted certificates) with something more advantageous for the
attacker. Once again, the key for this integrity-protection may be
derived from a user password, but in this case, it could also be the
user's own private key (assuming that private objects on the token
are decrypted before the integrity check is done).
The basic framework is as follows:
- credential servers MUST NOT be presented with credentials in
cleartext form
- all user, credential server communications MUST use HTTP over TLS
- only TLS ciphersuites providing strong confidentiality MAY be used
The framework for uploads is as follows:
- the credential server MUST be authenticated, that is only TLS
ciphersuites providing strong confidentiality and server
authentication MAY be used
- the user sends a POST message with the POST data containing the
credentials and other required information
- upload of credentials can either be authenticated, or
unauthenticated, any authentication information (for the upload
operation itself) is carried inside the POST data
- the POST data MUST include information which will be used later
for authentication during download, this information may take
various forms
<<XML is just being used here for convenience, and may well be
replaced.>>
This upload message is described in the following XML DTD:
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT SacredUploadData (OperationAuthenticationData?,
DownloadAuthenticationData,
CredentialData)>
<!ELEMENT OperationAuthenticationData (#PCDATA) >
<!ATTLIST OperationAuthenticationData method ID #REQUIRED>
<!ELEMENT DownloadAuthenticationData (#PCDATA)>
<!ATTLIST DownloadAuthenticationData method ID #REQUIRED>
Farrell & Nystr÷m [Page 4]
INTERNET-DRAFT July 2000
<!ELEMENT CredentialData (#PCDATA)>
<!ATTLIST CredentialData format ID #REQUIRED>
OperationUploadData, if present, is intended to authenticate the
user for the upload operation. DownloadAuthenticationData, which
MUST be present, contains indicates how the user will authenticate
for subsequent downloads and contains method specific data.
CredentialData contains the format information and the actual
credential itself.
The HTTP response to this POST message SHOULD be a text/html page
containing a HREF, which indicates URL from which the credential MAY
subsequently be downloaded.
The download operation is as follows:
- HTTP authentication is used to authenticate users to credential
servers(*)
- a simple GET request for the download URL is issued
- the HTTP response contains the credential and information about
the credential format
(*) This assumes that an HTTP SASL authentication scheme is defined
in addition to the current HTTP Basic and Digest authentication
schemes [RFC2617]. Work on such a scheme is on-going [<<REF>>].
The HTTP response MUST contain a CredentialData element as defined
in the above DTD.
<<management operations are TBS>>
4. Outline Protocol
In terms of the framework above, the specific protocol proposed as
mandatory to implement requires support for:
- OTP [RFC2289] and, optionally, S/KEY [RFC1760] for user
authentication
- uploads are unauthenticated and contain the OTP or S/KEY username
for downloads, and optionally the pass-phrase in the
DownloadAuthenticationData
- PKCS#15 [PKCS#15] is the credential format <<profile TBS>>
- the OTP (or S/KEY) passphrase is completely separate from any
password based encryption keys used to protect the PKCS#15
credential <<this breaks requirement 15 above, but can be fixed
later>>
5. A "strong" password scheme
In this section we present an idea for a "strong" password scheme.
The idea here is to tie down the "MUST" implement mechanisms for the
framework. <<NOTE: For now, this scheme is merely illustrative,
before being adopted it would have to be checked out in detail.>>
Farrell & Nystr÷m [Page 5]
INTERNET-DRAFT July 2000
Assumption: User has credential Cd.
To secure a credential:
Idea is to hash Cd and derive both a key and a password from the
hash. The security of the key/password derivation is driven by a
"level" (number of bits of hash used to derive password).
H=hash(Cd)
K=fold(H,level)
PWD=password-generator(K)
secured-credential=encrypt(K,Cd)
password-generator can be the OTP six word picker scheme (apparently
about 11 bits per word)
fold function can fold/truncate the hash to a key, based on the
number of bits indicated in the level (e.g. level1 is 40 bit; level
2 = 60 bit; level 3 = 80 bit)
User uploads nickname + secured-credential to credential server.
When roaming:
user->server: nickname
server->user: secured-credential
To expose credential:
K=reverse-password(PWD)
recovered=decrypt(K,secured-credential)
status=compare(fold(H(recovered)),K)
6. Open Issues
This document is intended to foster discussion of the requirements,
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:
IPR: Some of the useful mechanisms are encumbered
Robustness: Credential stores should not unacceptably increase the
potential for denial-of-service or other attacks
Performance: Users should not typically have to wait too long for
access to credentials
Bootstrapping: The use of, e.g. TLS server authentication, depends
on the client having a (set of) trusted root(s) - as the protocol
Farrell & Nystr÷m [Page 6]
INTERNET-DRAFT July 2000
may be providing these roots, there may be some hard bootstrapping
issues.
Finally, we note that whether or not the user authentication,
credential protection and specific credential formats should
be separated, or should be intertwined, is an open issue that
warrants careful consideration.
7. Security Considerations
Mobile credentials will never be as secure as a "pure" smart card
solution. However, reasonable security may be accomplished through
some simple means, as outlined above. One should keep in mind,
however, that platforms to which credentials are downloaded usually
cannot be regarded as tamper-resistant, and it therefore is not too
hard to analyze contents of their memories. Further, storage of
private keys, even if they are encrypted, on a credential server,
will be unacceptable in some environments.
8. References
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information
Syntax Standard," RSA Laboratories, June 2000.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", RFC 2026.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
[RFC2459] Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
Public Key Infrastructure - X.509 Certificate and CRL
profile", RFC 2459.
[RFC2616] "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L.
Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616.
Author's Addresses
Stephen Farrell,
Baltimore Technologies,
61/62 Fitzwilliam Lane,
Dublin 2,
IRELAND
tel: +353-1-647-3000
email: stephen.farrell@baltimore.ie
Magnus Nystr÷m
RSA Security
Box 10704
121 29 Stockholm
Sweden
Farrell & Nystr÷m [Page 7]
INTERNET-DRAFT July 2000
tel: +46 8 725 0900
email: magnus@rsasecurity.com
Full Copyright Statement
Copyright (C) The Internet Society (date). 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.
Farrell & Nystr÷m [Page 8]
