idnits 2.17.1 draft-ietf-sacred-framework-07.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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 abstract seems to contain references ([RFC3157]), 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (November 2003) is 7462 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) == Missing Reference: 'ID-1' is mentioned on line 535, but not defined == Missing Reference: 'ID-2' is mentioned on line 537, but not defined == Missing Reference: 'ID1' is mentioned on line 585, but not defined == Missing Reference: 'ID2' is mentioned on line 587, but not defined == Unused Reference: 'RFC2026' is defined on line 997, but no explicit reference was found in the text == Unused Reference: 'RFC2289' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC2444' is defined on line 1036, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3157 -- Obsolete informational reference (is this intentional?): RFC 2246 (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 D. Gustafson 3 Future Foundation 4 M. Just 5 Treasury Board of 6 Canada 7 Internet Draft M. Nystrom 8 Document: draft-ietf-sacred-framework-07.txt RSA Security 9 Expires: May 2004 November 2003 11 Securely Available Credentials - Credential Server Framework 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 As the number, and more particularly the number of different types, 39 of devices connecting to the Internet increases, credential mobility 40 becomes an issue for IETF standardization. This document responds to 41 the requirements on protocols for secure exchange of credentials 42 listed in [RFC3157] by presenting an abstract protocol framework. 44 Securely Available Credentials - November 2003 45 Credential Server Framework 47 Table of Contents 49 STATUS OF THIS MEMO...................................................1 51 COPYRIGHT NOTICE......................................................1 53 ABSTRACT..............................................................1 55 1 INTRODUCTION........................................................3 57 2 FUNCTIONAL OVERVIEW.................................................3 59 2.1 DEFINITIONS .....................................................3 60 2.2 CREDENTIALS .....................................................5 61 2.3 NETWORK ARCHITECTURE ............................................6 63 3 PROTOCOL FRAMEWORK..................................................7 65 3.1 CREDENTIAL UPLOAD ...............................................9 66 3.2 CREDENTIAL DOWNLOAD ............................................10 67 3.3 CREDENTIAL REMOVAL .............................................11 68 3.4 CREDENTIAL MANAGEMENT ..........................................12 70 4 PROTOCOL CONSIDERATIONS............................................13 72 4.1 SECURE CREDENTIAL FORMATS ......................................13 73 4.2 AUTHENTICATION METHODS .........................................13 74 4.3 TRANSPORT PROTOCOL SUITES ......................................16 76 5 SECURITY CONSIDERATIONS............................................18 78 5.1 COMMUNICATIONS SECURITY ........................................18 79 5.2 SYSTEMS SECURITY ...............................................19 81 6 REFERENCES.........................................................20 83 6.1 NORMATIVE REFERENCES ...........................................20 84 6.2 INFORMATIVE REFERENCES .........................................21 86 7 AUTHOR'S ADDRESSES.................................................22 88 FULL COPYRIGHT STATEMENT.............................................22 89 Securely Available Credentials - November 2003 90 Credential Server Framework 92 1 Introduction 94 Digital credentials, such as private keys and corresponding 95 certificates, are used to support various Internet protocols, e.g. 96 S/MIME, IPSec, and TLS. In a number of environments end users wish to 97 use the same credentials on different end-user devices. In a 98 "typical" desktop environment, the user already has many tools 99 available to allow import/export of these credentials. However, this 100 is not very practical. In addition, with some devices, especially 101 wireless and other more constrained devices, the tools required 102 simply do not exist. 104 This document proposes a general framework for secure exchange of 105 such credentials and provides a high level outline that will help 106 guide the development of one or more SACRED credential exchange 107 protocols. 109 2 Functional Overview 111 Requirements for Securely Available Credentials are fully described 112 in [RFC3157]. These requirements assume that two distinctly 113 different network architectures will be created to support credential 114 exchange for roaming users: 116 a) Client/Server Credential Exchange 117 b) Peer-to-Peer Credential Exchange 119 This document describes the framework for one or more client/server 120 credential exchange protocols. 122 In all cases, adequate user authentication methods will be used to 123 ensure credentials are not divulged to unauthorized parties. As well, 124 adequate server authentication methods will be used to ensure that 125 each client's authentication information (see Section 2.1) is not 126 compromised, and to ensure that roaming users interact with 127 intended/authorized credential servers. 129 2.1 Definitions 131 This section provides definitions for several terms or phrases used 132 throughout this document. 134 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", 135 "RECOMMENDED" and "MAY" in this document are to be interpreted as 136 described in [RFC2119]. 138 client authentication information: information that is presented by 139 the client to a server to authenticate the client. This may 140 include a password token, a registration string that may have 141 been received out-of-band (and possibly used for initially 142 Securely Available Credentials - November 2003 143 Credential Server Framework 145 registering a roaming user) or data signed with a signature 146 key belonging to the client (e.g. as part of TLS [RFC2246] 147 client authentication). 149 credentials: cryptographic objects and related data used to support 150 secure communications over the Internet. Credentials may 151 consist of public/private key pairs, symmetric keys, X.509 152 public key certificates, attribute certificates, and/or 153 application data. Several standardized formats for the 154 representation of credentials exist, e.g. [PKCS12], [PKCS15] 155 (see "secured credentials" below). 157 passkey: a symmetric key, derived from a password. 159 password: a string of characters known only to a client and used for 160 the purposes of authenticating to a server and/or securing 161 credentials. A user may be required to remember more than 162 one password. 164 password token: a value derived from a password using a one-way 165 function that may be used by a client to authenticate to a 166 server. A password token may be derived from a password using 167 a one-way hash function, for example. 169 secured credentials: a set of one or more credentials that have been 170 cryptographically secured, e.g. encrypted/MACed with a 171 passkey. Secured credentials may be protected using more than 172 one layer of encryption, e.g. the credential is secured with 173 a passkey corresponding to a user's password and also by a 174 key known only to the server (the credential's stored form). 175 During network transfer, the passkey-protected credential may 176 be protected with an additional encryption layer using a 177 symmetric key chosen by the Credential Server (e.g., the 178 transmitted form). 180 strong password protocol: a protocol that authenticates clients to 181 servers securely (see e.g. [SPEKE] for a more detailed 182 definition of this), where the client need only memorize a 183 small secret (a password) and carries no other secret 184 information, and where the server carries a verifier 185 (password token) which allows it to authenticate the client. 186 A shared secret is negotiated between client and server and 187 is used to protect data subsequently exchanged. 189 Note the distinction between an "account password" and a "credential 190 password." An account password (and corresponding password token) is 191 used to authenticate to a Credential Server and to negotiate a key 192 that provides session level encryption between client and server. 194 A credential password is used to derive a passkey that's used to 195 provide persistent encryption and authentication for a stored 196 Securely Available Credentials - November 2003 197 Credential Server Framework 199 credential. Applicable secured credential standards documents (e.g. 200 [PKCS#15]) describe the technical details of specific password-based- 201 encryption (pbe) techniques that are used to protect credentials from 202 unauthorized use. 204 Although the same password value may be used to provide both 205 services, it is likely that different, algorithm specific passkeys 206 would be generated from this password (i.e. because of different salt 207 values, etc.). 209 In addition, although it may be more convenient for a user to 210 remember only a single password, differing security policies (e.g. 211 password rules) between the credential server and the credential 212 issuers may result in a user having to remember multiple passwords. 214 2.2 Credentials 216 This document is concerned with the secure exchange and online 217 management of credentials in a roaming or mobile environment. 218 Credentials MAY be usable with any end user device that can connect 219 to the Internet, such as: 221 - desktop or laptop PC 222 - mobile phone 223 - personal digital assistant (PDA) 224 - etc. 226 The end user system may, optionally, store its credential information 227 on special hardware devices that provide enhanced portability and 228 protection for user credentials. 230 Since the credential usually contains sensitive information that is 231 known only to the credential holder, credentials MUST NOT be sent in 232 the clear during network transmission and SHOULD NOT be in the clear 233 when stored on an end user device such as a diskette or hard drive. 234 For this reason, a secured credential is defined. Throughout this 235 document we assume that, at least from the point of view of the 236 protocol, a secured credential is an opaque (and at least partially 237 privacy and integrity protected) data object that can be used by a 238 network connected device. Once downloaded, clients must be able to 239 recover their credentials from this opaque format. 241 At a minimum, all supported credential formats SHOULD provide privacy 242 and integrity protection for private keys, secret keys, and any other 243 data objects that must be protected from disclosure or modification. 244 Typically, these security capabilities are part of the basic 245 credential format such that the credential (e.g., a data file) is 246 protected when stored on hard drives, flexible diskettes, etc. 248 During network transmission, the secured credential is protected with 249 a second (outer) encryption layer. The outer encryption layer is 250 Securely Available Credentials - November 2003 251 Credential Server Framework 253 created using a session-level encryption key that was derived during 254 the mutual authentication process. Effectively, secured credentials 255 traverse an "encrypted tunnel" that provides an additional layer of 256 privacy protection for credentials (and any other) information 257 exchanged. 259 2.3 Network Architecture 261 The network diagram below shows the components involved in the SACRED 262 client/server framework. 264 +--------+ +------------+ 265 | Client +-----------| Credential | 266 +--------+ 1 | Server | 267 \ +-----+------+ 268 \ | 269 \ | 2 270 \ | 271 \ 3 +-----+------+ 272 -----------| Credential | 273 | Store(s) | 274 +------------+ 276 Client - The entity that wants to retrieve their credentials from a 277 credential server. 279 Credential Server - The server that downloads secure credentials to 280 and uploads them from the client. The server is 281 responsible for authenticating the client to ensure that 282 the secured credentials are exchanged only with an 283 appropriate end user. The credential server is 284 authenticated to the client to ensure that the client's 285 authentication information is not compromised and so that 286 the user can trust the credentials retrieved. 288 Credential Store - The repository for secured credentials. There 289 might be access control features but those generally aren't 290 sufficient in themselves for securing credentials. The 291 credential server may be capable of splitting credentials 292 across multiple credential stores for redundancy or to 293 provide additional levels of protection for user 294 credentials. 296 Protocol 1 - The protocol used to authenticate the client and 297 credential server, and download and upload user credentials 298 from a credential server. 300 Protocol 2 - The protocol used by the Credential Server to store and 301 retrieve user credentials (LDAP, LDAP/SSL, or other). 303 Securely Available Credentials - November 2003 304 Credential Server Framework 306 Protocol 3 - The protocol used by the client to store and retrieve 307 user credentials from the credential store (LDAP, LDAP/SSL, 308 or other). 310 This framework describes the high level design for protocol 1. 311 Protocols 2 and 3 are closely related (but out of scope for this 312 document) and could be implemented using standard protocols, such as 313 LDAP or secure LDAP, or other standard or proprietary protocols. 314 Note also that any administrator-credential server protocols are 315 assumed to be server vendor specific and are not the subject of 316 SACRED standardization efforts at this time. 318 Clients are not precluded from exchanging credentials directly with a 319 credential store (or any other server of it's choosing). However, 320 mutual authentication with roaming users and a consistent level of 321 protection for credential data while stored on network servers and 322 while in transit is provided by SACRED protocols exchanged with the 323 credential server. Depending on credential server design, user 324 credentials may flow through the credential server to the credential 325 store or directly between the client and the credential store. 327 Also, users may upload their credentials to several credential 328 servers to obtain enhanced levels of availability. Coordination 329 (automatic replication) of user information or credential data among 330 several credential servers is currently beyond the scope of this 331 document. 333 3 Protocol Framework 335 This section provides a high level description of client/server 336 protocols that can be used to exchange and manage SACRED credentials. 338 The client/server credential exchange protocol is based on three 339 basic and abstract operations; "GET", "PUT", and "DELETE". The 340 secured credential exchange protocol is accomplished as follows: 342 connect - the client initiates a connection to a credential 343 server for the purpose of secure credential exchange. 345 mutual authentication/key negotiation - using a strong password 346 protocol (or equivalent) the client authenticates to the 347 server, the server authenticates to the client, and a 348 session level encryption key is negotiated. The details 349 of the mutual authentication protocol exchange are 350 dependent upon the particular authentication method 351 used. In all cases, the end result is to authenticate 352 the client to the server and server to the client, and 353 establish a strong, shared secret between the two 354 parties. 356 Securely Available Credentials - November 2003 357 Credential Server Framework 359 client request(s) - the SACRED client issues one or more high 360 level credential exchange requests (e.g., GET, PUT, or 361 DELETE). 363 server response(s) - the SACRED credential server responds to 364 each request, either performing the operation 365 successfully or indicating an appropriate error. 367 close - the client indicates it has no more requests for the 368 server at this time. The security context between client 369 and server is no longer needed. Close is a logical, 370 session management operation. 372 disconnect - the parties disconnect the transport level 373 connection between client and server. Note that 374 "connect" and "disconnect" are logical, transport-layer 375 dependent operations that enclose the protocol exchange 376 between the two communicating processes. 378 Each high-level credential exchange operation is made up of a 379 series of request-response pairs. The client initiates each 380 request, which the server processes before returning an 381 appropriate response. Each request must complete (server reports 382 success or failure) before the client issues the next request. 383 The server SHOULD be willing to service at least one upload or 384 download request following successful mutual authentication but 385 either party can terminate the logical connection at any time. 387 In the following sections, secured credentials and related values are 388 represented using the following notation: 390 SC-x is the secured credential file, which includes a format 391 identifier field and credential data. The credential 392 data is an opaque, encrypted data object (e.g. PKCS#15 393 or PKCS#12 file). The format identifier is needed to 394 correctly parse the credential data. 396 Name-x is an account-defined selector or locator (a user 397 friendly name) that is used to indicate a specific 398 secured credential. The name of each credential stored 399 under a given user account MUST be unique e.g. there may 400 be one credential called "financial" and another called 401 "healthcare", etc. At a minimum, credential names MUST 402 be unique across a given account/user name. When no name 403 is supplied for a GET operation, all credentials stored 404 for the given username will be returned. 406 ID-x is a distinct credential version indicator that MAY be used 407 to request a conditional GET/PUT/DELETE operation. This 408 credential-ID value SHOULD contain the server's "last- 409 modified" date and time (e.g. the time that this 410 Securely Available Credentials - November 2003 411 Credential Server Framework 413 particular credential version was stored on the server) 414 and MAY contain additional information such as a 415 sequence number or a (complete or partial) credential 416 fingerprint that is used to ensure the credential-ID is 417 unique from other credential versions stored under the 418 same user account and credential name. 420 All named credentials may be accessed by authenticating under a 421 single username. If a user needs or prefers to use more than one 422 distinct authentication password (and/or authentication method) to 423 protect access to several secured credentials, he/she SHOULD register 424 those credentials under distinct user/account names, one for each 425 different authentication method used. 427 3.1 Credential Upload 429 The purpose of a credential upload operation is to allow a client to 430 register new credentials, or replace currently stored credentials 431 (e.g. credentials that may have been updated by the client using 432 appropriate key management software). 434 The framework for the credential upload, as implemented using the PUT 435 operation, is: 437 - The client and server establish a mutually authenticated session 438 and negotiate a shared secret. 440 - The client will then issue a PUT message that contains the upload 441 credential and related data fields. 443 - The server will respond to the PUT, indicating the credential was 444 successfully stored on the server or that an error occurred. 446 The client's PUT request MAY contain an optional identifier 447 (credential-ID) field. If present, the new credential will only be 448 stored if a credential with the same name and credential-ID is 449 currently stored on the server (e.g. a logical REPLACE operation is 450 performed). The server MUST return an error if a client attempts to 451 replace a credential that does not exist on the server. 453 The credential server's response to a PUT request MUST contain a 454 credential version identifier (credential-ID) for the newly stored 455 credential that MAY be used by clients to optimize subsequent 456 download operations and avoid credential version mismatches. 458 Securely Available Credentials - November 2003 459 Credential Server Framework 461 3.1.1 Credential Upload Protocol Sequence 463 The following gives an example of a "credential upload" protocol 464 sequence: 466 client server 467 ------- ------- 469 < connect > --> 471 <--- mutual authentication ---> 473 < PUT SC-1, Name-1, [ID-1] > --> 474 <-- < Name-1, new-ID-1 > 475 < PUT SC-2, Name-2, [ID-2] > --> 476 <-- < Name-2, new-ID-2 > 478 ... 480 < close > --> 481 <-- OK (+ disconnect) 483 new-ID-x is the credential-ID of the newly stored credential. 485 3.2 Credential Download 487 Roaming clients can download their credentials at any time after they 488 have been uploaded to the server. 490 The framework for a credential download, as implemented using the GET 491 operation, is: 493 - The client SHOULD authenticate the server. 495 - The user MUST be authenticated (by the server). 497 - A GET request for the credential download is issued. 499 - The response contains the credential and format identifier. 501 The specific user credential being requested may be identified by 502 name in the message sent to the credential server. If successful, 503 the response MUST contain the requested credential data element 504 (format ID and data) as defined above. 506 If the user issues a GET request with a NULL credential name field, 507 the server SHOULD return all credentials stored under the current 508 user account. 510 Optionally, the client MAY include a credential-ID to indicate a 511 conditional download request. In this case, the server will return 512 Securely Available Credentials - November 2003 513 Credential Server Framework 515 the requested credential if and only if the ID of the credential 516 currently stored on the server does NOT match the ID specified. 518 The server should return either the requested credential or a 519 distinct response indicating that the conditional download was not 520 performed (e.g., the client already has a copy of this exact 521 credential). 523 3.2.1 Credential Download Protocol Sequence 525 The following gives an example of a "credential download" protocol 526 sequence: 528 client server 529 ------- -------- 531 < connect > --> 533 <--- mutual authentication --> 535 < GET Name-1, [ID-1] > --> 536 <-- < SC-1, ID-1' > 537 < GET Name-2, [ID-2] > --> 538 <-- < GET response > 540 ... 542 < close > --> 543 <-- OK (+ disconnect) 545 Notice that for the second request, no credential has been returned 546 since ID-2, as included in the client's request, matched the 547 identifier for the Name-2 credential. 549 3.3 Credential Removal 551 The framework for the credential removal, as implemented with the 552 DELETE operation, is: 554 - The credential server MUST be authenticated (by the client) using 555 a method-dependent protocol sequence. 557 - The user MUST be authenticated (by the server) using a method- 558 dependent protocol sequence. 560 - The user then sends a DELETE request message that contains the 561 credential name indicating which credential to remove. 563 - Optionally, the client may include a credential-ID in the DELETE 564 request. In this case, the credential will be deleted if the 565 request ID matches the ID of the credential currently stored on 566 Securely Available Credentials - November 2003 567 Credential Server Framework 569 the server. This may be done to ensure that a client intending to 570 delete their stored credential does not mistakenly delete a 571 different version of the credential. 573 3.3.1 Credential Removal Protocol Sequence 575 The following gives an example of a "credential removal" protocol 576 sequence: 578 client server 579 ------- -------- 581 < connect > --> 583 <-------- mutual authentication --------> 585 < DEL Name-1, [ID1] > --> 586 <-- < Name-1 deleted > 587 < DEL Name-2, [ID2] > --> 588 <-- < Name-2 deleted > 590 ... 592 < close > --> 593 <-- OK (+ disconnect) 595 3.4 Credential Management 597 Note that the three operations defined above (GET, PUT, DELETE) can 598 be used to perform the basic credential management operations: 600 - add a new credential on the server, 601 - update (replace) an existing credential, and 602 - delete an existing credential. 604 The information provided for these basic operations might be used to 605 help guide the design of more complex operations such as user 606 registration (add account), user deregistration (remove account), 607 change account password, or list all credentials. 609 Note that, in the case where a credential with the same name exists 610 on the server, uploading a NULL credential is logically equivalent to 611 removing a previously stored credential. 613 Securely Available Credentials - November 2003 614 Credential Server Framework 616 4 Protocol Considerations 618 4.1 Secure Credential Formats 620 To ensure that credentials created on, and uploaded from, one device 621 can be downloaded and used on any other device, there is a need to 622 define a single "mandatory to implement" credential format that must 623 be supported by all conforming client implementations. 625 At least two well-defined credential formats are available today: 626 [PKCS12] and [PKCS15]. 628 Other optional credential formats may also be supported if necessary. 629 For example, additional credential formats might be defined for use 630 with specific (compatible) client devices. Each credential format 631 MUST provide adequate privacy protection for user credentials when 632 they are stored on flexible diskettes, hard disks, etc. 634 Throughout this document, the credential is treated as an opaque 635 (encrypted) data object and, as such, the credential format does not 636 affect the basic credential exchange protocol. 638 4.2 Authentication Methods 640 Authentication is vitally important to ensure that credentials are 641 accepted from and delivered to the authorized end user only. If an 642 unsecured credential is delivered to some other party, the credential 643 may be more easily compromised. If a credential is accepted from an 644 unauthorized party, the user might be tricked into using a credential 645 that has been substituted by an attacker (e.g. an attacker might 646 replace a newer credential with an older credential belonging to the 647 same user). 649 Ideally, the list of authentication methods should be open ended, 650 allowing new methods to be added as needs are identified and as they 651 become available. For all credentials, the user authentication method 652 and data is defined when a user is first registered with the 653 credential server and may be updated from time to time thereafter by 654 the authorized user. 656 To adequately protect user credentials from unauthorized disclosure 657 or modification in a roaming environment, all SACRED authentication 658 methods MUST provide protection for user credentials in network 659 environments where attackers might attempt to exploit potential 660 security vulnerabilities. See SACRED Requirements [RFC3157], Section 661 3.1, Vulnerabilities. 663 At a minimum, each SACRED authentication method SHOULD ensure that: 665 - The server authenticates the client 666 - The client authenticates the server 667 Securely Available Credentials - November 2003 668 Credential Server Framework 670 - The client and server securely negotiate (or derive) a 671 cryptographically strong, secret key (e.g., a session key). 672 - The exchange of one or more user credentials is protected 673 using this session key. 675 It is expected that all SACRED client/server protocols will provide 676 each of these basic security functions. Some existing authentication 677 protocols that might be used for this purpose include: 679 - Strong password protocols 680 - TLS 682 Sections 4.2.1 and 4.2.2 provide some guidance about when to use 683 these authentication methods based on the generic security 684 capabilities they provide and the security elements (passwords, key 685 pairs, user certificates, CA certificates) that must be available to 686 the SACRED client. 688 4.2.1 Strong Password Protocols 690 Strong password protocols such as those described in [RFC2945], 691 [BM92], [BM94], and [SPEKE] MAY be used to provide mutual 692 authentication and privacy for SACRED protocols. 694 All strong password protocols require that user-specific values (i.e. 695 a passtoken and related values) be configured within the server. Only 696 a party who knows the password can calculate the verifier value. It 697 must be securely delivered to the server at a time when the client 698 establishes a relationship with the server. At connect time, 699 messages are exchanged between the two parties and complementary 700 algorithms are used to compute a shared common value known only to 701 the legitimate user and the server. Both parties derive a strong 702 (symmetric) key that may be used to secure communications between the 703 two parties. 705 4.2.2 TLS Authentication 707 TLS authentication may either be mutual between the client and server 708 or unilateral where only the server is authenticated to the client. 709 These options are described in the next two subsections. 711 In both cases, TLS can be used to authenticate the server whenever 712 the TLS client has been pre-configured with the necessary 713 certificates needed to validate the server's certificate chain 714 (including revocation status checking). 716 TLS Server Authentication (sTLS) 718 TLS provides a basic secure session capability (sometimes called 719 server-side TLS) whereby the client authenticates the server and a 720 pair of session level encryption keys is securely exchanged between 721 Securely Available Credentials - November 2003 722 Credential Server Framework 724 client and server. Following server authentication and security 725 context setup, all client requests and server responses exchanged are 726 integrity and privacy protected. 728 Protocol designers and implementors should be aware that the 729 flexibility of the certificate-based TLS server authentication method 730 creates security risks that need to be mitigated. Specifically, the 731 need to ensure the user is connected to the intended credential 732 server (secure site), and no other. The TLS v1.0 standard [RFC2246] 733 identifies the basis for managing this risk in section F.3 (see also 734 Section 5.2 in this document): 736 "Implementations and users must be careful when deciding which 737 certificates and certificate authorities are acceptable; a 738 dishonest certificate authority can do tremendous damage." 740 Note also that a faulty implementation of (increasingly complex) TLS 741 server certificate chain processing, by the SACRED client, could lead 742 to similar compromise, allowing successful credential server 743 masquerade or man-in-the-middle attacks. 745 An engineering approach that provides an enhanced or augmented server 746 authentication method may be warranted for SACRED protocol designs. 747 It is also important to understand that simple layering of 748 independently developed security protocols (e.g. using BEEP or 749 similar layering techniques) produces a complex, multilayer security 750 protocol that might be easily defeated by a combination-specific 751 attack that is able to expose and exploit known weaknesses of the 752 individual protocol(s). 754 When necessary, and after a TLS session has been established between 755 the two parties, the credential server can request that the client 756 provide her user id and password information to authenticate the 757 remote user. Preferably, client and server can cooperate to perform 758 an authentication operation that allows the server to authenticate 759 the client (and perhaps vice-versa) in a "zero knowledge manner". In 760 such cases, the client need not have a security credential. 762 TLS with Client Authentication (cTLS) 764 TLS provides an optional, secure session capability (sometimes called 765 client-side TLS) whereby the TLS server can request client 766 authentication by verifying the client's digital signature. 768 In order to use cTLS to provide mutual authentication, the client 769 must also be configured with at least one security credential that is 770 acceptable to the TLS server for remote client authentication 771 purposes. 773 4.2.3 Other Authentication Methods 774 Securely Available Credentials - November 2003 775 Credential Server Framework 777 Other authentication methods that provide the necessary security 778 capabilities MAY also be suitable for use with SACRED credential 779 exchange protocols. 781 4.3 Transport Protocol Suites 783 It is intended that one or more underlying protocol stacks may carry 784 the SACRED credential exchange protocols. It is recognized at the 785 outset that the use of several underlying protocol suites, although 786 not ideal from an interoperability standpoint, may well be required 787 to support the wide variety of needs anticipated. 789 The SACRED list members have discussed several protocol suites that 790 have been considered on their technical merits, each with distinct 791 benefits and protocol design/implementation costs. Among these 792 protocols are: 794 - TCP 795 - BEEP 796 - HTTP 798 All protocol suites listed here depend on TCP to provide a reliable, 799 end-to-end transport layer protocol. Each of these building block 800 approaches provides a different way of handling the remaining 801 application layer issues (basic session management, session level 802 security, presentation/formatting, application functionality). 804 4.3.1 TCP 806 This approach (layering a SACRED credential exchange protocol 807 directly on top of a TCP connection) requires the development of a 808 custom credential exchange messaging protocol that interfaces to a 809 TCP connection/socket. The primary benefit of this approach is the 810 ability to provide exactly the protocol functionality needed and no 811 more. Most server and client development environments already provide 812 the socket level API needed. 814 4.3.2 BEEP 816 This approach builds on the Blocks Extensible Exchange Protocol 817 (BEEP) described in [RFC3080]. BEEP provides general purpose, peer- 818 to-peer message exchange over any of several transport mechanisms 819 where the necessary transport layer mappings have been defined for 820 operation over TCP, TLS, etc. See also [RFC3081]. 822 BEEP provides the necessary user authentication/session security and 823 session management capabilities needed to support SACRED credential 824 exchange operations. 826 4.3.3 HTTP 827 Securely Available Credentials - November 2003 828 Credential Server Framework 830 This approach builds on the Hypertext Transport Protocol (HTTP) 831 described in [RFC1945] and [RFC2616]. HTTP provides general purpose 832 typing and negotiation of data representation, allowing systems to be 833 built independently of the data objects being transferred. HTTP 834 support is available in a wide variety of server and client 835 platforms, including portable devices that apply to roaming 836 environments (laptop PCs, PDAs, mobile phones, etc.). 838 HTTP is layered over TCP and can be used, optionally, with TLS to 839 provide authenticated, session level security. Either or both TLS 840 authentication options, sTLS or cTLS, may be used whenever TLS is 841 supported. 843 Securely Available Credentials - November 2003 844 Credential Server Framework 846 5 Security Considerations 848 The following security considerations identify general observations 849 and precautions to be considered for a framework supporting 850 credential mobility. When designing or implementing a protocol to 851 support this framework, one should recognize these security 852 considerations, and furthermore consult the SACRED Requirements 853 document [RFC3157] Security Considerations. 855 5.1 Communications Security 857 A SACRED PDU will contain information pertaining to client or server 858 authentication, or communication of credentials. 859 This information is subject to the traditional security concerns 860 identified below. 862 5.1.1 Confidentiality 864 The password or password verifier should be protected when 865 communicated from the client to credential server. The communicated 866 value should be resistant to a dictionary attack. 868 Similarly, the entity credentials must be confidentiality protected, 869 when communicated from the client to the server and 870 vice-versa. The communicated value should also resist a dictionary 871 attack. 873 5.1.2 Integrity 875 Communication integrity between the client and the credential server 876 is required. In this way, intended client operations may not be 877 altered (e.g. from an update to a deletion of credentials), nor may 878 clients be maliciously given "old" credentials (e.g. possibly by an 879 attacker replaying a previous credential download). 881 5.1.3 Entity Authentication 883 Proper authentication of the client and server is required to achieve 884 communication confidentiality and integrity. 886 The server must properly authenticate the client, so that credentials 887 are not mistakenly revealed to an attacker. 888 The client must ensure the proper identification of the credential 889 server so as to prevent revealing their password to an 890 attacker. These goals may be achieved implicitly with a strong 891 password-based protocol or explicitly. If the server is identified 892 explicitly, the user or client must ensure that the user password is 893 conveyed to a trusted server. This might be achieved by installing 894 appropriate trusted key(s) in the client. 896 5.1.4 Non-repudiation 897 Securely Available Credentials - November 2003 898 Credential Server Framework 900 There are no requirements upon the SACRED protocol itself to support 901 non-repudiation, although the context in which the credentials are 902 being used may have such requirements. 904 5.2 Systems Security 906 Systems security is concerned with protection of the protocol 907 endpoints (i.e. the client and server) and information 908 stored at the server in support of the SACRED protocol. 910 5.2.1 Client Security 912 As with most security protocols, secure use of the client often 913 relies, in part, upon secure behavior by the user. In the 914 case of a password-based SACRED protocol, users should be educated, 915 or enforced through policy, to choose passwords with a reasonable 916 amount of entropy. Additionally, users should be made aware of the 917 importance of protecting the confidentiality of their account 918 password. 920 In addition, the client interface should be designed to thwart 921 "shoulder surfing" where an attacker can observe the password as 922 entered by a user. This is often achieved by not echoing the exact 923 characters of the password when entered. 925 As well, the interface should encourage the entering of the password 926 in the appropriate interface field so that protections can be 927 properly enforced. For example, a user should be guided to not 928 mistakenly enter their password in the "username" field (since their 929 password would likely be echoed to the screen in this case, and might 930 not be encrypted when communicated to the server). This might be 931 accomplished via the automatic insertion of the user name or several 932 user name choices in the appropriate on-screen dialog field, for 933 example. 935 5.2.2 Client Security, TLS Server Authentication 937 When TLS is used as the SACRED transport protocol, the client 938 interface should be designed to allow the user to verify that she is 939 connected to the intended credential server. For example, client 940 software should allow for the visual display of identifying 941 components from the TLS server's X.509 certificate, like the server's 942 name, the certificate fingerprint, etc. 944 Users should be guided to verify this information regularly, allowing 945 ready recognition of trusted credential servers. In addition, users 946 should be made aware of the importance of verifying their credential 947 server's identity before initiating any credential exchange 948 operations. 950 Securely Available Credentials - November 2003 951 Credential Server Framework 953 A SACRED client SHOULD only be configured with those SACRED trust 954 anchors that are to be used by the client. Re-use of trust anchors 955 from other applications, e.g. Internet browsers is NOT RECOMMENDED. 957 5.2.3 Server Security 959 Password verifiers and user credentials must be afforded a high level 960 of protection at the credential server. In addition to salting and 961 super-encrypting each (to ensure resistance to offline dictionary 962 attacks), a system should ensure that credential server keys are 963 protected using sufficient procedural and physical access controls. 965 The login to the credential server should be resistant to replay 966 attacks. 968 Online attempts to access a particular user account should be 969 controlled, or at least monitored. Control might be enforced by 970 incorporating a time delay after a number of unsuccessful logins to a 971 particular account, or possibly the locking of the account 972 altogether. Alternatively, one might simply log unsuccessful attempts 973 where an administrative notice is produced once a threshold of 974 unsuccessful credential access attempts is reached. 976 5.2.4 Denial of Service 978 As with most protocols, Denial of Service (DoS) issues must also be 979 considered. In the case of SACRED, most DoS issues are a concern for 980 the underlying transport protocol. However, some concerns may still 981 be mitigated. 983 Service to a user might be denied in case their account is locked 984 after numerous unsuccessful login attempts. Consideration of 985 protection against online attacks must therefore be considered (as 986 described above). Proper user authentication should ensure that an 987 attacker does not maliciously overwrite a user's credentials. 988 Credential servers should be wary of repeated logins to a particular 989 account (which also identifies a possible security breach, as 990 described above) or abnormal volumes of requests to a 991 number of accounts (possibly identifying a DoS attack). 993 6 References 995 6.1 Normative references 997 [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", 998 BCP 9, RFC 2026, October 1996. 1000 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1001 Requirement Levels", RFC 2119, March 1997. 1003 Securely Available Credentials - November 2003 1004 Credential Server Framework 1006 [RFC3157] Arsenault, A., Farrell, S., "Securely Available Credentials 1007 - Requirements", RFC 3157, August 2001. 1009 6.2 Informative references 1011 [BM92] S. Bellovin and M. Merritt, "Encrypted Key Exchange: 1012 Password-based protocols secure against dictionary 1013 attacks", Proceedings of the IEEE Symposium on Research in 1014 Security and Privacy, May 1992. 1016 [BM94] S. Bellovin and M. Merritt, "Augmented Encrypted Key 1017 Exchange: a Password-Based Protocol Secure Against 1018 Dictionary Attacks and Password File Compromise, ATT Labs 1019 Technical Report, 1994. 1021 [PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax", RSA 1022 Laboratories, June 24, 1999 1024 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax 1025 Standard", RSA Laboratories, June 2000. 1027 [RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext 1028 Transfer Protocol-- HTTP/1.0", RFC 1945, May 1996. 1030 [RFC2246] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 1031 2246, January 1999. 1033 [RFC2289] Haller, N., Metz, P., Nesser, P., & Straw, M., "A One-Time 1034 Password System", RFC 2289. 1036 [RFC2444] Newman, C., "The One-Time-Password SASL Mechanism", RFC 1037 2444, November 1997. 1039 [RFC2616] R. Fielding, J. Gettys, J. Mogul,, H. Frysyk, L. Masinter, 1040 M. Leach, T. Berners-Lee, "Hypertext Transfer Protocol - 1041 HTTP/1.1", RFC 2616. 1043 [RFC2945] Wu, T., "The SRP Authentication and Key Exchange System", 1044 RFC 2945, September 2000. 1046 [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", 1047 RFC 3080, March 2001. 1049 [RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March 1050 2001. 1052 [SPEKE] Jablon, D., "Strong Password-Only Authenticated Key 1053 Exchange", September 1996. 1055 Securely Available Credentials - November 2003 1056 Credential Server Framework 1058 7 Author's addresses 1060 Dale Gustafson 1061 Future Foundation Inc. 1062 degustafson@comcast.net 1064 Mike Just 1065 Treasury Board of Canada Secretariat 1066 Just.Mike@tbs-sct.gc.ca 1068 Magnus Nystrom 1069 RSA Security Inc. 1070 magnus@rsasecurity.com 1072 Full Copyright Statement 1074 Copyright (C) The Internet Society (2003). All Rights Reserved. 1076 This document and translations of it may be copied and furnished 1077 to others, and derivative works that comment on or otherwise 1078 explain it or assist in its implementation may be prepared, 1079 copied, published and distributed, in whole or in part, without 1080 restriction of any kind, provided that the above copyright 1081 notice and this paragraph are included on all such copies and 1082 derivative works. However, this document itself may not be 1083 modified in any way, such as by removing the copyright notice or 1084 references to the Internet Society or other Internet 1085 organizations, except as needed for the purpose of developing 1086 Internet standards in which case the procedures for copyrights 1087 defined in the Internet Standards process shall be followed, or 1088 as required to translate it into languages other than English. 1090 The limited permissions granted above are perpetual and will not 1091 be revoked by the Internet Society or its successors or assigns. 1092 This document and the information contained herein is provided 1093 on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1094 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1095 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1096 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 1097 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1098 PARTICULAR PURPOSE.