Securely Available Credentials - Requirements
RFC 3157

Document Type RFC - Informational (August 2001; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3157 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text