[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
     Internet Draft                                            M. Nystrom
     Document: draft-ietf-sacred-framework-04.txt            RSA Security
     Expires: December 2002                                     June 2002
  
  
        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
     [RFC3157]. 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, Just, & Nystrom                                 [page 1]
  

                     Securely Available Credentials -      February 2002
                       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..................................................5
    2.3 NETWORK ARCHITECTURE.........................................6
  3 PROTOCOL FRAMEWORK...............................................7
    3.1 CREDENTIAL UPLOAD............................................9
     3.1.1 Credential Upload Protocol Sequence......................10
    3.2 CREDENTIAL DOWNLOAD.........................................10
     3.2.1 Credential Download Protocol Sequence....................11
    3.3 CREDENTIAL REMOVAL..........................................11
     3.3.1 Credential Removal Protocol Sequence.....................12
    3.4 CREDENTIAL MANAGEMENT.......................................12
  4 PROTOCOL CONSIDERATIONS.........................................13
    4.1 SECURE CREDENTIAL FORMATS...................................13
    4.2 AUTHENTICATION METHODS......................................13
     4.2.1 Strong Password Protocols................................14
     4.2.2 TLS Authentication.......................................14
     4.2.3 Other Authentication Methods.............................15
    4.3 TRANSPORT PROTOCOL SUITES...................................15
     4.3.1 TCP......................................................16
     4.3.2 BEEP.....................................................16
     4.3.3 HTTP.....................................................16
  5 OPEN ISSUES.....................................................17
  6 SECURITY CONSIDERATIONS.........................................17
    6.1 COMMUNICATIONS SECURITY.....................................17
     6.1.1 Confidentiality..........................................17
     6.1.2 Integrity................................................17
     6.1.3 Entity Authentication....................................17
     6.1.4 Non-repudiation..........................................18
    6.2 SYSTEMS SECURITY............................................18
     6.2.1 Client Security..........................................18
     6.2.2 Server Security..........................................19
     6.2.3 DoS......................................................19
  7 REFERENCES......................................................20
  AUTHOR'S ADDRESSES................................................21
  FULL COPYRIGHT STATEMENT..........................................22
  
  
  
  
  
  
  
  
  
  
  
  
  
     Gustafson, Just, & Nystrom                                 [page 2]
  

                     Securely Available Credentials -      February 2002
                       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 a high level outline that will help
     guide the development of one or more SACRED credential exchange
     protocols.
  
  2 Functional Overview
  
     Requirements for Securely Available Credentials are fully
     described in [RFC3157].  These requirements assume that two
     distinctly different network architectures will be created to
     support credential exchange for roaming users:
  
     a) Client/Server Credential Exchange
     b) Peer-to-Peer Credential Exchange
  
     This draft describes the framework for one or more client/server
     credential exchange protocols.
  
     In all cases, adequate user authentication methods will be used to
     ensure credentials are not divulged to unauthorized parties. As
     well, adequate server authentication methods will be used to
     ensure that each client's authentication information (see Section
     2.1) is not compromised, and to ensure that roaming users interact
     with intended/authorized credential servers.
  
  2.1 Definitions
  
     This section provides definitions for several terms or phrases
     used throughout this 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).
  
     credentials: cryptographic objects and related data used to
             support secure communications over the Internet.
  
     Gustafson, Just, & Nystrom                                 [page 3]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
             Credentials may consist of public/private key pairs,
             symmetric keys, X.509 public key certificates, attribute
             certificates, and/or application data. Credentials are
             cryptographically protected for confidentiality and
             integrity by encoding them in a standard format (e.g.
             PKCS#12 [PKCS12] or PKCS#15 [PKCS15]). (See secured
             credentials below.)
  
     passkey: a symmetric key, derived from a password.
  
     password: a string of characters known only to a client and used
             for the purposes of authenticating to a server and/or
             securing credentials.  A user may be required to remember
             more than one password.
  
     password token: a value derived from a password using a one-way
             function that may be used by a client to authenticate to a
             server. A password token may be derived from a password
             using a one-way hash function, for example.
  
     secured credentials: a set of one or more credentials that have
             been cryptographically secured, e.g. encrypted/MACed with
             a passkey. Secured credentials may be protected using more
             than one layer of encryption, e.g. the credential is
             secured with a passkey corresponding to a user's password
             and also by a key known only to the server (the
             credential's stored form).  Prior to network transfer, the
             passkey-protected credential may be protected with an
             additional encryption layer using a symmetric key chosen
             by the Credential Server (e.g., the transmitted form).
  
     strong password protocol: a protocol that authenticates clients to
             servers securely (see e.g. [SPEKE] for a more detailed
             definition of this),, where the client need only memorize
             a small secret (a password) and carries no other secret
             information, and where the server carries a verifier
             (password token) which allows it to authenticate the
             client. A shared secret is negotiated between client and
             server and is used to protect data subsequently exchanged.
  
     Note the distinction between an "account password" and a
     "credential password."  An account password (and corresponding
     password token) is used to authenticate to a Credential Server and
     to negotiate a key that provides session level encryption between
     client and server.
  
     A credential password is used to derive a passkey that's used to
     provide persistent encryption and authentication for a stored
     credential. See [PKCS15] and [PKCS12] for credential format
     details. Although the same password value may be used to provide
     both services, it is likely that different, algorithm specific
  
  
     Gustafson, Just, & Nystrom                                 [page 4]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     passkeys would be generated from this password (i.e. because of
     different salt values, etc.).
  
     In addition, although it may be more convenient for a user to
     remember only a single password, differing security policies (e.g.
     password rules) between the credential server and the credential
     issuers may result in a user having to remember multiple
     passwords.
  
  2.2 Credentials
  
     This document is concerned with the secure use and online
     management of credentials in a roaming or mobile environment.
     Credentials MAY be usable with any end user device that can
     connect to the Internet, such as:
  
     - desktop or laptop PC
     - mobile phone
     - personal digital assistant (PDA)
     - etc.
  
     The end user system may, optionally, store its credential
     information on special hardware devices that provide enhanced
     portability and protection for user credentials.
  
     Since the credential usually contains sensitive information that
     is known only to the credential holder, credentials MUST NOT be
     sent in the clear during network transmission and SHOULD NOT be in
     the clear when stored on an end user device such as a diskette or
     hard drive. For this reason, a secured credential is defined.
     Throughout this draft we assume that, at least from the point of
     view of the protocol, a secured credential is an opaque (and at
     least partially privacy and integrity protected) data object that
     can be used by a network connected device. Once downloaded,
     clients must be able to recover their credentials from this opaque
     format.
  
     At a minimum, all supported credential formats SHOULD provide
     privacy and integrity protection for private keys, secret keys,
     and any other data objects that must be protected from disclosure
     or modification.  Typically, these security capabilities are part
     of the basic credential format such that the credential (e.g., a
     data file) is protected when stored on hard drives, flexible
     diskettes, etc.
  
     Prior to network transmission, the secured credential is protected
     with a second (outer) encryption layer.  The outer encryption
     layer is created using a session-level encryption key that was
     derived during the mutual authentication process.  Effectively,
     secured credentials traverse an "encrypted tunnel" that provides
     an additional layer of privacy protection for credentials (and any
     other) information exchanged.
  
     Gustafson, Just, & Nystrom                                 [page 5]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
  
  2.3 Network Architecture
  
     The network diagram below shows the components involved in the
     SACRED client/server framework.
  
                       +--------+           +------------+
                       | Client +-----------| Credential |
                       +--------+     1     |   Server   |
                            \               +-----+------+
                             \                    |
                              \                   | 2
                               \                  |
                                \    3      +-----+------+
                                 -----------| Credential |
                                            |  Store(s)  |
                                            +------------+
  
  
     Client - The entity that wants to retrieve their credentials from
               a credential server.
  
     Credential Server - The server that downloads secure credentials
               to and uploads them from the client.  The server is
               responsible for authenticating the client to ensure that
               the secured credentials are exchanged only with an
               appropriate end user. The credential server is
               authenticated to the client to ensure that the client's
               authentication information is not compromised and so
               that the user can trust the credentials retrieved.
  
     Credential Store - The repository for secured credentials. There
               might be access control features but those generally
               aren't sufficient in themselves for securing
               credentials.  The credential server may be capable of
               splitting credentials across multiple credential stores
               for redundancy or to provide additional levels of
               protection for user credentials.
  
     Protocol 1 - The protocol used to authenticate the client and
               credential server, and download and upload user
               credentials from a credential server.
  
     Protocol 2 - The protocol used by the Credential Server to store
               and retrieve user credentials (LDAP, LDAP/SSL, or
               other).
  
     Protocol 3 - The protocol used by the client to store and retrieve
               user credentials from the credential store (LDAP,
               LDAP/SSL, or other).
  
  
  
     Gustafson, Just, & Nystrom                                 [page 6]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     This framework describes the high level design for protocol 1.
     Protocols 2 and 3 are closely related (but out of scope for this
     document) and could be implemented using standard protocols, such
     as LDAP or secure LDAP, or other standard or proprietary
     protocols.  Note also that any administrator-credential server
     protocols are assumed to be server vendor specific and are not the
     subject of SACRED standardization efforts at this time.
  
     Clients are not precluded from exchanging credentials directly
     with a credential store (or any other server of it's choosing).
     However, mutual authentication with roaming users and a consistent
     level of protection for credential data while stored on network
     servers and while in transit is provided by SACRED protocols
     exchanged with the credential server.  Depending on credential
     server design, user credentials may flow through the credential
     server to the credential store or directly between the client and
     the credential store.
  
     Also, users may upload their credentials to several credential
     servers to obtain enhanced levels of availability.  Coordination
     (automatic replication) of user information or credential data
     among several credential servers is currently beyond the scope of
     this document.
  
  3 Protocol Framework
  
     This section provides a high level description of client/server
     protocols that can be used to exchange and manage SACRED
     credentials.
  
     The client/server credential exchange protocol is based on three
     basic and abstract operations; "GET", "PUT", and "DELETE". The
     secured credential exchange protocol is accomplished as follows:
  
          connect - the client initiates a connection to a credential
                  server for the purpose of secure credential exchange.
  
          mutual authentication/key negotiation - using a strong
                  password protocol (or equivalent) the client
                  authenticates to the server, the server authenticates
                  to the client, and a session level encryption key is
                  negotiated. The details of the mutual authentication
                  protocol exchange are dependent upon the particular
                  authentication method used. In all cases, the end
                  result is to authenticate the client to the server
                  and server to the client, and establish a strong,
                  shared secret between the two parties.
  
          client request(s) - the SACRED client issues one or more high
                  level credential exchange requests (e.g., GET, PUT,
                  or DELETE).
  
  
     Gustafson, Just, & Nystrom                                 [page 7]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
          server response(s) - the SACRED credential server responds to
                  each request, either performing the operation
                  successfully or indicating an appropriate error.
  
          close - the client indicates it has no more requests for the
                  server at this time. The security context between
                  client and server is no longer needed. Close is a
                  logical, session management operation.
  
          disconnect - the parties disconnect the transport level
                  connection between client and server. Note that
                  "connect" and "disconnect" are transport dependent,
                  logical operations that bound the protocol exchange
                  between the two communicating processes.
  
          Each high-level credential exchange operation is made up of a
          series of request-response pairs. The client initiates each
          request which the server processes before returning an
          appropriate response. Each request must complete (server
          reports success or failure) before the client issues the next
          request. The server SHOULD be willing to service at least one
          upload or download request following successful mutual
          authentication but either party can terminate the logical
          connection at any time.
  
     In the following sections, secured credentials and related values
     are represented using the following notation:
  
          SC-x is the secured credential file, which includes a format
                  identifier field and credential data.  The credential
                  data is an opaque, encrypted data object (e.g.
                  PKCS#15 or PKCS#12 file). The format identifier is
                  needed to correctly parse the credential data.
  
          Name-x is an account-defined selector or locator (a user
                  friendly name) that is used to indicate a specific
                  secured credential. The name of each credential
                  stored under a given user account MUST be unique e.g.
                  there may be one credential called "financial" and
                  another called "healthcare", etc. At a minimum,
                  credential names MUST be unique across a given
                  account/user name. A credential name is required on
                  all PUT/DELETE operations. When no name is supplied
                  for a GET operation, all credentials stored for the
                  given username will be returned.
  
          ID-x is a distinct credential version indicator that MAY be
                  used to request a conditional GET/PUT/DELETE
                  operation. This credential-ID value SHOULD contain
                  the server's "last-modified" date and time (eg. the
                  time that this particular credential version was
                  stored on the server) and MAY contain additional
  
     Gustafson, Just, & Nystrom                                 [page 8]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
                  information such as a sequence number or a (complete
                  or partial) credential fingerprint that is used to
                  ensure the credential-ID is unique from other
                  credential versions stored under the same user
                  account and credential name.
  
     All named credentials may be accessed by authenticating under a
     single username. If a user needs or prefers to use more than one
     distinct authentication password (and/or authentication method) to
     protect access to several secured credentials, he/she SHOULD
     register those credentials under distinct user/account names, one
     for each different authentication method used.
  
  3.1 Credential Upload
  
     The purpose of a credential upload capability is to allow a client
     to register new credentials, or replace currently stored
     credentials (e.g. credentials that may have been updated by the
     client using appropriate key management software).
  
     The framework for the credential upload, as implemented using the
     PUT operation, is:
  
      - The client and server establish a mutually authenticated
        session and negotiate a shared secret.
  
      - The client will then issue a PUT message that contains the
        upload credential and related data fields.
  
      - The server will respond to the PUT, indicating the credential
        was successfully stored on the server or that an error
        occurred.
  
     The client's PUT request MAY contain an optional identifier
     (credential-ID) field. If present, the new credential will only be
     stored if a credential with the same name and credential-ID is
     currently stored on the server (e.g. a logical REPLACE operation
     is performed). The server MUST return an error if a client
     attempts to replace a credential that does not exist on the
     server.
  
     The credential server's response to a PUT request MUST contain a
     credential version identifier (credential-ID) for the newly stored
     credential that MAY be used by clients to optimize subsequent
     download operations and avoid credential version mismatches.
  
  
  
  
  
  
  
  
     Gustafson, Just, & Nystrom                                 [page 9]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
    3.1.1 Credential Upload Protocol Sequence
  
     The following gives an example of a "credential upload" protocol
     sequence:
  
          client                               server
          -------                              -------
  
          < connect >                  -->
  
          <--- mutual authentication --->
  
          < PUT SC-1, Name-1, [ID-1] > -->
                                       <--     < Name-1, new-ID-1 >
          < PUT SC-2, Name-2, [ID-2] > -->
                                       <--     < Name-2, new-ID-2 >
  
                                       ...
  
          < close >                    -->
                                       <--     OK (+ disconnect)
  
     new-ID-x is the credential-ID of the newly stored credential.
  
  3.2 Credential Download
  
     Roaming clients can download their credentials at any time after
     they have been uploaded to the server.
  
     The framework for a credential download, as implemented using the
     GET operation, is:
  
       - The client SHOULD authenticate the server.
       - The user MUST be authenticated (by the server).
       - A GET request for the credential download is issued.
       - The response contains the credential and format identifier.
  
     The specific user credential being requested may be identified by
     name in the message sent to the credential server.  If successful,
     the response MUST contain the requested credential data element
     (format ID and data) as defined above.
  
     If the user issues a GET request with a NULL credential name
     field, the server SHOULD return all credentials stored under the
     current user account.
  
     Optionally, the client MAY include a credential-ID to indicate a
     conditional download request. In this case, the server will return
  
  
  
  
  
     Gustafson, Just, & Nystrom                                [page 10]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     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] >  -->
                                 <--     < GET response 1 (SC-1) >
          < GET Name-2, [ID-2] >  -->
                                 <--     < GET response 2 >
  
                                 ...
  
          < 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
  
     Gustafson, Just, & Nystrom                                [page 11]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
        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.
  
  
  
  
  
  
  
  
  
  
  
     Gustafson, Just, & Nystrom                                [page 12]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
  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 and server
     implementations.
  
     At least two well-defined credential formats are available today;
     [PKCS12] and [PKCS15]. For interoperability reasons, at least one
     credential format must be mandatory to support by clients.
  
     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:
  
     Gustafson, Just, & Nystrom                                [page 13]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
  
      - 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 authentication
  
     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], [PDM], 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.  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.  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 CA root
     key certificates needed to validate the server's certificate chain
     (including revocation status checking).
  
  
  
  
     Gustafson, Just, & Nystrom                                [page 14]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     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 are 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.
  
     When necessary, and after a TLS session has been established
     between the two parties, the server can request that the client
     provide her user id and password information to authenticate the
     remote user. Preferrably, client and server can cooperate to
     perform a SASL-based 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 Remote 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.
     Following successful server authentication, the TLS server MAY
     request client authentication.
  
     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 necessary security
     capabilities MAY also be suitable for use with SACRED credential
     exchange protocols:
  
      - server or mutual authentication, as appropriate
      - negotiate/derive a strong session key known only to client and
        server
      - adequate protection of sensitive information sent between
        clients and credential servers.
  
  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.
  
  
  
     Gustafson, Just, & Nystrom                                [page 15]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     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:
  
          - 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 (see [RFC2246]).
     Either or both TLS authentication options, sTLS or cTLS, may be
     used whenever TLS is supported.
  
  
     Gustafson, Just, & Nystrom                                [page 16]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
  
  5 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
  
  6 Security Considerations
  
     The following security considerations identify general
     observations and precautions to be considered for a
     frameworksupporting 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.
  
  6.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.
  
     6.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.
  
     6.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).
  
  
     6.1.3 Entity Authentication
  
     Proper authentication of the client and server is required to
     achieve communication confidentiality and integrity.
  
  
     Gustafson, Just, & Nystrom                                [page 17]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     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 in which the server learns
     nothing of the user's password as part of authentication, but
     knows that if authentication is successful, it could only
     have been established with the user. Alternatively, 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 root key(s) in
     the client.
  
     6.1.4 Non-repudiation
  
     Although credential confidentiality is one of many factors
     required to support non-repudiation, there are no requirements
     upon the SACRED protocol itself to support non-repudiation.
  
  6.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.
  
     6.2.1 Client Security
  
     As with most security protocols secure use of the client often
     relies, in part, upon secure behaviour by the user. In the
     case of a 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.
  
     Given that the user is relying on the security enforced by their
     client, the user must take care to ensure that their password is
     not entered into rogue client software.
  
     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
  
     Gustafson, Just, & Nystrom                                [page 18]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
     or serveral user name choices in the appropriate on-screen dialog
     field, for example.
  
     6.2.2 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
     all together. Alternatively, one might simply log unsuccessful
     attempts where an administrative notice is produced once a
     threshold of unsuccessful credential access attempts is reached.
  
     6.2.3 DoS
  
     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 a
     user's credentials are not maliciously overwritten by an attacker.
     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).
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Gustafson, Just, & Nystrom                                [page 19]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
  7 References
  
     [RFC3157] Arsenault, A., Farrell, S., "Securely Available
               Credentials - Requirements", RFC 3157, August 2001.
  
     [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.
  
     [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.
  
     [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.
  
     [RFC2222] Myers, J., "Simple Authentication and Security Layer
               (SASL), RFC 2222, October 1997.
  
     [PDM]     Perlman, R., Kaufman, C., Rescorla, E. "Strong Password-
               Based Credentials Download Using Pseudorandom Moduli
               <draft-perlman-strong-cred-00.txt>, December 2000.
  
     [SPEKE]   Jablon, D., "Strong Password-Only Authenticated Key
               Exchange", September 1996
  
  
  
     Gustafson, Just, & Nystrom                                [page 20]
  

                     Securely Available Credentials -      February 2002
                       Credential Server Framework
  
  
     [BM92]    S. Bellovin 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]    S. Bellovin and M. Merritt, "Augmented Encrypted Key
               Exchange: a Password-Based Protocol Secure Against
               Dictionary Attacks and Password File Compromise, ATT
               Labs Technical Report, 1994.
  
     [FK00]    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 Inc.
        3001 Broadway St NE
        Suite 100
        Minneapolis, MN 55413        Phone:  +1 651-452-9033
        USA                          Email:  dale.gustafson@bpsi.net
  
        Mike Just
        Entrust, Inc.
        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
  
  
  
  
  
  
  
  
  
  
  
  
  
  
     Gustafson, Just, & Nystrom                                [page 21]
  

                   Securely Available Credentials -      February 2002
                     Credential Server Framework
  
  
   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 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, Just, & Nystrom                                [page 22]
  

Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/