idnits 2.17.1 draft-ietf-sacred-scenarios-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 255 has weird spacing: '... person is tr...' == Line 262 has weird spacing: '... In our inc...' == Line 263 has weird spacing: '...rom the norma...' == Line 266 has weird spacing: '...ind the next ...' == Line 267 has weird spacing: '...eration of w...' == (3 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 12, 2001) is 8466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N.D. McBurnett 3 Internet-Draft Avaya Inc. 4 Expires: August 13, 2001 February 12, 2001 6 SACRED Scenarios 7 draft-ietf-sacred-scenarios-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 13, 2001. 32 Copyright Notice 34 Copyright (C) The Internet Society (2001). All Rights Reserved. 36 Abstract 38 This memo presents scenarios for securely acquiring credentials. 39 This ID is an interim product of work-in-progress within the 40 Securely Available Credentials (sacred)[1] working group. 42 Table of Contents 44 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 45 2. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 4 46 2.1 Obtaining Root Certs . . . . . . . . . . . . . . . . . . . . 4 47 2.2 Home Desktop Computer . . . . . . . . . . . . . . . . . . . 4 48 2.3 Work Desktop Computer . . . . . . . . . . . . . . . . . . . 6 49 2.4 Public Lab / On-campus Shared Workstation . . . . . . . . . 6 50 2.5 Public Kiosk Mobility . . . . . . . . . . . . . . . . . . . 7 51 2.6 Platforms with Limited Capabilities . . . . . . . . . . . . 8 52 2.7 Uploading Credentials . . . . . . . . . . . . . . . . . . . 9 53 2.8 Changing authentication information . . . . . . . . . . . . 9 54 2.9 User Self-Enrollment . . . . . . . . . . . . . . . . . . . . 9 55 2.10 Bulk Initialization of a Credential Server's Repository . . 9 56 2.11 Possible scenarios to justify time-to-live requirement . . . 9 57 References . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 59 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 60 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 62 1. Introduction 64 The scenarios below are intended to provoke discussion of what 65 SACRED should and shouldn't do. It is not necessarily true that 66 SACRED should support all of these or to what extent SACRED should 67 support them. These scenarios should encompass most of the sorts of 68 things that we expect SACRED to play a part in. 70 [These scenarios are collected mostly as-is from several 71 individuals. From an editorial standpoint, no effort has been made 72 to hammer them into a coherent style, pending feedback on their 73 general utility, the preferred style, and additional input.] 75 2. Scenarios 77 2.1 Obtaining Root Certs 79 A new student, Carol, needs to configure her browser so it will work 80 in the campus environment. The campus has deployed their own 81 self-signed root certificate which is used to sign things like TLS 82 certificates for campus web servers, SACRED server certs, etc. They 83 have bundled this root certificate up as a SACRED credential named 84 ExampleU-Root (possibly along with trust policies of some sort, 85 etc.) and published the name and fingerprint of this bundle in some 86 paper medium (her acceptance letter, the campus newspaper, or the 87 like.) 89 Carol connects to the SACRED server and gets the ExampleU-Root 90 credential. Her client calculates and displays the fingerprint, and 91 since it matches the published fingerprint, Carol tells the client 92 to accept the credential. She can be confident that it authentic 93 without even needing to authenticate the SACRED server or present 94 any credentials of her own. 96 Note that other mechanisms may offer an alternative to checking a 97 fingerprint - e.g. the Password Derived Moduli (PDM) scheme could 98 work if the server had a userid and password for the user, and the 99 user could thus use these to authenticate the server, and accept the 100 root credentials simple on the basis of trusting an authenticated 101 server. 103 2.2 Home Desktop Computer 105 Scenario Overview 107 A university utilizing a PKI infrastructure for various applications 108 and services on-campus is likely to find that many of its users 109 would like to make use of the same PKI-enabled services and 110 applications on computers located in their residence. These home 111 computers may be owned either by the university or by the individual 112 but are permanently located at the residence as opposed to laptop 113 systems that may be taken home. The usage depicted in this scenario 114 may be motivated by formal telecommuting arrangements or simply by 115 the need to catch up on work from home in the evenings. The basic 116 scenario should apply equally well to the commercial, health care, 117 and higher education environments. 119 Assumptions 121 This scenario assumes that the institution has not implemented a 122 hardware token-based PKI mobility solution 123 The home computer has a dial-up as opposed to a permanent network 124 connection. 126 The PKI applications, whenever practical, should be functional in 127 both on-line and off-line modes. For example, the home user 128 signing an email message to be queued for later bulk sending and 129 the reading of a received encrypted message may be supported 130 off-line while composing and queuing of an encrypted message 131 might not be supported in off-line mode. 133 Applications using digital signatures will require 134 nonrepudiation. 136 There institution prefers that the user be identified via a 137 single certificate / key-pair from all computers used by the 138 individual. 140 The home computer system can not be directly supported by the 141 institution's IT staff. Hardware, operating system versions, and 142 operating system configurations will vary widely. Significant 143 software installations or specialized configurations will be 144 difficult to implement. 146 Uniqueness of Scenario 148 The PKI mobility support needed for this scenario is, in general, 149 similar to the other mobility scenarios. However, it does have 150 several unique aspects: 152 The home-user scenario differs from the general public 153 workstation case in that it provides the opportunity to 154 permanently store the user's certificate and key-pair on the 155 workstation. 157 Likewise the appropriate CA certificates and even certificates 158 for other users can be permanently stored or cached on the home 159 workstation. 161 Another key difference is the need to support off-line use of the 162 PKI credentials given the assumed dial-up network connection. 164 The level of hardware and software platform consistency 165 (operating system versions and configurations) will vary widely. 167 Finally, the level of available technical support is 168 significantly less for home systems than for equivalent systems 169 managed by the IT staff at the office location. 171 2.3 Work Desktop Computer 173 This will usually involve a subset of the requirements of the Home 174 Desktop Computer scenario. 176 2.4 Public Lab / On-campus Shared Workstation 178 Scenario Overview 180 Many colleges and universities operate labs full of computer systems 181 that are available for use by the general student population. These 182 computers are typically configured with identical hardware and an 183 operating system build that is replicated to all of the systems in 184 the lab. Many typical configurations provide no permanent storage 185 of any type while others may offer individual disk space for 186 personal files on a central server. Some scheme is generally used 187 to ensure that the configuration of the operating system is 188 preserved across users and that temporary files created by one user 189 are removed before the next user logs in. Students generally sit 190 down at the next available workstation without any clear pattern of 191 usage. 193 The same basic technical solutions used to operate public labs are 194 often also used in general environments where several people share a 195 single workstation. This is often found in locations with shift 196 work such as medical facilities and service bureaus that provide 197 services to multiple time zones. 199 Assumptions 201 This scenario assumes that the institution has not implemented a 202 hardware token-based PKI mobility solution. 204 The computer systems are permanently networked with LAN 205 connections. 207 The configuration of the computer system is centrally maintained 208 and customizations are relatively easy to implement. For example 209 it would be easy to load enterprise root certificates, LDAP 210 server configurations, specialized software, and any other needed 211 components of the PKI infrastructure on to the workstations. 213 Applications using digital signatures will require nonrepudiation 214 in some of the anticipated environments. Examples of this might 215 include homework submission in a public lab environment or 216 medical records in a health care environment. 218 The institution prefers that the user be identified via a single 219 certificate / key-pair from all computers used by the individual. 221 Many anticipated implementations of this scenario will not 222 implement any user authentication at the desktop operating system 223 level. Instead, user authentication will occur at during the 224 startup of networked applications such as email, web-based 225 services, etc. Login at the desktop level may be with generic 226 user names that are more targeted at matching printouts to 227 machines than identifying users. 229 Users, with almost ridiculous frequency, will walk away from a 230 system forgetting to first logout from running authenticated 231 applications. 233 Uniqueness of Scenario 235 The PKI mobility support needed for this scenario is, in general, 236 similar to the other mobility scenarios. However, it does have 237 several unique aspects: 239 Unlike situations with personal workstations, there is no 240 permanent storage available to hold user key pairs and 241 certificates. 243 Appropriate CA certificates and custom software are easily added 244 and maintained for these types of shared systems. 246 The workstations are installed in public locations and users will 247 frequently forget to close applications before permanently 248 walking away from the workstation. 250 2.5 Public Kiosk Mobility 252 Overview 254 This scenario describes the needs of the traveler or the shopper. 255 This person is traveling light (no computer) or is burdened with 256 everything but a computer. It recognizes the increasing availability 257 of internet access points in public spaces, such as libraries, 258 airports, shopping malls, and "cyber cafes". 260 The Need 262 In our increasingly mobile society, the chances of needing 263 information when away from the normal computing place are great. 264 One may need to look up a telephone number. Have you tried to find 265 a phone book at a public phone lately? It may become necessary to 266 use a data device to find the next place to rush to. Mapquest to 267 the rescue. With the proliferation of wireless devices (electronic 268 leashes), others have the ability to create a need for quick access 269 to electronic information. A pager can generate a need to check 270 the email inbasket or address book. A cell phone can drive you to 271 your database to answer a pressing question. 273 The ability to quickly access sensitive or protected information or 274 services from publicly available devices will only become more 275 necessary as we become more and more "connected". 277 The Device 279 The access device is more a function of the best discount or 280 marketing effort than of design. Any number of Intel based hardware 281 platforms will be encountered. Macintosh is encountered from time to 282 time. Linux has been spotted in a couple of local internet coffee 283 shops. 285 Since these devices are open to the public I/O ports are not likely 286 to be. In order to protect the device and it's immediate network 287 environment, most devices will be in some sort of protective 288 container. Access to serial, parallel, USB, firewire, SCSI, or 289 PCMCIA connections will not be possible. Likewise floppy, zip, or cd 290 drives. Therefore, any software "token" must be obtained from the 291 network itself. 293 The Concerns 295 1. Getting the "token". Since it will be necessary to obtain the 296 token (key, certificate, credential) from across the network. How 297 can it be protected during transit? 299 2. Where did you get it? One of the primary controls in the Public 300 Key Infrastructure is protection of the private key. Placing the key 301 on a host that is accessible from a public network means that there 302 is an inherent exposure from that network. The access controls and 303 other security measures on the host machine are an area of concern. 305 3. How did you get it? When you obtained the token from the server, 306 how did it know that you are you? Authentication becomes critical. 308 4. What happens to the token when you leave? You've checked your 309 mail, downloaded a recipe from that super-secure recipe server, 310 found out how to get to the adult beverage store for the... uh... 311 accessories... for the meal, and you're off! Is your token? Or is it 312 still sitting there on the public kiosk waiting for those youngsters 313 coming out of the music store to notice and cruise the information 314 highway on your ticket? 316 2.6 Platforms with Limited Capabilities 318 Cell Phones, PDAs, Appliances, etc. 320 2.7 Uploading Credentials 322 2.8 Changing authentication information 324 2.9 User Self-Enrollment 326 2.10 Bulk Initialization of a Credential Server's Repository 328 2.11 Possible scenarios to justify time-to-live requirement 330 [Under what circumstances should the protocol or SACRED credential 331 format get involved in time-to-live criteria? Does it imply that the 332 client software and host are trusted to enforce the restriction, 333 even though it is not part of the underlying certificates or 334 whatever in a way that can be validated by the party that relies on 335 the credential?] 337 References 339 [1] 341 [2] 343 [3] 345 Author's Address 347 Neal D. McBurnett 348 Avaya Inc. 349 1300 W 120th Ave. 350 Westminster, CO 80234 351 US 353 Phone: +1 303-538-4852 354 EMail: nealmcb@avaya.com 355 URI: http://bcn.boulder.co.us/~neal/ 357 Appendix A. Acknowledgements 359 The editor gratefully acknowledges the contributions of Jim Jokl, 360 Kevin Unrue and Internet2's HEPKI-TAG[2] (Higher Education PKI 361 Technical Advisory Group). 363 The XML source[3] for this document is available and can be 364 formatted into text or html via xml2rfc or via the web thanks to the 365 folks at http://xml.resource.org/. 367 Full Copyright Statement 369 Copyright (C) The Internet Society (2001). All Rights Reserved. 371 This document and translations of it may be copied and furnished to 372 others, and derivative works that comment on or otherwise explain it 373 or assist in its implementation may be prepared, copied, published 374 and distributed, in whole or in part, without restriction of any 375 kind, provided that the above copyright notice and this paragraph 376 are included on all such copies and derivative works. However, this 377 document itself may not be modified in any way, such as by removing 378 the copyright notice or references to the Internet Society or other 379 Internet organizations, except as needed for the purpose of 380 developing Internet standards in which case the procedures for 381 copyrights defined in the Internet Standards process must be 382 followed, or as required to translate it into languages other than 383 English. 385 The limited permissions granted above are perpetual and will not be 386 revoked by the Internet Society or its successors or assigns. 388 This document and the information contained herein is provided on an 389 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 390 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 391 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 392 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 393 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 395 Acknowledgement 397 Funding for the RFC editor function is currently provided by the 398 Internet Society.