Securely Available Credentials Protocol
RFC 3767

 
Document
Type RFC - Proposed Standard (June 2004; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream
WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG
IESG state RFC 3767 (Proposed Standard)
Telechat date
Responsible AD Steven Bellovin
Send notices to <stephen.farrell@cs.tcd.ie>, <magnus@rsasecurity.com>

Email authors IPR References Referenced by Nits Search lists

Network Working Group                                    S. Farrell, Ed.
Request for Comments: 3767                        Trinity College Dublin
Category: Standards Track                                      June 2004

                Securely Available Credentials Protocol

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes a protocol whereby a user can acquire
   cryptographic credentials (e.g., private keys, PKCS #15 structures)
   from a credential server, using a workstation that has locally
   trusted software installed, but with no user-specific configuration.
   The protocol's payloads are described in XML.  This memo also
   specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the
   protocol.  Security requirements are  met by mandating support for
   TLS and/or DIGEST-MD5 (through BEEP).

Table Of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  The Protocol. . . . . .  . . . . . . . . . . . . . . . . . . .  3
   3.  BEEP Profile for SACRED. . . . . . . . . . . . . . . . . . . .  9
   4.  IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 13
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Appendix A: XML Schema . . . . . . . . . . . . . . . . . . . . . . 17
   Appendix B: An Example of Tuning with BEEP . . . . . . . . . . . . 20
   Appendix C: Provision SACRED using other Protocols . . . . . . . . 23
   Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
   Full Copyright Statement. . . . . . . . . . . .  . . . . . . . . . 25

Farrell                     Standards Track                     [Page 1]
RFC 3767              Secure Credentials Protocol              June 2004

1.  Introduction

   Digital credentials, such as private keys and corresponding
   certificates, 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 credentials on different end-user devices.  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 document describes a protocol for the secure exchange of such
   credentials and is a realization of the abstract protocol framework
   described in [RFC3760].

   Many user-chosen passwords are vulnerable to dictionary attacks.  So
   the SACRED protocol is designed to give no information with which an
   attacker can acquire information for launching a dictionary attack,
   whether by eavesdropping or by impersonating either the client or
   server.

   The protocol also allows a user to create or delete an account,
   change her account password and/or credentials, and upload the new
   values to the server.  The protocol ensures that only someone that
   knew the old account password is able to modify the credentials as
   stored on the credential server.  The protocol does not preclude
   configuring a server to disallow some operations (e.g. credential
   upload) for some users.  The account management operations as a whole
   are optional implementations for both credential servers and clients.

   Note that there are potentially two "passwords" involved when using
   this protocol - the first used to authenticate the user to the
   credential server, and the second to decrypt (parts of) the
   credential following a download operation.  Where the context
   requires it, we refer to the former as the account password and the
   latter as the credential password.

   Using a protocol such as this is somewhat less secure than using a
   smart card, but can be used until smart cards and smart card readers
   on workstations become ubiquitous, and can be useful even after smart
   cards are ubiquitous, as a backup strategy when a user's smart card
   is lost or malfunctioning.

   The protocol sets out to meet the requirements in [REQS].
   Cryptographic credentials may take the form of private keys, PKCS #15
   [PKCS15], or structures.  As stated, a profile based on BEEP [BEEP]
Show full document text