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

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

Sacred Working Group                                        D. Gustafson
INTERNET-DRAFT                                         Future Foundation
Expires May 2001                                              M. Nystrom
                                                            RSA Security
                                                           November 2000

               Securely Available Credentials - Framework

                   draft-ietf-sacred-framework-00.txt

                          Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract

   As the number, and more particularly the number of different types,
   of devices, connecting to the Internet increases, credential mobility
   becomes an issue for IETF standardization. This draft responds to the
   requirements listed in [SACRED}. It presents a strawman framework and
   outlines protocols for securely available credentials.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

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





Gustafson & Nystrom         Expires: May 2001                   [Page 1]

INTERNET DRAFT             SACRED - Framework              November 2000


Table of Contents

   1.      Introduction                            2
   2.      Functional Overview                     3
   2.1     Client/Server Network Architecture      4
   2.2     Peer-to-Peer Network Architecture       4
   3.      Protocol Framework                      5
   3.1     Client/Server Protocol                  5
   3.1.1   Credential Upload                       5
   3.1.2   Credential Download                     7
   3.1.3   Credential Removal                      8
   3.1.4   Credential Management                   9
   3.2     Peer-to-Peer Protocol                  10
   4.      User Authentication Methods            10
   4.1     One-time Password (OTP) Algorithms     10
   4.2     Strong Password Algorithms             11
   4.3     TLS Remote Client Authentication       11
   4.4     Conclusions                            11
   5.      Credential Formats                     12
   5.1     A note on interoperability             12
   5.2     PKCS #12                               12
   5.3     PKCS #15                               12
   6.      Open Issues                            13
   7.      Security Considerations                13
   8.      References                             13
   9.      Author's Addresses                     14
   10.     Full Copyright Statement               15

1. Introduction

   Private credentials are used to support various Internet protocols,
   e.g.  S/MIME, IPSec, and TLS. In a number of environments end users
   wish to use the same set of private credentials from different end
   user equipment. In a "typical" desktop environment, the user already
   has many tools available to allow import/export of these credentials.
   However, with some devices, especially wireless and other more
   constrained devices, the tools required simply do not exist.

   This draft proposes a general framework for secure exchange of user
   credentials and provide an outline of a protocol to meet requirements
   stated in [SACRED].

   <<editorial comments are in angle brackets, like this>>








Gustafson & Nystrom         Expires: May 2001                   [Page 2]

INTERNET DRAFT             SACRED - Framework              November 2000


2. Functional Overview

   Requirements for Securely Available Credentials are fully described
   in [SACRED].  These requirements assume that two distinctly different
   network architectures will be supported to exchange credentials
   between different end user systems:

   a) Client/Server Credential Exchange
   b) Peer-to-Peer Credential Exchange

   These requirements also assume that, in all cases, adequate user
   authentication methods will be used to ensure credentials are not
   divulged to unauthorized parties.

   A security credential consists of cryptographic objects and related
   data that are needed to support secure communications over the
   Internet, such as:

   - public/private key pairs
   - secret keys
   - x.509 public key certificates
   - attribute certificates
   - application data

   Since the credential usually contains sensitive information that is
   known only to the credential holder, such information MUST be
   encrypted during network transmission and SHOULD be encrypted when
   stored on an end user device such as a diskette or hard drive.  These
   security credentials MAY be usable with any end user device that can
   connect to the Internet, such as:

   - desktop or laptop PC
   - mobile phone
   - personal digital assistant (PDA)
   - etc.

   Logically, there is no limit to the number of data objects that may
   be included within a credential or the number of credentials that may
   be utilized by any particular end user.  Throughout this document we
   assume that a credential is an opaque (and at least partially
   privacy- and integrity-protected) data object that can be used by a
   network connected device.  Once downloaded, the end user system may,
   optionally, store its credential information on other special
   hardware devices that provide additional portability and protection.







Gustafson & Nystrom         Expires: May 2001                   [Page 3]

INTERNET DRAFT             SACRED - Framework              November 2000


 2.1 Client/Server Network Architecture

   The network diagram below shows the components involved in the sacred
   client/server framework. The numbers refer to protocols that already
   exist or will be described in this document.

                     +--------+           +------------+
                     | Client +-----------| Credential |
                     +--------+     1.    | Server     |
                               \          +-----+------+
                                \               |
                               3.\              | 2.
                                  \             |
                                   \      +-----+------+
                                    +-----| Repository |
                                          +------------+

   Client:                The entity that wants the credential.

   Credential Server:     The server that downloads credentials to and
                          uploads them from the client.  The server
                          is responsible for authenticating the client
                          to ensure credentials are exchanged only
                          with end users who are allowed to use them.

   Repository:            Where the credentials are stored. The
                          repository might have access control features
                          but those generally aren't sufficient in
                          themselves for protecting credentials.
                          Protocol 3 is, likely, not supported
                          by all clients.

   Protocol 1:            The protocol used to download and upload
                          user credentials from a credential server.
                          Described in this document.

   Protocol 2:            The protocol used to store and retrieve
                          user credentials in a repository (LDAP,
                          LDAP/SSL, or other).

   Protocol 3:            The protocol used by the client to exchange
                          credentials (upload or download) directly
                          with a credential repository (LDAP or
                          LDAP/SSL).

 2.2 Peer-to-Peer Network Architecture

   <<TBS - Add a picture and description of a peer-to-peer connection>>



Gustafson & Nystrom         Expires: May 2001                   [Page 4]

INTERNET DRAFT             SACRED - Framework              November 2000


3. Protocol Framework

   This section provides a high level description of client/server and
   peer-to-peer protocols that can be used to exchange and manage SACRED
   credentials.

 3.1 Client/Server Protocol

   The client/server credential exchange protocol is based on three
   basic and abstract operations; "GET", "PUT", and "DELETE". For all
   client/server protocol messages it is assumed that:

   - credential servers MUST NOT be presented with credentials (e.g, a
     sensitive object such as a private key) in plaintext form
   - all user, credential server communications MUST be able to use
     HTTP [RC2616] over TLS [RC2246]
   - when TLS is used, only cipher suites providing strong
     confidentiality MAY be used

   While the following sections assume the use of HTTP over TLS
   transport service other transport protocol options are certainly
   feasible.

  3.1.1 Credential Upload

   The framework for credential upload (PUT operation) is:

   - the credential server MUST be authenticated, that is only TLS
     cipher suites providing strong confidentiality and server
     authentication MAY be used
   - prior to credential upload, the user SHOULD be authenticated (by
     the server) using a method-dependent protocol sequence
   - the user then sends a PUT message that contains the credentials
     and other required information
   - upload of credentials can either be authenticated, or
     unauthenticated
   - if credential upload is unauthenticated, the PUT data MUST include
     information which will be used for user authentication during
     download, this information may take various forms

   <<Note: In this case, PKI credentials could be used for user
   authentication, this will however probably not be possible for
   downloads>>

   The credential server should determine whether user authentication is
   required.  Whenever necessary, the remote user MUST be authenticated.

   The user authentication protocol exchange is method-dependent and



Gustafson & Nystrom         Expires: May 2001                   [Page 5]

INTERNET DRAFT             SACRED - Framework              November 2000


   will typically involve the exchange of several messages between
   client and server.  See Section 4 of this document for more detailed
   information on user authentication methods.

   The user then issues a "PUT" command containing the credential upload
   message. This message contains the following data fields:

   - Credential Format ID and Data

     The user's protected credential and a format identifier that is
     needed to parse the credential after it has been downloaded.

   - Download Authentication Method ID and Data

     The authentication data and an identifier that specifies how
     the user will authenticate to the server for downloads.

   The credential server's response to this PUT message SHOULD contain
   an identifier of the (version of the) credential, which MAY be used
   to optimize later downloads. Note that this message format allows
   each credential stored on the server to be protected by a different
   password.

   The TLS protocol provides an "encrypted tunnel" that protects the
   data only during transmission between client and server. The client
   MAY provide an additional layer of encryption (as defined by the
   credential format) to ensure the credential is not exposed within the
   credential server or repository.

   The "credential upload" protocol sequence is:

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

             connect        -->
                            ...

           < auth-0 >       -->
                            <--     < auth-1 >
           < auth-2 >       -->

                            ...

                            <--     < auth-n >
           < cred-1 >       -->
                            <--     < cred-1 URL, ID >
           < cred-2 >       -->
                            <--     < cred-2 URL, ID >



Gustafson & Nystrom         Expires: May 2001                   [Page 6]

INTERNET DRAFT             SACRED - Framework              November 2000


                            ...

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

   where,

   { auth-0 ... auth-x } is the method-dependent user authentication
   sequence.

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

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

   << For extensibility, we use the connection as if it were a point-to-
   point link.  Should work well for arbitrary links and transports --
   is this appropriate for a TLS connection? >>

  3.1.2 Credential Download

   The framework for a credential download (GET operation) is:

   - TLS server authentication SHOULD be used to authenticate the
     server
   - the user MUST be authenticated (by the server) using a method-
     dependent protocol sequence
   - a GET request for the credential download is issued
   - the response contains the credential and format identifier

   The specific user credential being requested is identified in the
   message sent to the credential server.  If successful, the response
   MUST contain the requested credential data element (format ID and
   data) as defined above.

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

   The "credential download" protocol sequence is:

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

             connect           -->
                               ...



Gustafson & Nystrom         Expires: May 2001                   [Page 7]

INTERNET DRAFT             SACRED - Framework              November 2000


           < auth-0 >          -->
                               <--     < auth-1 >
           < auth-2 >          -->

                               ...

                               <--     < auth-n >
           < GET cred-1 URL
               [Fingerprint]>  -->
                               <--     < GET response 1 (credential-1) >
           < GET cred-2 URL
              [Fingerprint] >  -->
                               <--     < GET response 2 (credential-2) >

                               ...

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

   where,

   { auth-0 ... auth-x } is a method-dependent user authentication
   sequence.

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

   << Issue: We need to decide if uploading and downloading multiple
   credentials needs to be included.  Implies that multiple credentials
   are accessed using a common authentication method and password rather
   than maintaining a separate password for each. >>

  3.1.3 Credential Removal

   The framework for credential removal (DELETE operation) is:

   - the credential server MUST be authenticated, that is only TLS
     ciphersuites providing strong confidentiality and server
     authentication MAY be used
   - the user MUST be authenticated (by the server) using a method-
     dependent protocol sequence
   - the user then sends a DELETE message that contains the credential
     Identifier indicating which credential to remove.

   The "credential removal" protocol sequence is:






Gustafson & Nystrom         Expires: May 2001                   [Page 8]

INTERNET DRAFT             SACRED - Framework              November 2000


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

             connect           -->
                               ...

           < auth-0 >          -->
                               <--     < auth-1 >
           < auth-2 >          -->

                               ...

                               <--     < auth-n >
           < DEL cred-1 URL >  -->
                               <--     < cred-1 deleted >
           < DEL cred-2 URL >  -->
                               <--     < cred-2 deleted >

                               ...

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

   where,

   { auth-0 ... auth-n } is a method-dependent user authentication
   sequence.

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

  3.1.4 Credential Management

   Note that the three basic operations defined above (GET, PUT, DELETE)
   can be used to perform the necessary management operations:

   - create a new credential on the server
   - update an existing credential
   - delete an existing credential
   - change password

   The credential is an opaque (encrypted) data object with user defined
   format.  Section 5 mentions some possible credential formats.
   However, no credential format is excluded in this memo.  There is no
   restriction on the data that may be included in a user credential or
   the credential storage format seen by the server.






Gustafson & Nystrom         Expires: May 2001                   [Page 9]

INTERNET DRAFT             SACRED - Framework              November 2000


 3.2 Peer-to-Peer Protocol

   << TBS - define the peer-to-peer protocol >>

4. User Authentication Methods

   User authentication is vitally important to ensure that credentials
   are accepted from and delivered to the authorized end user only.  If
   a credential is delivered to some other party, the credential may be
   more easily compromised.  If a credential is accepted from an
   unauthorized party, the user might be tricked into using a credential
   which was substituted by an attacker.

   Ideally, the list of authentication methods should be open ended,
   allowing new methods to be added as needs are identified and as new
   methods become available. For all credentials, the user
   authentication method/data is defined when the credential is first
   stored on the server and may be updated from time to time thereafter
   by the authorized user.

   The following classes of user authentication methods are applicable
   (at different times) to the credential exchange protocols described
   earlier:

   - one-time password (OTP)
   - strong password
   - TLS client authentication

 4.1 One-time Password (OTP) Algorithms

   RFC 2289 [RFC2289] describes a password-based authentication method
   that protects the user's password from eavesdroppers.  The client and
   server disguise the secret pass-phrase by using it to generate a
   sequence of one-time (single use) passwords each of which cannot be
   derived from any previously used OTP.  With OTP, the user's secret
   pass-phrase never crosses the network and is not vulnerable to replay
   attacks.  In addition, since each OTP is (effectively) a hash of the
   password, no secret information need be stored on any system.  The
   user's password canot be derived from any of the OTPs that might be
   stored on a server.

   RFC 2444 [RFC2444] describes a One-Time-Password SASL (Simple
   Authentication and Security Layer) mechanism that provides a formal
   way to integrate OTP into SASL-enabled protocols such as IMAP, ACAP,
   POP3 and LDAPv3.






Gustafson & Nystrom         Expires: May 2001                  [Page 10]

INTERNET DRAFT             SACRED - Framework              November 2000


 4.2 Strong Password Algorithms

   Strong password algorithms (e.g. [RFC2945], [PRANDOM], [SPEKE]) may
   be used to authenticate clients to servers securely, in cases where
   the client must only memorize a small secret (like a password) and
   carries no other secret information, and where the server carries a
   verifier which allows it to authenticate the client but which, if
   compromised, would not allow someone to impersonate the client.

   Strong password methods require that user-specific information (e.g.,
   a "verifier", which is derived from the user's password) be
   configured within the server.  This verifier value can only be
   calculated by a party who knows the password (the user) and must be
   securely delivered to the server.  At connect time, messages are
   exchanged between the two parties and complementary algorithms are
   used to compute a common value that can be used to verify the user's
   password (even though the password is never divulged).  Both parties
   also derive a strong (symmetric) key that could be used to secure
   subsequent communications between the two parties.

   Kaliski and Ford [ROAMING] have suggested that an attacker who is
   able to gain access to "password verifier" value(s) can easily derive
   the user's password by mounting a dictionary attack against the
   verifier.  They suggest that the verification function should be
   spread across multiple servers since several servers are less likely
   to be compromised, at the same time, than any single server.  Doing
   so would provide another level of protection for user passwords.

 4.3 TLS Remote Client Authentication

   A web server application can (optionally) request that the remote
   client authenticate to the server using a digital signature.  In this
   case, the server requests client authentication and issues a random
   challenge which is signed and returned (with the client's certificate
   chain) by the client.  The user is strongly authenticated if the
   digital signature can be verified.

   TLS client authentication is not possible when the client currently
   has no credentials that are suitable for use with TLS.

 4.4 Conclusions

   - User passwords need never be stored "in the clear" on credential
     servers.
   - Credential servers SHOULD first request TLS remote client
     authentication whenever it is necessary to establish the identity
     of credential users.
   - If client authentication is not possible (e.g., the user currently



Gustafson & Nystrom         Expires: May 2001                  [Page 11]

INTERNET DRAFT             SACRED - Framework              November 2000


     has no valid credentials), a strong password should be used to
     authenticate the user.
   - In all cases, a different password should be used to derive the
     secret key used protect the credential data per se.  The key
     derivation formula should maximize the effort needed to mount a
     dictionary attack on the credential password (given a copy of the
     credential).
   - The effective level of protection afforded user passwords, no
     matter how they are transformed by one-way hash operations, etc.
     is directly proportional to how well passwords or their derived
     values are protected by the server.
   - It is expected that credential users will make use of physical
     security or additional encryption layers (or both) to further
     protect their credentials, whenever appropriate.

5. Credential Formats

 5.1 Background

   In order to ensure that credentials created on, and uploaded from,
   one device are possible to download to, and be used on, another
   device, there is a need to mandate support for at least one
   credential format.  This section describes two possible candidate
   formats, both unencumbered. While other formats (and even new ones)
   certainly are conceivable, it appears as if selection of an existing
   format offers the best approach.

   <<An accompanying document, describing the SACRED protocol in detail,
   should/will also mandate a credential format.>>

 5.2 PKCS #12

   PKCS #12 [PKCS12] provides a transfer syntax for personal identity
   information, including private keys, certificates, and miscellaneous
   secrets. It is widely used and would therefore constitute a natural
   choice for a mandated SACRED credential format.

 5.3 PKCS #15

   PKCS #15 [PKCS15] specifies a file and directory format for storing
   security-related information on cryptographic tokens (which are
   defined as portable devices capable of storing persistent data). PKCS
   #15 has seen its main use as a smart card application where it
   facilitates interoperability and credential portability. Among things
   speaking in favor of PKCS #15 are:

   - Capable of carrying more certificate types (e.g. WAP WTLS [WTLS]
     certificates]



Gustafson & Nystrom         Expires: May 2001                  [Page 12]

INTERNET DRAFT             SACRED - Framework              November 2000


   - Capable of carrying "raw" public keys
   - Standardized set of secret key types

   Among things speaking against selection of PKCS #15 as SACRED's
   mandated credential format are:

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

6. Open Issues

   This document is intended to foster further discussion of the
   framework and protocols that might be used to support credential
   mobility.  However, the authors recognize that there are many issues
   that remain to be resolved. Some of the most pressing are (in
   addition to those mentioned in [SACRED]:

   -Flexibility:  Users should be able to access their credentials from
    any device using any supported authentication method
   -Peer-to-Peer protocol: not described
   -The possibility of coupling (or not coupling) credential protection
    to the security provided by transport protocols has not been
    discussed
   -Is the triplet <PUT, GET, DELETE> enough for now?
   -Authentication for download - http/1.1 is not very flexible here

7. Security Considerations

   The Security Considerations section of [SACRED] applies to this memo
   as well. In particular, and as mentioned in [SACRED], mobile
   credentials will never be as secure as tamper-resistant hardware
   solutions. However, reasonable security may be accomplished through
   some relatively simple means, as outlined above and in [SACRED].

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

   For downloads, if the server is not authenticated, the user MUST be
   aware of risks associated with this fact.

8. References

   [SACRED]  Arsenault, A., Farrell, S., "Securely Available
             Credentials - Requirements", Internet Draft
             <draft-sacred-reqs-00.txt>, November 2000.
   [PKCS12]  "PKCS 12 v1.0: Personal Information Exchange Syntax",
             RSA Laboratories, June 24, 1999
   [PKCS15]  "PKCS #15 v1.1: Cryptographic Token Information Syntax



Gustafson & Nystrom         Expires: May 2001                  [Page 13]

INTERNET DRAFT             SACRED - Framework              November 2000


             Standard", RSA Laboratories, June 2000.
   [RFC2026] Bradner, S., "The Internet Standards Process - Revision
             3", BCP 9, RFC 2026, October 1996.
   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", RFC 2119, March 1997.
   [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0," RFC
             2246, January 1999.
   [RFC2289] Haller, N., Metz, P., Nesser, P., & Straw, M., "A One-Time
             Password System", RFC 2289.
   [RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC
             2444, November 1997.
   [RFC2616] R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter,
             Leach, T. Berners-Lee, "Hypertext Transfer Protocol -
             HTTP/1.1", RFC 2616, June 1999.
   [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
             RFC 2945, September 2000.
   [PRANDOM] Perlman, R., Kaufman, C., "Strong Password-Based
             Authentication Using Pseudorandom Moduli", Internet Draft
             <draft-perlman-strong-pass-00.txt>, June 2000.
   [SPEKE]   Jablon, D., "Strong Password-Only Authenticated Key
             Exchange", September 1996
   [ROAMING] Ford, W., Kaliski, B., "Server-Assisted Generation of a
             Strong Secret from a Password", June 2000.
   [WTLS]    WAP, "Wireless Application Protocol - Wireless Transport
             Layer Security Specification," Approved version
             18-Feb-2000.

9. Author's Addresses

   Dale Gustafson
   Future Foundation
   Eagan, MN 55122
   USA
   tel: +1 651-452-8369
   email: dale.gustafson@bpsi.net

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








Gustafson & Nystrom         Expires: May 2001                  [Page 14]

INTERNET DRAFT             SACRED - Framework              November 2000


10. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  In addition,
   the ASN.1 module presented in Appendix B may be used in whole or in
   part without inclusion of the copyright notice.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process shall be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.  This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.























Gustafson & Nystrom         Expires: May 2001                  [Page 15]


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