[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 3760

                                                           D. Gustafson
                                                      Future Foundation
                                                                M. Just
                                                   Entrust Technologies
Internet Draft                                               M. Nystrom
Document: draft-ietf-sacred-framework-01.txt               RSA Security
Expires: September 2001                                      March 2001


    Securely Available Credentials - Credential Server Framework


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
   responds to the credential server framework 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 [1].

   Please send comments on this document to the ietf-sacred@imc.org
   mailing list.






   Gustafson, Nystrom, & Just                                [page 1]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework


Table of Contents

STATUS OF THIS MEMO .............................................  1

ABSTRACT ........................................................  1

1 INTRODUCTION...................................................  3

2 FUNCTIONAL OVERVIEW ...........................................  3
 2.1 DEFINITIONS ................................................  3
 2.2 CREDENTIALS ................................................  4
 2.3 NETWORK ARCHITECTURE .......................................  5

3 AUTHENTICATION METHODS ........................................  6
 3.1 STRONG PASSWORD ALGORITHMS .................................  7
 3.2 TLS AUTHENTICATION .........................................  7
  3.2.1 MUTUAL TLS AUTHENTICATION ...............................  7
  3.2.2 TLS SERVER AUTHENTICATION ...............................  8

4 AUTHENTICATION OPTIONS ........................................  8
 4.1 CLIENT INITIALIZATION ......................................  8
  4.1.1 UNINITIALIZED CLIENT STATE ..............................  8
  4.1.2 INITIALIZED CLIENT STATE ................................  8
 4.2 CLIENT AUTHENTICATION ......................................  9
  4.2.1 USER REGISTRATION .......................................  9
  4.2.2 CREDENTIAL DOWNLOAD .....................................  9
  4.2.3 POST CREDENTIAL DOWNLOAD OPERATIONS ....................  10

5 PROTOCOL FRAMEWORK ...........................................  10
 5.1 CREDENTIAL UPLOAD .........................................  10
  5.1.1 CREDENTIAL UPLOAD PROTOCOL SEQUENCE ....................  11
 5.2 CREDENTIAL DOWNLOAD .......................................  12
  5.2.1 CREDENTIAL DOWNLOAD PROTOCOL SEQUENCE ..................  12
 5.3 CREDENTIAL REMOVAL ........................................  13
  5.3.1 CREDENTIAL REMOVAL PROTOCOL SEQUENCE ...................  13
 5.4 CREDENTIAL MANAGEMENT .....................................  14

6 CREDENTIAL FORMATS ...........................................  14
 6.1 PKCS #12 ..................................................  14
 6.2 PKCS #15 ..................................................  15

7 OPEN ISSUES ..................................................  15

8 SECURITY CONSIDERATIONS ......................................  15

REFERENCES .....................................................  16

AUTHOR'S ADDRESSES .............................................  17

FULL COPYRIGHT STATEMENT .......................................  18

   Gustafson, Nystrom, & Just                                [page 2]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework


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 on different end-user equipment. 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 draft proposes a general framework for secure exchange of
   user credentials and provides an outline of a protocol to meet
   requirements stated in [SACRED].

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

   This draft describes only the client/server architecture
   framework.  A separate framework draft may describe the peer-to-
   peer architecture.

   In all cases, adequate user authentication methods will be used to
   ensure credentials are not divulged to unauthorized parties. As
   well, adequate server authentication ensures that client
   authentication information (see Section 2.1) is not compromised,
   and so that the user retrieves their intended credentials (i.e. so
   that a user isn't maliciously given an "older" set of credentials
   to use).

2.1 Definitions

   This section provides definitions for several terms or phrases
   used throughout this draft.

   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 private signing key
   credential belonging to the client (e.g. as part of TLS client
   authentication).


   Gustafson, Nystrom, & Just                                [page 3]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   credentials: cryptographic objects and related data used to
   support secure communications over the Internet. Credentials may
   consist public/private key pairs, symmetric keys, X.509 public key
   certificates, attribute certificates, and/or application data.
   Credentials may be cryptographically protected for confidentiality
   and integrity by encoding them in a standard format (e.g. PKCS#12
   or PKCS#15). (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. credentials may be first secured with a
   passkey corresponding to a user's password, followed by a
   symmetric key chosen by the Credential Server.

   Note the distinction between an "authentication password" and a
   "credential password."  An authentication password (and
   corresponding token) may be used by a user to authenticate to a
   Credential Server. A credential password may be used to generate a
   passkey used to secure credentials. Although the same password may
   be used to both authenticate and protect all credentials, it is
   likely that different passkeys would be generated from this
   password to protect credentials (i.e. because of different salt
   values).

   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 draft is concerned with the secure use 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)

   Gustafson, Nystrom, & Just                                [page 4]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   - etc.

   The end user system may, optionally, store its credential
   information on other special hardware devices that provide
   additional portability and protection.

   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 draft we assume that, at least to 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.

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

   Gustafson, Nystrom, & Just                                [page 5]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

             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).

   The high level design for protocol 1 is described by this
   framework. Protocols 2 and 3 may be implemented using standard
   protocols, such as LDAP or secure LDAP, or using other standard or
   proprietary protocols.

   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 the credential
   server.  Depending on credential server design, user credentials
   may flow through the credential server to the credential store or
   directly from the client to/from 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 Authentication Methods

   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 (e.g. an older
   credential for the user).

   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 a user is first
   registered with the credential server and may be updated from time
   to time thereafter by the authorized user.

   Gustafson, Nystrom, & Just                                [page 6]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   Authentication MUST be performed to mutually authenticate the
   client and server within the credential exchange protocol. Some
   authentication protocols that might be used for this purpose
   include:

   - strong password based,
   - TLS authentication, or
   - TLS with client password authentication

   Section 4 gives some guidance as to the use of each authentication
   method. The specifics of each supported authentication protocol is
   (or will be) defined in a separate draft.

3.1 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 (such as a
   trusted root store), 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. This option is
   suitable in the case that the user is unable/unwilling to rely on
   a trusted root key necessary for authenticating the Credential
   Server's certificate.

   Strong password methods require that user-specific information
   (i.e. a password token) 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 a time when the user 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.
   Also, both parties derive a strong (symmetric) key that may be
   used to secure subsequent communications between the two parties.

   For the purpose of initial registration a secret shared out-of-
   band between the user and the Credential Server may be used to
   strongly authenticate both parties.

3.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 indicated in the following two
   subsections.  In either case, authentication of the server
   requires that the user possesses at least one trusted root (in
   addition to their password).




   Gustafson, Nystrom, & Just                                [page 7]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework


 3.2.1 Mutual TLS Authentication

   Following server authentication, the server MAY request TLS client
   authentication. If the client is currently configured with a
   suitable certificate, this operation can be used to authenticate
   the client. TLS client authentication is not possible whenever the
   client device has no such credential. Note also the requirement
   that the server must be able to successfully validate the user's
   certificate.

 3.2.2 TLS Server Authentication

   In the case that a client does not have a certificate with which
   to mutually authenticate with the server, then subsequent to a
   server authentication, the client may authenticate with a password
   token. This is a viable option whenever the client certificate
   cannot be validated by the Credential Server.

4 Authentication Options

   The choice of authentication mechanism depends very much upon the
   client state, and in particular, what information is available to
   them. This section provides some guidance as to what general
   authentication methods might be more appropriate given the
   client's environment and operation that they intend to perform.

4.1 Client initialization

   Authentication of the server, by the client depends on whether the
   client possesses any trusted roots or not.  We distinguish such
   client state as follows.

 4.1.1 Uninitialized client state

   In order to use http/TLS transport protocol, client software must
   be configured with one or more root certificates.  Root
   certificates, sometimes called self-signed or self-issued
   certificates must be protected by some external means (e.g. other
   than the certificate's digital signature) at all times.
   Typically, each secure application installs one or more root
   certificates during the software installation process then
   protects them using application-specific methods.

   Prior to client initialization, strong password authentication can
   be used to authenticate client and server and protect user
   credential(s) while in transit.  Once received, client software
   can install and configure root certificates, client credentials,
   and other data as appropriate.

 4.1.2 Initialized client state


   Gustafson, Nystrom, & Just                                [page 8]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   Once root certificates have been installed, http/TLS capability is
   available and the client device can utilize a wider range of
   authentication and credential exchange options to upload
   credentials, download additional credentials, etc.

   Several combinations of strong password authentication and
   http/TLS (see section 4.2 for details) can be used to mutually
   authenticate client and server then exchange credentials.

4.2 Client authentication

   The authentication method used by the client to the server depends
   on the information currently available to the client. It is
   helpful to distinguish based on the operation that is being
   performed.  There are essentially three different macro-level
   operations that may be performed by a client interacting with the
   credential server. This classification of operations is given in
   the following subsections.  Note that in all cases, the user may
   either be "self registered" or may be registered through the
   facilities of an administrative process or method that is
   associated with the credential server.  The administrative process
   or method operates as a user with special create/update privilege.

 4.2.1 User Registration

   A user registering with a credential server will likely currently
   possess credentials that may be used to authenticate to the
   Credential Server. In this case, mutual TLS authentication (see
   Section 3.2.1) may be used (provided the user has been initialized
   - see Section 4.1.2). However, the use of the client certificate
   also requires that the Credential Server is able to establish
   trust in this certificate.

   Alternatively, a user might register using a secret shared out-of-
   band with the credential server, and used in a strong-password-
   based protocol (see Section 3.1).  This alternative supports an
   uninitialized user (see Section 4.1.1) but requires an out-of-band
   sharing.

   In the case that identification of the user is not required as
   part of their registration, an initialized user (see Section
   4.1.2) may upload the appropriate registration information to the
   Credential Server over a server-authenticated TLS session (see
   Section 3.2.2).

 4.2.2 Credential Download

   An uninitialized user (see Section 4.2.1) not currently possessing
   any certificate information may use a strong-password-based
   protocol (see Section 3.1) as authentication for downloading their
   credentials.


   Gustafson, Nystrom, & Just                                [page 9]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   Alternatively, an initialized user (see Section 4.2.2) may use a
   server authenticated session and user password to authenticate to
   the Credential Server (see Section 3.2.2).

   An initialized user already possessing a certificate that is
   verifiable by the Credential Server may establish a mutually
   authenticated TLS session (see Section 3.2.1) prior to download.

 4.2.3 Post Credential Download Operations

   Once a client has retrieved their credentials, an initialized
   client (see Section 4.2.2) may use mutual TLS authentication (see
   Section 3.2.1) to perform any subsequent operations (so long as
   the credential server is able to determine the validity of the
   user certificate).

   Alternatively, an initialized user (see Section 4.2.2) may use a
   server authenticated session and user password to authenticate to
   the Credential Server (see Section 3.2.2).

   An uninitialized user (see Section 4.2.1) may use a strong-
   password-based protocol (see Section 3.1) as authentication for
   any post credential download operations.

5 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".

   Access to credentials is based on a user supplying at least a user
   name and appropriate client authentication information. Successful
   authentication by the user allows access to the secured
   credentials corresponding to the authenticate user name. For each
   user name, different "handles" may be assigned to different
   secured credentials, e.g. there may be one handle for "financial"
   and one for "healthcare" credentials. If a user would like to have
   a distinct (authentication) password in order to obtain different
   secured credentials, then they may register credentials under
   distinct user names.

5.1 Credential Upload

   The purposes of a credential upload capability are:

   - to allow a client to register new credentials with a
     credential server, and



   Gustafson, Nystrom, & Just                                [page 10]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   - to allow a client to modify currently stored credentials with
     new credentials, e.g. credentials that may have been updated by the
     client using appropriate key management software.

   The framework for credential upload (PUT operation) is:

   - The client and server establish a mutually authenticated TLS
     session (or equivalent);

   - The client will then issue a PUT message that contains the
     upload credential and 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.

   - Credential Handle: The handle or alias associated with the
     credential.

   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.

 5.1.1 Credential Upload Protocol Sequence

   The following gives an example of a "credential upload" protocol
   sequence:

         client                      server
         -------                     -------

        < connect >      -->

        <--- mutual authentication --->

        < Cred-1 >       -->
                         <--     < Cred-1 URL, ID >
        < Cred-2 >       -->
                         <--     < Cred-2 URL, ID >

                         ...

        < done >         -->
                         <--     OK (+ connection dropped)

   where,

   The <mutual authentication> protocol exchange is dependent upon
   the authentication method used.  In any case, its end result is to
   authenticate the client to the server and server to the client,
   and establish a symmetric key shared between the two parties.


   Gustafson, Nystrom, & Just                                [page 11]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   Cred-x URL is a locator that can be used to access the secured
   credential for download.

   Cred-x ID is a indicator that may be used for conditional download
   (e.g. http/1.1 "if modified-since").

5.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 (GET operation) is:

   - The server SHOULD be authenticated to the client

   - 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 may be 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. In the case that a
   credential handle is not specified, all credentials associated
   with the given user name may be returned.

   Optionally, the user agent MAY include a previously obtained
   fingerprint (see above) to determine whether a download is
   necessary. If the server finds that the credential has not been
   modified, it MAY indicate this in its response.

 5.2.1 Credential Download Protocol Sequence

   The following gives an example of a "credential download" protocol
   sequence:

          client                      server
          -------                    --------

        < connect >       -->

        <--- mutual authentication --->

        < GET Cred-1 URL
          [Fingerprint]>  -->
                          <--     < GET response 1 (Cred-1) >
        < GET Cred-2 URL
          [Fingerprint]>  -->
                          <--     < GET response 2 (Cred-2) >

      Gustafson, Nystrom, & Just                                [page 12]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

                          ...

        < done >          -->
                          <--     OK (+ connection dropped)

   where,

   Cred-x URL is a locator for a specific credential. Each download
   request may be conditional.

   Fingerprint is an optional value that may be used to indicate that
   a specific version or revision level of Cred-x is already
   available to the client.

5.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 in the case that TLS authentication is
     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.

 5.3.1 Credential Removal Protocol Sequence

   The following gives an example of a "credential removal" protocol
   sequence:

         client                        server
         -------                      --------

       < connect >            -->

       <-------- mutual authentication -------->

       < DEL Cred-1 URL >     -->
                              <--     < Cred-1 deleted >
       < DEL Cred-2 URL >     -->
                              <--     < Cred-2 deleted >

                              ...

       < done >               -->
                              <--     OK (+ connection dropped)



    Gustafson, Nystrom, & Just                                [page 13]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   where,

   Cred-x URL is a locator for a specific credential.

5.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

   << Operations such as Registration, De-registration,
   ChangePassword, ListCredentials, will be included in the next
   version of this draft. >>

   The credential is an opaque (encrypted) data object with user
   defined format.  Section 6 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.

6 Credential Formats

   This section describes two possible candidate formats, both
   (believed to be) unencumbered. A separate document may profile use
   of existing standards, such as PKCS #12 and PKCS #15, when they
   are used to convey SACRED credentials.

6.1 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 SACRED credential format.

   PKCS #12 is capable of providing a highly flexible, secure
   credential format that may contain any number of public/private
   key pairs, PKCS #8 shrouded key pairs, EE or CA certificates, and
   miscellaneous secrets.  The entire credential will be integrity
   protected using digital signature or HMAC.  Credentials will be
   privacy protected using password-based-encryption.

6.2 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


   Gustafson, Nystrom, & Just                                [page 14]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   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]
   - Capable of carrying "raw" public keys
   - Standardized set of secret key types

   Among things speaking against PKCS #15 are:

   - The software token format has recently been defined and is
     not widely used


7 Open Issues

   This document is intended to foster further discussion of the
   framework and protocols that might be used to support credential
   mobility.  Some open issues that remain are:

   - Flexibility:  Users should be able to access their
     credentials from any device using any supported authentication method

   - Authentication for download - http/1.1 is not very flexible
     here


8 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].

   Some additional security considerations are:

   - For uploads, if the user is not authenticated, the server
     MUST make sure not to accidentally overwrite another user's
     credentials.

   - For downloads, if the server is not authenticated, the user
     MUST be made aware of risks associated with this fact. For example,
     the user may unknowingly reveal information regarding their
     authentication password (in the case a password token is supplied
     over a server authenticated TLS channel).  As well, a user might be
     unknowingly given an old credential to use.

   - Using any password-based techniques, user passwords need
     never be stored "in the clear" on credential servers.


  Gustafson, Nystrom, & Just                                [page 15]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework


   - Credential servers SHOULD provide mechanisms to protect
     against remote dictionary attacks on user passwords.

   - 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 (e.g., password
     verifiers) are protected by the server.

   - To ensure the integrity of mutual authentication and
     transaction privacy, credential servers SHOULD protect "password
     verifiers" with the same rigor that they protect their private key.

   - It is expected that credential users will make use of
     physical security or additional encryption layers (or both) to
     further protect their locally stored credentials, whenever
     appropriate.


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
             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, M. Leach, T. Berners-Lee, "Hypertext Transfer
             Protocol - HTTP/1.1", RFC 2616.




  Gustafson, Nystrom, & Just                                [page 16]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   [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.

Author's Addresses

   Dale Gustafson
   Future Foundation
   715 Florida Avenue South
   Golden Valley, MN, 55426     Phone:  +1 651-452-8369
   USA                          Email:  dale.gustafson@bpsi.net

   Mike Just
   Entrust Technologies
   1000 Innovation Drive
   Ottawa, ON K2K 3E7           Phone:  +1 613-270-3685
   Canada                       Email:  mike.just@entrust.com

   Magnus Nystrom
   RSA Security
   Box 10704
   121 29 Stockholm             Phone:  +46 8 725 0900
   Sweden                       Email:  magnus@rsasecurity.com


Full Copyright Statement

   Copyright (C) The Internet Society (2001).  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. 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


  Gustafson, Nystrom, & Just                                [page 17]

                   Securely Available Credentials -         March 2001
                     Credential Server Framework

   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, & Just                                [page 18]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/