rfc3157.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/4 页

Network Working Group                                       A. Arsenault
Request for Comments: 3157                                    Diversinet
Category: Informational                                       S. Farrell
                                                  Baltimore Technologies
                                                             August 2001


             Securely Available Credentials - Requirements

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

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

Abstract

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

Table Of Contents

   1. Introduction.................................................1
   2. Framework Requirements.......................................4
   3. Protocol Requirements........................................7
   4. Security Considerations.....................................10
   References.....................................................12
   Acknowledgements...............................................12
   Authors' Addresses.............................................13
   Appendix A: A note on SACRED vs. hardware support..............14
   Appendix B: Additional Use Cases...............................14
   Full Copyright Statement.......................................20

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)
   [RFC2510] - 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.





Arsenault & Farrell          Informational                      [Page 1]

RFC 3157                 SACRED - Requirements               August 2001


   In simple models, users and other entities (e.g., computers like
   routers) 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.  Similarly credentials may
   have to be moved between routers when they are upgraded.

   This document 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].

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

   The following scenario relating to routers has also been offered:
   "Once upon a time, a router generated a keypair.  The administrators
   transferred the public key of that router to a lot of other (peer)
   routers and used that router to encrypt traffic to the other routers.
   And this was good for many years.  Then one day, the network



Arsenault & Farrell          Informational                      [Page 2]

RFC 3157                 SACRED - Requirements               August 2001


   administrators found that this particular little router couldn't
   handle an OC-192.  So they trashed it and replaced it with a really
   big router.  While they were there, the craft workers inserted a
   smart card into the router and logged into the router.  They gave the
   appropriate commands and entered the correct answers and so the
   credentials (keypair) were transferred to the new, big router.
   Alternatively, the craft people could have logged into the router,
   given it a minimal configuration and transferred the credentials from
   a credential server to the router.  They had to perform the correct
   incantations and authentications for the transfer to be successful.
   In this way, the identity of the router was moved from an old router
   to a new one.  The administrators were glad that they didn't have to
   edit the configurations of all of the peer routers as well."

   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.

   Making credentials securely available (in an interoperable fashion)
   will provide substantial value to network owners, administrators, and
   end users.  The intent is that this value be provided largely
   independent of the hardware device used to access the secure
   credential and the type of storage medium to which the secure
   credential is written.  Different credential storage devices, (e.g.,
   desktop or laptop PC computer memory, a 3.5 inch flexible diskette, a
   hard disk file, a cell phone, a smart card, etc.) will have very
   different security characteristics and, often very different protocol
   handling capabilities.  Using SACRED protocols, users will be able to
   securely move their credentials between different locations,
   different Internet devices, and different storage media as needed.

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

1.2 Working Group Organization and Documents

   The SACRED Working Group is working on the standardization of a set
   of protocols for securely transferring 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 that conform to the framework can then be
   developed.




Arsenault & Farrell          Informational                      [Page 3]

RFC 3157                 SACRED - Requirements               August 2001


   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
   two different classes of solutions.  Section 4 identifies Security
   Considerations.  Appendix A describes the relationship of the SACRED
   solutions and credential-mobility solutions involving hardware
   components such as smart cards.  Appendix B contains some additional
   scenarios which were considered when developing the requirements.

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

   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.

   Some advantages of a credential server approach compared to
   credential transfer are:







Arsenault & Farrell          Informational                      [Page 4]

RFC 3157                 SACRED - Requirements               August 2001


   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.

   3. The credential server may be able to enforce a uniform security
      policy regarding credential handling.  This is particularly the
      case where credentials are issued by an organization for its own
      purposes, and are not "created" by the end user, and so must be
      governed by the policies of the issuer, not the user.

   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.  This is particularly
      true for servers which are used for a large community of users.
      When the credential server is intended for a small community, the
      complexity and cost would be much less.

   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.

   Thus, some users may prefer a different class of solution, in which
   credentials are transferred directly from one device to another
   (i.e., having no intermediary element that processes or has any
   understanding of the credentials).