RFC 3157

Securely Available Credentials - Requirements

📅 published August 2001, from ietf

Securely Available Credentials - Requirements 🎀

okay bestie, this is RFC 3157 💖 It's titled "Securely Available Credentials - Requirements" and it's an Informational doc, so it's just sharing info and isn't an Internet standard. It's from August 2001, and the two authors are A. Arsenault (Diversinet) and S. Farrell (Baltimore Technologies). The title block doesn't list any Obsoletes or Updates entries, so this doc doesn't replace or change any other RFC 🦋

Network Working Group, Request for Comments: 3157 🌸

Status of This Memo ✨

This memo gives info to the Internet community. It does not specify an Internet standard of any kind 💅 Distribution is unlimited, so share it with everyone 🫶

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

Abstract

This doc describes the requirements that Securely Available Credentials (SACRED) protocols have to meet 🔥

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 🧚

okay so "Credentials" are info that can prove who an entity is, or help that entity talk securely. Think private keys, trusted roots, tickets, or the private part of a Personal Security Environment (PSE) [RFC2510]. Basically it's the stuff used for secure communication on the Internet 🔐 Credentials back up protocols like S/MIME, IPSec and TLS, so they're literally everywhere 💜

Back in the day, users and other entities (like routers) got their credentials, and those credentials just stayed put in one place. But now there are SO many more devices that can get on the Internet, and it's only growing 📱 You can hop on from desktops, laptops, wireless phones, pagers, PDAs and other gadgets. Plus, people want their private info and secure services on any device, and they want the same stuff everywhere 😭 Credentials also sometimes have to move between routers when those get upgraded 🍓

This doc lists the requirements for credential mobility ✨ The Working Group is also making companion docs: one describing a framework for secure credential mobility, and another with protocols that actually get the job done 🎀

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

Okay, picture this. In simple setups, users and other entities get credentials, and those credentials stay in one spot. Like, Mimi makes a public and private key on her desktop, gives the public key to a Certification Authority (CA) so it gets put in a certificate, and keeps the private key on her computer. It never has to move 🌸

But here's the drama 😩 Mimi wants to send signed emails from her desktop when she's at the office, and from her laptop when she's on the road, and she does NOT want recipients to notice a difference. To pull that off, she has to get her private key onto both devices somehow. So that credential has to move 🦋

Will has a similar problem. He wants to read encrypted email on his wireless phone or his two-way pager, whichever one he's holding at the moment. He doesn't want to get locked out of his mail or be unable to decrypt important messages just because he grabbed the wrong device 💀 So he needs the same private key available on both devices 🔑

Someone also shared this router scenario, and it's giving main character energy 👑

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

Everyone agrees the private key in these examples has to be transferred securely 🔒 In Mimi's case, the private key should not be exposed to anyone except Mimi herself, and ideally it wouldn't even be directly exposed to her 🙈 And the transfer has to be correct too. The key has to land on the right device, and it can't get corrupted (improperly modified) along the way 😤

Making credentials securely available, in a way that works across different systems, is a huge win for network owners, admins and end users 🌈 The goal is for that value to mostly not depend on which hardware device you're using or what kind of storage the credential is saved to. Different storage (desktop or laptop memory, a 3.5 inch floppy diskette, a hard disk file, a cell phone, a smart card, and so on) comes with very different security properties and often very different protocol handling abilities 🧠 With SACRED protocols, users can securely move their credentials between locations, Internet devices and storage media whenever they need to ✨

For the rest of this doc, we list requirements for securely transferring software-based credentials 💖

1.2 Working Group Organization and Documents

The SACRED Working Group is standardizing a set of protocols for securely moving credentials between devices 🎀 They're building a general framework that gives an abstract definition of protocols which can meet the credential-transfer requirements. That framework lets people develop a set of protocols that may differ from each other in some ways, and specific protocols that conform to the framework can then be built 🧚

A bunch of docs are in progress 📚 This one lists the requirements for the general framework and for the specific protocols. Another doc will describe the protocol framework, and others will define the protocols themselves 💅

1.3 Structure of This Document

Here's the map 🗺️ Section 1 introduces the problem this Working Group is solving. Section 2 covers the requirements on the framework. Section 3 sets out the overall requirements for secure credential-transfer protocols, plus separate requirements for two different classes of solutions. Section 4 covers Security Considerations. Appendix A explains how SACRED solutions relate to credential-mobility solutions that use hardware components like smart cards. Appendix B has extra scenarios that were looked at while the requirements were being written 🦋

2. Framework Requirements ✨

Okay, this section is about requirements the SACRED framework itself has to meet 💜 That's different from requirements that a specific protocol built on top of the framework has to meet, so keep those two separate in your head 🫶

2.1. Credential Server and Direct solutions 💅

okay so 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" is basically 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, which means it implements security enforcing functionality 🔒

Transferring 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:

  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, so the design is likely to be familiar to most people who know most other Internet protocols 🧚
  2. It provides 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, where 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 especially 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 especially true for servers used by 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 it 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 🥀
Okay, that last one is the scary part, bestie. Whoever controls the server can delete your stuff. Design around it! 🚨

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) 🦋

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 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 to the protocol, though not to processing within the protocol's peers. The protocol MUST NOT depend on the internal structure of any credential type or format.

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.

3. Protocol Requirements 📋

In this section, we identify the requirements for secure credential-transfer solutions. We will begin by listing a set of relevant vulnerabilities and the requirements that must be met by all solutions. Then we 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. Vulnerabilities 👀

This section lists the vulnerabilities against which a SACRED protocol SHOULD offer protection. Any protocol claiming to meet the requirements listed in this document MUST explicitly indicate how (or whether) it offers protection for each of these vulnerabilities 🛡️

  • V1. A passive attacker can watch all packets on the network and later carry out a dictionary attack.
  • V2. An attacker can attempt to masquerade as a credential server in an attempt to get a client to reveal information on line that allows for a later dictionary attack.
  • V3. An attacker can attempt to get a client to decrypt a chosen "ciphertext" and get the client to make use of the resulting plaintext. The attacker may then be able to carry out a dictionary attack (e.g., if the plaintext resulting from "decryption" of a random string is used as a DSA private key).
  • V4. An attacker could overwrite a repository entry so that when a user subsequently uses what they think is a good credential, they expose information about their password (and hence the "real" credential) 😱
  • V5. An attacker can copy a credential server's repository and carry out a dictionary attack.
  • V6. An attacker can attempt to masquerade as a client in an attempt to get a server to reveal information that allows for a later dictionary attack.
  • V7. An attacker can persuade a server that a successful login has occurred, even if it hasn't.
  • V8. (Upload) An attacker can overwrite someone else's credentials on the server.
  • V9. (When using password-based authentication) An attacker can force a password change to a known (or "weak") password.
  • V10. An attacker can attempt a man-in-the-middle attack for lots
  • V11. User enters password instead of name.
  • V12. An attacker could attempt various denial-of-service attacks.

3.2 General Protocol Requirements ✨

Okay so looking back at the examples from Section 1.1, there are a bunch of requirements that MUST apply to credential transfer if we want the Internet security protocols (like TLS, IPSec, and S/MIME) to actually work 🔐. The big one is that credentials must stay confidential at all times. Other nodes besides the end user's device(s) cannot see them in any readable, cleartext form. That's a hard no 🙅‍♀️

So these 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 NOT be forced by the protocol to be present in cleartext at any device other than the end user's. 🙈
  • G3. The protocol SHOULD ensure that all transferred credentials be authenticated in some way (e.g., digitally signed or MAC-ed). 🖋️
  • G4. The protocol MUST support a range of cryptographic algorithms, including symmetric and asymmetric algorithms, hash algorithms, and MAC algorithms. 🧮
  • G5. The protocol MUST allow the use of various credential types and formats (e.g., X.509, PGP, PKCS12, ...). 🎀
  • G6. One mandatory to support credential format MUST be defined. 👑
  • G7. One mandatory to support user authentication scheme MUST be defined. 🔑
  • G8. The protocol MAY allow credentials to be labeled with a text handle, (outside the credential), to allow the end user to select amongst a set of credentials or to name a particular credential. 🏷️
  • G9. Full I18N support is REQUIRED (via UTF8 support) [RFC2277]. 🌍
  • G10. It is desirable that the protocol be able to support privacy, that is, anonymity for the client. 🦋
  • G11. Transferred credentials MAY incorporate timing information, for example a "time to live" value determining the maximum time for which the credential is to be usable following transfer/download. ⏳

3.3 Requirements for Credential Server-based solutions 🖥️

Okay, these next requirements assume there's a credential server. Credentials get downloaded from it to the end user device, and get uploaded back to it 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 or else only downloaded in a format that requires completion of user authentication for deciphering. 🔒
  • 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. Credential servers SHOULD be authenticated to the user for all operations except download. Note: This requirement can be ignored if the credential format itself is strongly protected, as there is no risk (other than user confusion) from an unauthenticated credential server. 🤷‍♀️
  • S6. It SHOULD be possible to authenticate the credential server to the user as part of a download operation. 🫶
  • S7. The user SHOULD only have to enter a single secret value in order to download and use a credential. 🙌
  • S8. Sharing of secrets across multiple servers MAY be possible, so that penetration of some servers does not expose the private parts of a credential ("m-from-n" operation). 🧩
  • S9. The protocol MAY 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. 🧳
  • S10. The protocol MUST provide operations allowing users to manage their credentials stored on the credential server, e.g., to retrieve a list of their credentials stored on a server; add credentials to the server; delete credentials from the server. 🗂️
  • S11. Client-initiated authentication information (e.g., password) change MUST be supported. 🔁
  • S12. The user SHOULD be able to retrieve a list of accesses/changes to their credentials. 👀
  • S13. The protocol MUST support user self-enrollment. One scenario calling for this is where a previously unknown user uploads his credential without requiring manual operator intervention. 🌱
  • S14. The protocol MUST NOT prevent bulk initializing of a credential server's repository. 🚫
  • S15. The protocol SHOULD require minimal client configuration. 🧁

3.4 Requirements for Direct-Transfer Solutions 📨

The full set of requirements for this case hasn't been figured out yet, so this list is provisional, meaning it's a work in progress 🚧 An additional requirements document (or a modification of this one) will be required before a direct-transfer protocol can move forward.

These requirements apply to solutions that support the "direct" transfer of credentials from one device to another. (See Section 2 for the note on what "direct" means 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. Security Considerations 🛡️

4.1 Hardware vs. Software 💻

Okay, real talk: mobile credentials will never be as secure as a "pure" hardware-based solution, because attacks through the operating system of the end-user device are always a risk 😭 That said, an acceptable level of security may be accomplished through some simple means. In fact, the level of security may be improved (compared to password encrypted files) through the use of SACRED protocols ✨

The platforms that credentials get downloaded to usually can't be regarded as tamper-resistant, so it therefore is not too hard to analyze contents of their memories 👀 Storing private keys on a credential server is also a no-go in some environments, even if the keys are encrypted 🙅‍♀️ And lastly, replacing installed or downloaded SACRED client software with a Trojan horse program will always be possible. A program like that could email the username and password to the program's author 💀

4.2 Auditing 📋

Although auditing is out of scope for the SACRED protocol development work, implementations should carefully audit events that may be security relevant 🔍 Credential server implementations in particular should audit all operations, and should include information about the time and source (e.g., IP address) of the operation, the claimed identity of the client (possibly masked - see below), the type and result of the operation, and possibly other operation specific information. Implementations should also take care not to include security sensitive information in the audit trail, especially not sensitive authentication information 🤐

It may be sensible to mask the claimed identity in some way, so that even if a user types her password into a "username" field, that that information is not in clear in the audit trail, regardless of whether or not it was received in clear 🎭

Similar mechanisms which should be supported, but which are out of scope of protocol development, include alerts and account locking, in particular following repeated authentication failures 🔔

4.3 Defense against attacks 🏰

Credential servers are major targets 🎯 Someone who can successfully attack a credential server might be able to gain access to the credentials of a number of users, unless those credentials are sufficiently protected (e.g., encrypted sufficiently that they cannot be read or used by someone who gains access to them). Attackers might also be able to substitute credentials of users, to carry out other system attacks. For example, an attacker could provide a user with a "trusted root" credential that the attacker controls, which would later allow the attacker to have some other certificate accepted by the user counter to policy 😱

On top of that, a credential server is a major target for denial of service attacks. Making a credential server unavailable to legitimate users can be a huge help to attackers. Users who couldn't retrieve needed credentials might be forced to operate insecurely, or not operate at all 🥺 Credential servers are especially vulnerable to denial of service attacks if they do lots of expensive cryptographic operations, since it might not take very many operations for the attacker to bring service to an unacceptable level 🔥

Thus, great care should be taken in designing systems that use credential servers to protect against these attacks. 🚨

References 📚

[PGP] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.

[PKCS12] "PKCS #12 v1.0: Personal Information Exchange Syntax Standard", RSA Laboratories, June 24, 1999.

[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.

[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000.

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2277] Alvestrand, H., " IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

[RFC2510] Adams, C. and S. Farrell, "Internet X.509 Public Key Infrastructure Certificate Management Protocols", RFC 2510, March 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol - HTTP/1.1", RFC 2616, June 1999.

Acknowledgements 🙏

The authors gratefully acknowledge the text containing additional use cases in Appendix B that was supplied by Neal Mc Burnett (nealmcb@avaya.com). 🌟

Authors' Addresses 🖊️

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

Phone: +1 410-480-2052
EMail: aarsenault@dvnet.com


Stephen Farrell,
Baltimore Technologies,
39 Parkgate Street,
Dublin 8,
IRELAND

Phone: +353-1-881-6000
EMail: stephen.farrell@baltimore.ie

Appendix A: A note on SACRED vs. hardware support ✨

okay so one way to hit a lot of the SACRED WG's goals is to put the credentials on hardware tokens 🔐 like smart cards, PCMCIA cards, or other devices. there are plenty of hardware tokens out there today that give you secure storage for sensitive info, some level of authentication, and interfaces to a bunch of wireless and other devices. so back in the second example from section 1.1, Will could just stash his private key on a smart card, always keep it on him, and be totally set. whatever device he uses to check his e-mail, he'll have everything he needs to decrypt and read his messages 💌

bestie, hardware tokens aren't the move for every environment 🙅‍♀️ they cost more than software-only solutions, and the extra security they give might or might not be worth the extra cost 💸 not every device has interfaces for the same hardware tokens either. and hardware tokens fail in different ways than regular computers do. it's super normal for a smart card to get lost or stolen 😭 or for a PCMCIA card to physically break 💀

so it makes sense to build a complementary software-based solution 🦋 that lets credentials move from one device to another and gives a level of security that works for its environment. ngl, we know the security from a software solution may not be as high as the hardware options above, and some orgs might not think it's enough at all. but we really do believe a worthwhile solution can be built 🫶

lastly, SACRED protocols can also complement hardware credential solutions 🎀 by offering standard ways to update the credentials stored on the hardware device. right now that usually means sending the device back to an admin centre, which is a major hassle and can be pricey 😩 SACRED protocols give you a way to update and manage credentials on hardware devices without needing that physical trip. no cap, iconic 👑

Appendix B: Additional Use Cases 🍓

this appendix walks through some extra use cases for SACRED protocols 🧚 SACRED protocols are NOT REQUIRED to support all of these use cases, so this text is purely informative, bestie 💜

B.1 Home/Work Desktop Computer 🏠

Scenario Overview

a university that uses a PKI for lots of on-campus apps and services is going to find that a lot of its users want to use those same PKI-enabled services and apps on computers at home 💻 these home computers might belong to the university or to the person, but they stay put at the residence, unlike laptops that get carried around. this could be because of formal telecommuting setups or just because you need to catch up on work at home in the evenings 🌙 the basic scenario should work just as well for commercial, health care, and higher education environments ✨

Assumptions

this scenario assumes the institution has not set up a hardware token-based PKI mobility solution 🙈

the home computer has a dial-up connection instead of a permanent network connection 📞

the PKI apps, whenever practical, should work both online and offline 🔥 for example, a home user signing an email to queue up for a later bulk send, and reading an encrypted message they received, may be supported offline. but composing and queuing an encrypted message might not be supported offline, and that's fine 💅

apps that use digital signatures may require "non-repudiation" 🧾

the institution prefers that the user be identified through a single certificate / key-pair from all computers the individual uses 🔑

the institution's IT staff can't directly support the home computer 😬 hardware, OS versions, and OS configurations are going to vary a ton. big software installs or specialized configs will be hard to pull off.

Uniqueness of Scenario

the PKI mobility support this scenario needs is, generally speaking, similar to the other mobility scenarios 🦋 but it has some unique vibes too:

  1. the home-user scenario is different from the general public workstation case because it gives you the chance to store the user's certificate and key-pair on the workstation permanently 🔐
  2. same goes for the appropriate CA certificates, and even certificates for other users, which can be permanently stored or cached on the home workstation 🗂️
  3. another big difference is that you need to support offline use of PKI credentials, since the dial-up connection is assumed 📴
  4. the level of hardware and software platform consistency (OS versions and configurations) will vary widely 🌈
  5. and finally, the level of tech support available is way lower for home systems than for equivalent systems managed by the IT staff at the office 🥲

B.2 Public Lab / On-campus Shared Workstation 🖥️

Scenario Overview

tons of colleges and universities run labs full of computers that the general student body can use 🎓 these machines usually have identical hardware and an OS build that's copied onto every system in the lab. a lot of typical setups don't give any permanent storage at all, while others offer personal disk space on a central server. some scheme is usually used to keep the OS configuration consistent across users and to delete temp files one user made before the next person logs in 🧹 students usually just sit down at whatever workstation is free, with no clear pattern at all.

the same basic tech used to run public labs also shows up in general environments where several people share one workstation 👯 you'll see this in places with shift work, like medical facilities and service bureaus that serve multiple time zones ⏰

Assumptions

  1. this scenario assumes the institution has not set up a hardware token-based PKI mobility solution 🙅‍♀️
  2. the computer systems are permanently networked with LAN connections 🔌
  3. the computer config is maintained centrally, and customizations are pretty easy to make 🛠️ for example, it would be easy to load enterprise root certificates, LDAP server configurations, specialized software, and any other needed PKI components onto the workstations.
  4. apps that use digital signatures may require "non-repudiation" in some of the expected environments 📝 examples include homework submission in a public lab, or medical records in a health care setting 🩺
  5. the institution prefers that the user be identified through a single certificate / key-pair from all computers the individual uses 🔑
  6. a lot of the expected implementations of this scenario won't do any user authentication at the desktop OS level 🤷‍♀️ instead, authentication happens when you start up networked apps like email, web-based services, and so on. login at the desktop level may use generic user names that are more about matching printouts to machines than identifying people 🖨️
  7. users, with almost ridiculous frequency, will walk away from a system without logging out of the authenticated apps they're running 🙃 (we all know the vibe 😭)

Uniqueness of Scenario

the PKI mobility support this scenario needs is, generally speaking, similar to the other mobility scenarios 🦋 but it has some unique aspects:

  1. unlike personal workstations, there's no permanent storage available to hold user key pairs and certificates 🚫
  2. appropriate CA certificates and custom software are easy to add and maintain on these shared systems 🧰
  3. the workstations sit in public places, and users will often forget to close their apps before they walk away for good 🏃‍♀️💨

B.3 Public Kiosk Mobility 📱

Overview

this scenario is about the traveler or the shopper 🛍️ this person is either traveling light (no computer) or is loaded down with everything except a computer 🧳 it's based on the growing number of internet access points in public spaces like libraries, airports, shopping malls, and "cyber cafes" ☕

The Need

we're getting more mobile every day, so the odds of needing info away from your usual computer are high 📈 you might need to look up a phone number. have you tried finding a phone book at a public phone lately? 📖💀 you might need a data device to figure out where to rush to next 🏃‍♀️ with all the wireless devices out there (electronic leashes 📟), other people can create a need for quick access to electronic info too. a pager can make you want to check your email inbox or address book, and a cell phone can send you to your database to answer a pressing question 📲

being able to quickly reach sensitive or protected info or services from public devices is only going to matter more as we get more and more "connected" 🌐💜

The Device

the access device depends more on whatever deal or marketing push was going on than on design 🏷️ you could run into basically any hardware platform.

since these devices are open to the public, their I/O ports are probably not going to be open to the public 🔒 to protect the device and its network environment, most devices will sit inside some kind of protective container 🛡️ you won't be able to use serial, parallel, USB, firewire, SCSI, or PCMCIA connections. same with floppy, zip, or CD drives 🚫💿 so any software "token" has to come from the network itself ☁️

The Concerns

  1. getting the "token" 🎟️ since the token (key, certificate, credential) has to come across the network, how do you protect it in transit? 🤔
  2. where did you get it? one of the main controls in PKI is protecting the private key 🗝️ putting the key on a host that's reachable from a public network means there's an inherent exposure from that network 😱 the access controls and other security measures on the host machine are a real worry.
  3. how did you get it? when you got the token from the server, how did it know that you are you? 🧐 authentication becomes critical here 🚨
  4. what happens to the token when you leave? you checked your mail, grabbed a recipe from that super-secure recipe server, looked up how to get to the adult beverage store for the... uh... accessories... for the meal, and you're out 🏃‍♀️ is your token still with you? or is it still sitting on the public kiosk, waiting for some youngsters coming out of the music store to notice and cruise the information highway on your ticket? 👀💀

Okay, the legal bit, but make it cute 💅 Copyright (C) The Internet Society (2001). All Rights Reserved. ✨

So you're totally allowed to copy this document and hand it to people, and you can even make derivative works that comment on or explain it or help with implementing it, in whole or in part, with no restrictions of any kind. The one condition is that the copyright notice and this paragraph have to stay on every copy and derivative work 🎀

BUT the document itself may not be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations 🙅‍♀️ The exceptions are when you need it for developing Internet standards (then the copyright procedures in the Internet Standards process must be followed) or when you need to translate it into a language other than English 🌈

These permissions are perpetual, and the Internet Society and its successors or assigns won't ever revoke them 🦋

This document and the info in it are provided "AS IS," 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 💀 Translation: no guarantees, bestie, read it at your own risk ⭐

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from