Network Working Group N.D. McBurnett
Internet-Draft Avaya Inc.
Expires: August 13, 2001 February 12, 2001
SACRED Scenarios
draft-ietf-sacred-scenarios-00
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.
This Internet-Draft will expire on August 13, 2001.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This memo presents scenarios for securely acquiring credentials.
This ID is an interim product of work-in-progress within the
Securely Available Credentials (sacred)[1] working group.
McBurnett Expires August 13, 2001 [Page 1]
Internet-Draft SACRED Scenarios February 2001
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Obtaining Root Certs . . . . . . . . . . . . . . . . . . . . 4
2.2 Home Desktop Computer . . . . . . . . . . . . . . . . . . . 4
2.3 Work Desktop Computer . . . . . . . . . . . . . . . . . . . 6
2.4 Public Lab / On-campus Shared Workstation . . . . . . . . . 6
2.5 Public Kiosk Mobility . . . . . . . . . . . . . . . . . . . 7
2.6 Platforms with Limited Capabilities . . . . . . . . . . . . 8
2.7 Uploading Credentials . . . . . . . . . . . . . . . . . . . 9
2.8 Changing authentication information . . . . . . . . . . . . 9
2.9 User Self-Enrollment . . . . . . . . . . . . . . . . . . . . 9
2.10 Bulk Initialization of a Credential Server's Repository . . 9
2.11 Possible scenarios to justify time-to-live requirement . . . 9
References . . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . 10
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
Full Copyright Statement . . . . . . . . . . . . . . . . . . 12
McBurnett Expires August 13, 2001 [Page 2]
Internet-Draft SACRED Scenarios February 2001
1. Introduction
The scenarios below are intended to provoke discussion of what
SACRED should and shouldn't do. It is not necessarily true that
SACRED should support all of these or to what extent SACRED should
support them. These scenarios should encompass most of the sorts of
things that we expect SACRED to play a part in.
[These scenarios are collected mostly as-is from several
individuals. From an editorial standpoint, no effort has been made
to hammer them into a coherent style, pending feedback on their
general utility, the preferred style, and additional input.]
McBurnett Expires August 13, 2001 [Page 3]
Internet-Draft SACRED Scenarios February 2001
2. Scenarios
2.1 Obtaining Root Certs
A new student, Carol, needs to configure her browser so it will work
in the campus environment. The campus has deployed their own
self-signed root certificate which is used to sign things like TLS
certificates for campus web servers, SACRED server certs, etc. They
have bundled this root certificate up as a SACRED credential named
ExampleU-Root (possibly along with trust policies of some sort,
etc.) and published the name and fingerprint of this bundle in some
paper medium (her acceptance letter, the campus newspaper, or the
like.)
Carol connects to the SACRED server and gets the ExampleU-Root
credential. Her client calculates and displays the fingerprint, and
since it matches the published fingerprint, Carol tells the client
to accept the credential. She can be confident that it authentic
without even needing to authenticate the SACRED server or present
any credentials of her own.
Note that other mechanisms may offer an alternative to checking a
fingerprint - e.g. the Password Derived Moduli (PDM) scheme could
work if the server had a userid and password for the user, and the
user could thus use these to authenticate the server, and accept the
root credentials simple on the basis of trusting an authenticated
server.
2.2 Home Desktop Computer
Scenario Overview
A university utilizing a PKI infrastructure for various applications
and services on-campus is likely to find that many of its users
would like to make use of the same PKI-enabled services and
applications on computers located in their residence. These home
computers may be owned either by the university or by the individual
but are permanently located at the residence as opposed to laptop
systems that may be taken home. The usage depicted in this scenario
may be motivated by formal telecommuting arrangements or simply by
the need to catch up on work from home in the evenings. The basic
scenario should apply equally well to the commercial, health care,
and higher education environments.
Assumptions
This scenario assumes that the institution has not implemented a
hardware token-based PKI mobility solution
McBurnett Expires August 13, 2001 [Page 4]
Internet-Draft SACRED Scenarios February 2001
The home computer has a dial-up as opposed to a permanent network
connection.
The PKI applications, whenever practical, should be functional in
both on-line and off-line modes. For example, the home user
signing an email message to be queued for later bulk sending and
the reading of a received encrypted message may be supported
off-line while composing and queuing of an encrypted message
might not be supported in off-line mode.
Applications using digital signatures will require
nonrepudiation.
There institution prefers that the user be identified via a
single certificate / key-pair from all computers used by the
individual.
The home computer system can not be directly supported by the
institution's IT staff. Hardware, operating system versions, and
operating system configurations will vary widely. Significant
software installations or specialized configurations will be
difficult to implement.
Uniqueness of Scenario
The PKI mobility support needed for this scenario is, in general,
similar to the other mobility scenarios. However, it does have
several unique aspects:
The home-user scenario differs from the general public
workstation case in that it provides the opportunity to
permanently store the user's certificate and key-pair on the
workstation.
Likewise the appropriate CA certificates and even certificates
for other users can be permanently stored or cached on the home
workstation.
Another key difference is the need to support off-line use of the
PKI credentials given the assumed dial-up network connection.
The level of hardware and software platform consistency
(operating system versions and configurations) will vary widely.
Finally, the level of available technical support is
significantly less for home systems than for equivalent systems
managed by the IT staff at the office location.
McBurnett Expires August 13, 2001 [Page 5]
Internet-Draft SACRED Scenarios February 2001
2.3 Work Desktop Computer
This will usually involve a subset of the requirements of the Home
Desktop Computer scenario.
2.4 Public Lab / On-campus Shared Workstation
Scenario Overview
Many colleges and universities operate labs full of computer systems
that are available for use by the general student population. These
computers are typically configured with identical hardware and an
operating system build that is replicated to all of the systems in
the lab. Many typical configurations provide no permanent storage
of any type while others may offer individual disk space for
personal files on a central server. Some scheme is generally used
to ensure that the configuration of the operating system is
preserved across users and that temporary files created by one user
are removed before the next user logs in. Students generally sit
down at the next available workstation without any clear pattern of
usage.
The same basic technical solutions used to operate public labs are
often also used in general environments where several people share a
single workstation. This is often found in locations with shift
work such as medical facilities and service bureaus that provide
services to multiple time zones.
Assumptions
This scenario assumes that the institution has not implemented a
hardware token-based PKI mobility solution.
The computer systems are permanently networked with LAN
connections.
The configuration of the computer system is centrally maintained
and customizations are relatively easy to implement. For example
it would be easy to load enterprise root certificates, LDAP
server configurations, specialized software, and any other needed
components of the PKI infrastructure on to the workstations.
Applications using digital signatures will require nonrepudiation
in some of the anticipated environments. Examples of this might
include homework submission in a public lab environment or
medical records in a health care environment.
The institution prefers that the user be identified via a single
certificate / key-pair from all computers used by the individual.
McBurnett Expires August 13, 2001 [Page 6]
Internet-Draft SACRED Scenarios February 2001
Many anticipated implementations of this scenario will not
implement any user authentication at the desktop operating system
level. Instead, user authentication will occur at during the
startup of networked applications such as email, web-based
services, etc. Login at the desktop level may be with generic
user names that are more targeted at matching printouts to
machines than identifying users.
Users, with almost ridiculous frequency, will walk away from a
system forgetting to first logout from running authenticated
applications.
Uniqueness of Scenario
The PKI mobility support needed for this scenario is, in general,
similar to the other mobility scenarios. However, it does have
several unique aspects:
Unlike situations with personal workstations, there is no
permanent storage available to hold user key pairs and
certificates.
Appropriate CA certificates and custom software are easily added
and maintained for these types of shared systems.
The workstations are installed in public locations and users will
frequently forget to close applications before permanently
walking away from the workstation.
2.5 Public Kiosk Mobility
Overview
This scenario describes the needs of the traveler or the shopper.
This person is traveling light (no computer) or is burdened with
everything but a computer. It recognizes the increasing availability
of internet access points in public spaces, such as libraries,
airports, shopping malls, and "cyber cafes".
The Need
In our increasingly mobile society, the chances of needing
information when away from the normal computing place are great.
One may need to look up a telephone number. Have you tried to find
a phone book at a public phone lately? It may become necessary to
use a data device to find the next place to rush to. Mapquest to
the rescue. With the proliferation of wireless devices (electronic
leashes), others have the ability to create a need for quick access
to electronic information. A pager can generate a need to check
McBurnett Expires August 13, 2001 [Page 7]
Internet-Draft SACRED Scenarios February 2001
the email inbasket or address book. A cell phone can drive you to
your database to answer a pressing question.
The ability to quickly access sensitive or protected information or
services from publicly available devices will only become more
necessary as we become more and more "connected".
The Device
The access device is more a function of the best discount or
marketing effort than of design. Any number of Intel based hardware
platforms will be encountered. Macintosh is encountered from time to
time. Linux has been spotted in a couple of local internet coffee
shops.
Since these devices are open to the public I/O ports are not likely
to be. In order to protect the device and it's immediate network
environment, most devices will be in some sort of protective
container. Access to serial, parallel, USB, firewire, SCSI, or
PCMCIA connections will not be possible. Likewise floppy, zip, or cd
drives. Therefore, any software "token" must be obtained from the
network itself.
The Concerns
1. Getting the "token". Since it will be necessary to obtain the
token (key, certificate, credential) from across the network. How
can it be protected during transit?
2. Where did you get it? One of the primary controls in the Public
Key Infrastructure is protection of the private key. Placing the key
on a host that is accessible from a public network means that there
is an inherent exposure from that network. The access controls and
other security measures on the host machine are an area of concern.
3. How did you get it? When you obtained the token from the server,
how did it know that you are you? Authentication becomes critical.
4. What happens to the token when you leave? You've checked your
mail, downloaded a recipe from that super-secure recipe server,
found out how to get to the adult beverage store for the... uh...
accessories... for the meal, and you're off! Is your token? Or is it
still sitting there on the public kiosk waiting for those youngsters
coming out of the music store to notice and cruise the information
highway on your ticket?
2.6 Platforms with Limited Capabilities
Cell Phones, PDAs, Appliances, etc.
McBurnett Expires August 13, 2001 [Page 8]
Internet-Draft SACRED Scenarios February 2001
2.7 Uploading Credentials
2.8 Changing authentication information
2.9 User Self-Enrollment
2.10 Bulk Initialization of a Credential Server's Repository
2.11 Possible scenarios to justify time-to-live requirement
[Under what circumstances should the protocol or SACRED credential
format get involved in time-to-live criteria? Does it imply that the
client software and host are trusted to enforce the restriction,
even though it is not part of the underlying certificates or
whatever in a way that can be validated by the party that relies on
the credential?]
McBurnett Expires August 13, 2001 [Page 9]
Internet-Draft SACRED Scenarios February 2001
References
[1] <http://www.ietf.org/html.charters/sacred-charter.html>
[2] <http://www.educause.edu/hepki/>
[3] <http://bcn.boulder.co.us/~neal/ietf/>
Author's Address
Neal D. McBurnett
Avaya Inc.
1300 W 120th Ave.
Westminster, CO 80234
US
Phone: +1 303-538-4852
EMail: nealmcb@avaya.com
URI: http://bcn.boulder.co.us/~neal/
McBurnett Expires August 13, 2001 [Page 10]
Internet-Draft SACRED Scenarios February 2001
Appendix A. Acknowledgements
The editor gratefully acknowledges the contributions of Jim Jokl,
Kevin Unrue and Internet2's HEPKI-TAG[2] (Higher Education PKI
Technical Advisory Group).
The XML source[3] for this document is available and can be
formatted into text or html via xml2rfc or via the web thanks to the
folks at http://xml.resource.org/.
McBurnett Expires August 13, 2001 [Page 11]
Internet-Draft SACRED Scenarios February 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). 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. 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 must 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
McBurnett Expires August 13, 2001 [Page 12]
