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

Versions: 00

INTERNET-DRAFT                                            A. Arsenault
expires in six months                                       Diversinet
                                                            S. Farrell
                                                Baltimore Technologies
                                                        September 2000



               Securely Available Credentials - Requirements
                   <draft-arsenault-sacred-reqs-00.txt>


Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

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

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

Abstract

   This document describes requirements to be placed on Securely
   Available Credentials (sacred) protocols.

   This is the initial draft of the sacred requirements specification
   and is therefore highly likely to change substantially.

   Discussion of this draft is taking place on the sacred list (see
   http://www.imc.org/ietf-sacred for subscription information).

Table Of Contents

   Status of this Memo.............................................1
   Abstract........................................................1
   Table Of Contents...............................................1
   1. Introduction.................................................2
       1.1  Background and Motivation..............................2
       1.2  Working Group Organization and Documents...............4
       1.3  Structure of This Document.............................4



Arsenault & Farrell                                           [Page 1]


INTERNET-DRAFT                                          September 2000



   2. Framework Requirements.......................................4
       2.1  Credential Server and Direct solutions.................4
       2.2  User authentication....................................6
       2.3  Credential Formats.....................................7
       2.4  Transport Issues.......................................7
   3. Protocol Requirements........................................7
       3.1  General Protocol Requirements..........................7
       3.2  Requirements for Credential Server-based solutions.....8
       3.3  Requirements for Direct-Transfer Solutions.............9
   4. Open Issues..................................................9
   5. Security Considerations.....................................10
   References.....................................................10
   Authors' Addresses.............................................10
   Full Copyright Statement.......................................11


1. Introduction.

   "Credentials" are information that can be used to establish the
   identity of an entity, or help that entity communicate securely.
   Credentials include such things as private keys, trusted roots,
   tickets, or the private part of a Personal Security Environment
   (PSE)[RFC2459] - that is, information used in secure communication
   on the Internet. Credentials are used to support various Internet
   protocols, e.g. S/MIME, IPSec and TLS.

   In simple models, users and other entities are provided with
   credentials, and these credentials stay in one place.  However, the
   number, and more importantly the number of different types, of
   devices that can be used to access the Internet is increasing.  It
   is now possible to access Internet services and accounts using
   desktop computers, laptop computers, wireless phones, pagers,
   personal digital assistants (PDAs) and other types of devices.
   Further, many users want to access private information and secure
   services from a number of different devices, and want access to the
   same information from any device.

   This draft identifies a set of requirements for credential mobility.
   The Working Group will also produce companion documents, which
   describe a framework for secure credential mobility, and a set of
   protocols for accomplishing this goal.

   The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
   in this document are to be interpreted as described in [RFC2119].

   <<Editorial comments are in angle brackets, like this>>.

1.1 Background and Motivation

   In simple models of Internet use, users and other entities are
   provided with credentials, and these credentials stay in one place.


Arsenault & Farrell                                           [Page 2]


INTERNET-DRAFT                                          September 2000


   For example, Mimi generates a public and private key on her desktop
   computer, provides the public key to a Certification Authority (CA)
   to be included in a certificate, and keeps the private key on her
   computer.  It never has to be moved.

   However, the number, and more importantly the number of different
   types, of devices that can be used to access the Internet is
   increasing.  It is now possible to access Internet services and
   accounts using desktop computers, laptop computers, wireless phones,
   pagers, personal digital assistants (PDAs) and other types of
   devices.  Further, many users want to access private information and
   secure services from a number of different devices, and want access
   to the same information from any device.

   For example, Mimi may want to able to send signed e-mail messages
   from her desktop computer when she is in the office, and from her
   laptop computer when she is on the road, and she does not want
   message recipients to know the difference.  In order to do this, she
   must somehow make her private key available on both devices - that
   is, that credential must be moved.

   Similarly, Will may want to retrieve and read encrypted e-mail from
   either his wireless phone or from his two-way pager.  He wants to
   use whichever device he has with him at the moment, and does not
   want to be denied access to his mail or to be unable to decrypt
   important messages simply because he has the wrong device.  Thus, he
   must be able to have the same private key available on both devices.

   It is generally accepted that the private key in these examples must
   be transferred securely. In the first example, the private key
   should not be exposed to anyone other than Mimi herself (and
   ideally, it would not be directly exposed to her). Furthermore, it
   must be transferred correctly. It must be transferred to the proper
   device, and it must not be corrupted - improperly modified - during
   transfer.

   One way of accomplishing these goals is to put the credentials on
   hardware tokens - e.g., smart cards, PCMCIA cards, or other devices.
   There are a number of types of hardware tokens today that provide
   secure storage for sensitive information, some degree of
   authentication, and interfaces to a number of types of wireless
   devices. Thus, in the second example above, Will could simply put
   his private key on a smart card, always take the smart card with
   him, and be assured that whichever device he uses to retrieve his e-
   mail, he will have all of the information necessary to decrypt and
   read messages.

   However, hardware tokens are not appropriate for every environment.
   They cost more than software-only solutions, and the additional
   security they provide may not be worth the incremental cost. Not all
   devices have interfaces for the same hardware tokens. And hardware
   tokens are subject to different failure modes than typical computers


Arsenault & Farrell                                           [Page 3]


INTERNET-DRAFT                                          September 2000


   - it is not at all unusual for a smart card to be lost or stolen; or
   for a PCMCIA card to physically break.

   Thus, it is appropriate to develop a complementary (?) software-
   based solution that allows credentials to be moved from one device
   to another, and provides a level of security sufficient for its
   environments.  While we recognize that the level of security
   provided by a software solution may not be as high as that provided
   by the hardware solutions discussed above, and some organizations
   may not consider it sufficient at all, we believe that a worthwhile
   solution can be developed.

   In the remainder of this draft we present a set of requirements for
   the secure transfer of software-based credentials.

1.2 Working Group Organization and Documents

   <<This section can be filled in more completely as work progresses
   and we know more about what the rest of the documents are. Note:
   sacred is not as yet an IETF working group, but is expected to
   become one in the near future.>>

   The Securely Available Credentials (sacred) Working Group is working
   on a set of protocols for the standardization of the secure transfer
   of credentials among devices.  A general framework is being
   developed that will give an abstract definition of protocols which
   can meet the credential-transfer requirements. This framework will
   allow for the development of a set of protocols, which may vary from
   one another in some respects. Specific protocols which conform to
   the framework can then be developed.

   Work is being done on a number of documents.  This document
   identifies the requirements for the general framework, as well as
   the requirements for specific protocols.  Another document will
   describe the protocol framework.  Still others will define the
   protocols themselves.

1.3 Structure of This Document

   Section 1 of this document provides an introduction to the problem
   being solved by this working group. Section 2 describes requirements
   on the framework.  Section 3 identifies the overall requirements for
   secure credential-transfer protocols, and separate requirements for
   the two different classes of solutions.  Section 4 addresses
   remaining issues. Section 5 identifies Security Considerations.

2. Framework Requirements

   This section describes requirements that the sacred framework has to
   meet, as opposed to requirements that are to be met by a specific
   protocol that uses the framework.

2.1 Credential Server and Direct solutions

Arsenault & Farrell                                           [Page 4]


INTERNET-DRAFT                                          September 2000



   There are at least two different ways to solve the problem of secure
   credential transfer between devices.  One class of solutions uses a
   "credential server" as an intermediate node, and the other class
   provides direct transfer between devices.

   A "credential server" can be likened to a server that sits in front
   of a repository where credentials can be securely stored for later
   retrieval. The credential server is active in the protocol, that is,
   it implements security enforcing functionality.

   To transfer credentials securely from one end device to another is a
   straightforward two-step process. Users can have their credentials
   securely "uploaded" from one device, e.g., a wireless phone, to the
   credential server.  They can be stored on the credential server, and
   "downloaded" when needed using another device; e.g., a two-way
   pager.

   The advantages of a credential server approach to credential
   transfer are two-fold:

  1.  It provides a conceptually clean and straightforward approach.
      For all end devices, there is one protocol, with a set of
      actions defined to transfer credentials from the device to the
      server, and another set of actions defined to transfer
      credentials from the server to the device. Furthermore, this
      protocol involves clients (the devices) and a server (the
      credential server), like many other Internet protocols; thus,
      the design of this protocol is likely to be familiar to most
      people familiar with most other Internet protocols.
  2.  It provides for a place where credentials can be securely stored
      for arbitrary lengths of time. Given a reasonable-quality server
      operating under generally accepted practices, it is unlikely the
      credentials will be permanently lost due to a hardware failure.
      This contrasts with systems where credentials are only stored on
      end devices, in which a failure of or the loss of the device
      could mean that the credentials are lost forever.

   However, the credential server approach has some potential
   disadvantages, too:

  1.  It might be somewhat expensive to maintain and run the
      credential server, particularly if there are stringent
      requirements on availability and reliability of the server.
  2.  The credential server may have to be "trusted" in some sense and
      also introduces a point of potential vulnerability.  (See the
      Security Considerations section for some of the issues.) Good
      protocol and system design will limit the vulnerability that
      exists at the credential server, but at a minimum, someone with
      access to the credential server will be able to delete
      credentials and thus deny the sacred service to system users.



Arsenault & Farrell                                           [Page 5]


INTERNET-DRAFT                                          September 2000


   Thus, some users may prefer a different class of solution, in which
   credentials are transferred directly from one device to another.  In
   this case "directly" may not mean from one device to another,
   without any other device participating in the transaction.  Rather,
   it simply means that the transfer is "direct" from the view of the
   credential-transfer protocol; there is no intermediate credential
   server involved which is active in security terms. It may be the
   case that at lower protocol layers, an arbitrary number of other
   devices are involved in moving bits around.

   For example, consider the case where Mimi sends a message from her
   wireless phone containing the credentials in question, and retrieves
   it using her two-way pager.  In getting from one place to another,
   the bits of the message cross the wireless phone network to a base
   station. These bits are likely transferred over the wired phone
   network to a message server run by the wireless phone operator, and
   are transferred from there over the Internet to a message server run
   by the paging operator. From the paging operator they are
   transferred to a base station and then finally to MimiÆs pager.
   Certainly, there are devices other than the original wireless phone
   and ultimate pager that are involved in the credential transfer, in
   the sense that they transmit bits from one place to another.
   However, to all devices except the pager and the wireless phone,
   what is being transferred is an un-interpreted and unprocessed set
   of bits.  No security-related decisions are made, and no actions are
   taken based on the fact that this message contains credentials, at
   any of the intermediate nodes.  They exist simply to forward bits.
   Thus, we consider this to be a "direct" transfer of credentials.

   Solutions involving the direct transfer of credentials from one
   device to another are potentially somewhat more complex than the
   credential-server approach, owing to the large number of different
   devices and formats that may have to be supported. Complexity is
   also added due to the fact that each device may in turn have to
   exhibit the behavior of both a client and a server.

   We believe that both classes of solutions are useful in certain
   environments, and thus that the sacred framework will have to define
   solutions for both. The extent to which elements of the above
   solutions overlap remains to be determined.

   This all leads to our first set of requirements:

   F1.     The framework MUST support both "credential server" and
           "direct" solutions.
   F2.     The "credential server" and "direct" solutions SHOULD use
           the same technology as far as possible.


2.2 User authentication

   There is a wide range of deployment options for credential mobility
   solutions. In many of these cases, it is useful to be able to re-use

Arsenault & Farrell                                           [Page 6]


INTERNET-DRAFT                                          September 2000


   an existing user authentication scheme, for example where passwords
   have previously been established, it may be more secure to re-use
   these than try to manage a whole new set of passwords. Different
   devices may also limit the types of user authentication scheme that
   are possible, e.g. not all mobile devices are practically capable of
   carrying out asymmetric cryptography.

   F3.     The framework MUST allow for protocols which support
           different user authentication schemes

2.3 Credential Formats

   Today there is no single standard format for credentials and this is
   not likely to change in the near future. There are a number of
   fairly widely deployed formats, e.g. [PGP], [PKCS#12] that have to
   be supported. This means that the framework has to allow for
   protocols supporting any credential format.

   F4.     The details of the actual credential type or format MUST be
           opaque, that is, the protocol MUST NOT depend on the
           internal structure of any credential type or format

   <<Open issue: Should we place any structure on credentials or really
   just regard them as octet strings? The latter is simpler, except
   that perhaps a password is used both to authenticate to a credential
   server *and* to encrypt the private parts of a pkcs#12 file.>>

2.4 Transport Issues

   Different devices allow for different transport layer possibilities,
   e.g. current WAP 1.x devices do not support TCP. For this reason the
   framework has to be transport "agnostic".

   F5.     The framework MUST allow use of different transports.

   <<Do we really need this? Couldn't we pick one and leave whatever
   doesn't fit to be worked on later? If we pick one, possiblities
   would include: directly over TCP or UDP or even SCTP, on top of
   HTTP, or SMTP or even FTP or BEEP. >>

3. Protocol Requirements

   In this section, we identify the requirements for secure credential-
   transfer solutions.  We will begin by identifying those requirements
   that must be met by all solutions. Then, we will identify additional
   requirements that must be met by solutions involving a credential
   server, followed by additional requirements that must be met by
   solutions involving direct transfer of credentials.

3.1 General Protocol Requirements

   Looking again at the examples described in Section 1.1, we can
   readily see that there are a number of requirements that must apply

Arsenault & Farrell                                           [Page 7]


INTERNET-DRAFT                                          September 2000


   to the transfer of credentials if the ultimate goal of supporting
   the Internet security protocols (e.g., TLS, IPSec, S/MIME) is to be
   met.  For example, the credentials must remain confidential at all
   times; it is unacceptable for nodes other than the end-userÆs
   device(s) to see the credentials in any readable, cleartext form.

   These, then, are the requirements that apply to all secure
   credential-transfer solutions:

   G1.     Credential transfer both to and from a device MUST be
           supported.
   G2.     Credentials MUST never be present in cleartext at any device
           other than the end user's.
   G3.     All transferred credentials SHOULD be authenticated in some
           way (e.g., digitally signed or MAC-ed).
   G4.     All transferred credentials MUST be integrity protected in
           some way (e.g., digitally signed or MAC-ed).
   G5.     The protocol MUST support a range of cryptographic
           algorithms, including symmetric and asymmetric algorithms,
           hash algorithms, and MAC algorithms.
   G6.     The protocol MUST support the use of various credential
           types and formats (e.g., X.509, PGP, PKCS12, ...).
   G7.     One mandatory to support credential format MUST be defined.
   G8.     One mandatory to support user authentication scheme MUST be
           defined.
   G9.     Credentials MAY be labelled with a text handle to allow the
           end user to select amongst a set of credentials or to name a
           particular credential.
   G10.    Full I18N support is REQUIRED (via UTF8 support).
   G11.    The protocol MUST NOT be vulnerable to any spoofing attacks
           (e.g. server spoofing). <<Open issue: how much detail needed
           here? Probably deserves a section of its own.>>
   G12.    The protocol MUST be able to support privacy, that is,
           anonymity for the client.

3.2 Requirements for Credential Server-based solutions

   The following requirements assume that there is a credential server
   from which credentials are downloaded to the end user device, and to
   which credentials are uploaded from an end user device.

   S1.     Credential downloads (to an end user) and upload (to the
           credential server) MUST be supported.
   S2.     Credentials MUST only be downloadable following user
           authentication.
   S3.     It MUST be possible to ensure the authenticity of a
           credential during upload.
   S4.     Different end user devices MAY be used to
           download/upload/manage the same set of credentials.
   S5.     The credential server MUST NOT have easy access to the
           cleartext credentials.
   S6.     Credential servers MUST be authenticated to the user for all
           operations except (possibly) download.

Arsenault & Farrell                                           [Page 8]


INTERNET-DRAFT                                          September 2000


   S7.     It MUST be possible to authenticate the credential server to
           the user prior to download (if the user is able to verify
           the authentication).
   S8.     The user SHOULD only have to enter a single secret value in
           order to download and use a credential.
   S9.     Sharing of secrets across multiple servers MUST be possible,
           so that penetration of some servers does not expose the
           private parts of a credential ("m-from-n" operation).
   S10.    The protocol MUST support "away-from-home" operation, where
           the user enters both a name and a domain (e.g.
           RoamingStephen@baltimore.ie) and the domain can be used in
           order to locate the user's credential server.
   S11.    Users MUST be able to manage their credentials stored on the
           credential server.
   S12.    The user MUST be able to retrieve a list of their
           credentials stored on a server; add credentials to the
           server; delete credentials from the server.
   S13.    Client-initiated authentication information (e.g. password)
           change MUST be supported.
   S14.    The user SHOULD be able to retrieve a list of
           accesses/changes to their credentials.


3.3 Requirements for Direct-Transfer Solutions

   The following requirements apply to solutions supporting the
   "direct" transfer of credentials from one device to another. (See
   Section 2 for the note on the meaning of "direct" in this case.)

   D1.     It SHOULD be possible for the receiving device to
           authenticate that the credential package indeed came from
           the purported sending device.
   D2.     In order for a sender to know that a credential has been
           received by a recipient, it SHOULD be possible for the
           receiving device to send an acknowledgment of credential
           receipt back to the sending device, and for the sending
           device to authenticate this acknowledgment.

4. Open Issues

   This document is intended to foster discussion of the requirements
   for secure credential transfer solutions. However, the authors
   recognize that there are many issues that remain to be resolved.
   Some of the most pressing are:

   Vulnerabilities: Which attacks can/should the framework and protocol
   protect against? What do we depend on the end user device for?

   Robustness: Credential stores should not unacceptably increase the
   potential for denial-of-service or other attacks.

   Performance: Users should not typically have to wait too long for
   access to credentials.

Arsenault & Farrell                                           [Page 9]


INTERNET-DRAFT                                          September 2000



   Bootstrapping: The use of, e.g. TLS server authentication as a way
   of having the client authenticate the credential server, depends on
   the client having a (set of) trusted root(s). As the protocol may be
   providing these roots, there may be some hard bootstrapping issues.

   Finally, we note that whether or not the user authentication,
   credential protection and specific credential formats should be
   separated, or should be intertwined, is an open issue that warrants
   careful consideration.

5. Security Considerations

   Mobile credentials will never be as secure as a "pure" hardware-
   based solution, because of potential attacks through the operating
   system of the end-user device. However, an acceptable level of
   security may be accomplished through some simple means. One should
   keep in mind, however, that platforms to which credentials are
   downloaded usually cannot be regarded as tamper-resistant, and it
   therefore is not too hard to analyze contents of their memories.
   Further, storage of private keys, even if they are encrypted, on a
   credential server, will be unacceptable in some environments.

   <<Probably should mention something about denial-of-service attacks
   on credential servers.  ItÆs not a huge deal, but we should at least
   acknowledge it.>>

References

   [PGP]       Callas, J., Donnerhacke, L., Finney, H., & Thayer, R.,
               "OpenPGP Message Format", RFC 2440.
   [PKCS12]    "PKCS #12 v1.0: Personal Information Exchange Syntax
               Standard", RSA Laboratories, June 24, 1999.
   [CMS]       Housley, R., "Cryptographic Message Syntax", RFC 2630
   [PKCS15]    "PKCS #15 v1.1: Cryptographic Token Information Syntax
               Standard," RSA Laboratories, June 2000.
   [RFC2026]   Bradner, S., "The Internet Standards Process -- Revision
               3", RFC 2026.
   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", RFC 2119.
   [RFC2459]   Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
               Public Key Infrastructure - X.509 Certificate and CRL
               profile", RFC 2459.
   [RFC2616]   "R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L.
               Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
               Protocol - HTTP/1.1", RFC 2616.

Authors' Addresses

   Alfred Arsenault
   Diversinet Corp.
   P.O. Box 6530
   Ellicott City, MD 21042


Arsenault & Farrell                                          [Page 10]


INTERNET-DRAFT                                          September 2000


   USA
   tel: +1 410-480-2052
   email: aarsenault@dvnet.com

   Stephen Farrell,
   Baltimore Technologies,
   61/62 Fitzwilliam Lane,
   Dublin 2,
   IRELAND
   tel: +353-1-647-3000
   email: stephen.farrell@baltimore.ie


Full Copyright Statement

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

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

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














Arsenault & Farrell                                          [Page 11]


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