idnits 2.17.1 draft-ietf-sacred-protocol-bss-09.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 6 months document validity. ** 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 493 has weird spacing: '...Request ok ...' == Line 494 has weird spacing: '...Request ok ...' == Line 495 has weird spacing: '...Request ok ...' -- 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 7467 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS15' ** Downref: Normative reference to an Informational RFC: RFC 3157 (ref. 'REQS') ** Obsolete normative reference: RFC 2222 (ref. 'SASL') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3268 (ref. 'TLSAES') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 3075 (ref. 'XMLDSIG') (Obsoleted by RFC 3275) -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLSCHEMA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DDOS' ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) -- Possible downref: Non-RFC (?) normative reference: ref. 'XKMS' -- Possible downref: Non-RFC (?) normative reference: ref. 'XBULK' Summary: 14 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Editor: Stephen Farrell 3 expires in six months Trinity College Dublin 4 November 2003 5 Securely Available Credentials Protocol 6 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 10 of [RFC2026]. 12 Internet-Drafts are working documents of the Internet Engineering 13 Task Force (IETF), its areas, and its working groups. Note that 14 other groups may also distribute working documents as Internet- 15 Drafts. Internet-Drafts are draft documents valid for a maximum of 16 six months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- Drafts 18 as reference material or to cite them other than as "work in 19 progress." 20 The list of current Internet-Drafts can be accessed at 21 http://www.ietf.org/ietf/1id-abstracts.txt 22 The list of Internet-Draft Shadow Directories can be accessed at 23 http://www.ietf.org/shadow.html. 25 Abstract 27 This document describes a protocol whereby a user can acquire 28 cryptographic credentials (e.g., private keys, PKCS #15 structures) 29 from a credential server, using a workstation that has locally 30 trusted software installed, but with no user-specific configuration. 31 The protocol's payloads are described in XML. This memo also 32 specifies a BEEP profile of the protocol. Security requirements are 33 met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). 35 Table Of Contents 37 Status of this Memo.............................................1 38 Abstract........................................................1 39 Table Of Contents...............................................1 40 1. Introduction.................................................2 41 2. The protocol.................................................3 42 3. BEEP Profile for SACRED......................................8 43 4. IANA Considerations.........................................12 44 5. Security Considerations.....................................12 45 References.....................................................14 46 Acknowledgements...............................................15 47 Editor's Address...............................................15 48 Full Copyright Statement.......................................15 49 Appendix A: XML Schema.........................................16 50 Appendix B: An Example of Tuning with BEEP.....................20 51 Appendix C: Provision SACRED using other Protocols.............23 52 Appendix D: Changes & Open Issues..............................24 53 1. Introduction 55 Digital credentials, such as private keys and corresponding 56 certificates, are used to support various Internet protocols, e.g. 57 S/MIME, IPSec, and TLS. In a number of environments end users wish 58 to use the same credentials on different end-user devices. In a 59 "typical" desktop environment, the user already has many tools 60 available to allow import/export of these credentials. However, 61 this is not very practical. In addition, with some devices, 62 especially wireless and other more constrained devices, the tools 63 required simply do not exist. 65 This document describes a protocol for the secure exchange of such 66 credentials and is a realization of the abstract protocol framework 67 described in [RFC3...] <> 69 Many user-chosen passwords are vulnerable to dictionary attacks. So 70 the SACRED protocol is designed to give no information with which an 71 attacker can acquire information for launching a dictionary attack, 72 whether by eavesdropping or by impersonating either the client or 73 server. 75 The protocol also allows a user to create or delete an account, 76 change her account password and/or credentials and upload the new 77 values to the server. The protocol ensures that only someone that 78 knew the old account password is able to modify the credentials as 79 stored on the credential server. The protocol does not preclude 80 configuring a server to disallow some operations (e.g. credential 81 upload) for some users. The account management operations as a whole 82 are optional to implement for both credential servers and clients. 84 Note that there are potentially two "passwords" involved when using 85 this protocol - the first used to authenticate the user to the 86 credential server, and the second to decrypt (parts of) the 87 credential following a download operation. Where the context 88 requires it, we refer to the former as the account password and the 89 latter as the credential password. 91 Using a protocol such as this is somewhat less secure than using a 92 smart card, but can be used until smart cards and smart card readers 93 on workstations become ubiquitous, and can be useful even after 94 smart cards are ubiquitous, as a backup strategy when a user's smart 95 card is lost or malfunctioning. 97 The protocol sets out to meet the requirements in [REQS]. 98 Cryptographic credentials may take the form of private keys, PKCS 99 #15 [PKCS15] or structures. As stated, a profile based on BEEP 100 [BEEP] is specified for message transport and security (integrity, 101 authentication and confidentiality). In particular, in that case, 102 the security requirements are met by mandating support (via BEEP) 103 for TLS [TLS] and/or DIGEST-MD5 [DIGEST-MD5]. 105 We assume the only authentication information available to the user 106 is a username and password. 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 110 this document are to be interpreted as described in [RFC2119]. 112 2. The protocol 114 This section defines the account management and "run-time" 115 operations for the SACRED protocol. 117 It also describes the message formats used, which are described in 118 XML [XMLSCHEMA]. Appendix A provides an XML schema for these 119 elements. 121 The approach taken here is to define SACRED elements that are 122 compatible with the elements used in [XKMS] and [XMLDSIG], so that 123 an implementation of this protocol can easily also support XKMS, and 124 vice versa. 126 It is also intended that other SACRED protocol instances (e.g. using 127 a different authentication scheme, credential format or transport 128 protocol) could re-use many of the definitions here. 130 2.1 Account management operations 132 These operations MAY be implemented, that is, they are OPTIONAL. 134 2.1.1 Information Request 136 This operation does NOT REQUIRE authentication. 138 The purpose of this operation is to provide to the client the values 139 required for account creation. 141 The client sends an InfoRequest message (which has no content). 143 The server responds with an InfoResponse message which contains the 144 authentication mechanism parameters for the server and the list of 145 supported ProcessInfo types. For DIGEST-MD5 this consists of the 146 list of realms (each as an XML element named "Realm") which the 147 server supports. There MUST be at least one realm specified. Clients 148 MUST be able to select one from a list of Realms and MUST be able to 149 disregard any other information present (allowed for extensibility). 151 2.1.2 Create Account 153 This operation REQUIRES server authentication. 155 The purpose of this operation is to setup a new account on the 156 server. The information required for a "new" account will depend on 157 the SASL [SASL] mechanism used. 159 The client sends a CreateAccountRequest, which contains the account 160 name (e.g. username). It also contains the elements required to 161 create an account for a particular authentication mechanism. The 162 actual information is defined according to the authentication 163 mechanism. For DIGEST-MD5 this consists of the password verifier 164 (the hashed username, password and realm) and the chosen realm. 165 Although more than one set of such data is allowed by the data 166 structures defined in the appendix, clients SHOULD only include one 167 here. 169 The server responds with an error or acknowledgement message. 171 2.1.3 Remove Account 173 This operation REQUIRES mutual authentication. 175 The purpose of this operation is to delete the entire account. 177 The client sends a RemoveAccountRequest message (which has no 178 content) to the server. 180 The server MUST delete all information relating to the account and 181 respond with an error or acknowledgement message. 183 2.1.4 Modify Account 185 This operation REQUIRES mutual authentication. 187 The purpose of this operation is to allow the client to change the 188 information required for authentication. The information required 189 will depend on the authentication method used. 191 The client sends a ModifyAccountRequest message which contains the 192 elements required to change the authentication information for the 193 account, for a particular authentication mechanism. The actual 194 information is defined according to the authentication mechanism. 195 For [DIGEST-MD5] it will consist of a realm and password verifier 196 value. 198 Once the account information has been changed, the server will 199 respond with an error or acknowledgement message. 201 2.2 "Run-time" operations 203 These operations MUST be supported by all conformant 204 implementations. 206 2.2.1 Credential Upload 208 This operation REQUIRES mutual authentication. 210 The purpose of this operation is to allow the client to deposit a 211 credential with the server. 213 The client sends an UploadRequest message to the server which MUST 214 contain one Credential. 216 If a credential with the same credential selector field as in the 217 UploadRequest, (a "matching" credential), already exists for the 218 account, then that credential is replaced with the new credential 219 from the UploadRequest. Otherwise a "new" credential is associated 220 with that account. If a new credential is being uploaded then the 221 client SHOULD include (in LastModified) its local concept of the 222 time (if it has one) or else an indicator that it has no clock. The 223 actual value of LastModified can be anything, (but the element has 224 to be present) since this will be overwritten by the server in any 225 case. 227 If any change is made to the stored credentials associated with the 228 account then the server MUST update the corresponding LastModified 229 value (returned in DownloadResponse messages) to the current time 230 (at the server). 232 The LastModified value in the UploadRequest MUST be the value which 233 was most recently received in a corresponding DownloadResponse for 234 that credential. This means the clients are strongly RECOMMENDED to 235 only produce an UploadRequest based on recently downloaded 236 credentials, since otherwise the LastModified value may be out of 237 date. 239 The LastModified value can also be of use in detecting conflicts. 240 For example, download to platform A, download to platform B, update 241 from B, update from A. The server could detect a conflict on the 242 second upload. In this case the server MUST respond with a BEEP 243 error (which SHOULD be StaleCredential). 245 The server replaces the provided LastModified value with the current 246 time at the server before storing the credential. (Note that this 247 means that it would be unwise for a client to include the 248 LastModified field in a ClientInfo digital signature which is 249 calculated over the CredentialType.) 251 The server responds with an error or acknowledgement message. 253 2.2.2 Credential Download 255 This operation REQUIRES mutual authentication. 257 The purpose of this operation is to allow a client to get one or 258 more credentials from a server (the purpose of the entire protocol 259 really!). 261 The client sends a DownloadRequest message to the server which MAY 262 contain a credential selector string for the credential. No, or an 263 enmpty, credential selector means the request is for all credentials 264 associated with the account. 266 The server responds with a DownloadResponse or an error message. A 267 DownloadResponse contains one or more credential payloads including 268 the LastModified time which represents the time (at the server) when 269 the last change was made to each credential associated with the 270 account (e.g. subsequent to an UploadRequest). 272 2.2.3 Credential Delete 274 This operation REQUIRES mutual authentication. 276 The purpose of this operation is to allow the client to delete one 277 or all credentials associated with the account. 279 The client sends an DeleteRequest message to the server which can 280 contain either a CredentialSelector or an All element. 282 If the DeleteRequest contains an All element then all of the 283 credentials associated with that account are deleted. 285 If the DeleteRequest contains a CredentialSelector then the request 286 MAY include a LastModified value. If the LastModified value is 287 present in the DeleteRequest then it MUST be the value which was 288 most recently received in a corresponding DownloadResponse for that 289 credential. If the value does not match then the server MUST NOT 290 delete the credentials. 292 If no "matching" credential exists, the server returns an error. 294 The server responds to this request with an error or acknowledgement 295 message. 297 2.3 Miscellaneous 299 2.3.1 Session security 301 Six SACRED operations are defined above. In this section we specify 302 the requirements for security for each of the operations (where 303 supported). 305 Operation Security REQUIRED 306 --------- ----------------- 307 Information request NONE 308 Create account Server authentication, 309 Confidentiality, Integrity 310 Remove account Mutual authentication, 311 Confidentiality, Integrity 312 Modify account Mutual authentication, 313 Confidentiality, Integrity 314 Credential upload Mutual authentication, 315 Confidentiality, Integrity 316 Credential download Mutual authentication, 317 Confidentiality, Integrity 318 Credential delete Mutual authentication, 319 Confidentiality, Integrity 321 The security requirements can be met by several mechanisms. This 322 document REQUIRES credential servers to support TLS and DIGEST-MD5. 323 Clients MUST support DIGEST-MD5 and TLS with server authentication. 325 The mandatory-to-implement TLS cipher suite for SACRED is 326 TLS_RSA_WITH_3DES-EDE_CBC_SHA. Implementations SHOULD also support 327 TLS_RSA_WITH_AES_128_CBC_SHA [TLSAES]. 329 When performing mutual authentication using DIGEST-MD5 for the 330 client, DIGEST-MD5 MUST only be used "within" a TLS server- 331 authenticated "pipe", and MUST only be used only for client 332 authentication. That is, we do not use the DIGEST-MD5 security 333 services (confidentiality, integrity etc.). 335 2.3.2 Handling multiple credentials for an account 337 When more than one credential is stored under a single account, the 338 client can select a single credential using the optional credential 339 selector string. 341 There is no concept of a "default credential" - all credentials MUST 342 have an associated selector unique for that account. The selector 343 is REQUIRED for upload requests and OPTIONAL for download requests. 344 If the selector is omitted in a download request it MUST be 345 interpreted as a request for all the stored credentials. 347 An empty selector string value (i.e. "") in a credential download 348 request, is to be interpreted as if the selector string were 349 omitted, i.e. a download request containing this is a request for 350 all credentials. 352 It is an error to have more than one credential stored under the 353 same account where both have the same credential selector string. 355 2.3.3 Common fields 357 All messages sent to the server MAY contain ProcessInfo values. This 358 field MAY be used by other specifications or for vendor extensions. 359 For example, a server might require clients to include a phone 360 number in this field. The information response message contains a 361 list of the types of ProcessInfo that the server supports. This 362 extensibility scheme is similar to that used in [XKMS] and [XBULK]. 364 Where no specific response message is defined for an operation (e.g. 365 for UploadRequest) then the transport will indicate success or 366 failure. 368 All of the response messages defined here MAY contain a Status 369 string, containing a value intended for human consumption. 371 2.3.4 Credential Format 373 A number of messages involve the Credential element. It has the 374 following fields (all optional fields may occur exactly zero or one 375 times unless otherwise stated): 377 - CredentialSelector contains a string by which this particular 378 credential (for this account) can be identified. 379 - PayLoad contains either a ds:KeyInfo or some other form of 380 credential. Implementations MUST support the PKCS #15 form of 381 ds:KeyInfo defined below (the SacredPKCS15 element). 382 - LastModified is a string containing the time (at the server) at 383 which this credential was last modified. 384 - TimeToLive (optional) is a hint which clients SHOULD honor, which 385 specifies the number of seconds for which the downloaded 386 credential is to be usable. 387 - ProcessInfo (optional) MAY contain any (typed) information that 388 the server is intended to process. If the server doesn't support 389 any of the ProcessInfo data, it MAY ignore that data. 390 - ClientInfo (optional) MAY contain any (typed) information that the 391 client is intended to process, but which the server MUST ignore. 392 If the client doesn't support any of the ClientInfo data, it MAY 393 ignore that data (e.g. if the ClientInfo is device specific). 395 3. BEEP Profile for SACRED 397 The protocol described in this memo is realized as a [BEEP] profile. 399 Future memos may define alternative versions of the BEEP profile for 400 SACRED. When a BEEP peer sends its greeting, it indicates which 401 profiles it is willing to support. Accordingly, when the BEEP client 402 asks to start a channel, it indicates the versions it supports, and 403 if any of these are acceptable to the BEEP server, the latter 404 specifies which profile it is starting. 406 Profile Identification: http://iana.org/beep/transient/sacred/bss 408 This profile URI is consistent with [TRANS]. 410 Messages Exchanged during Channel Creation: 411 InfoRequest, 412 CreateAccountRequest, 413 RemoveAccountRequest, 414 ModifyAccountRequest, 415 DownloadRequest, 416 UploadRequest, 417 DeleteRequest, 418 InfoResponse, 419 DownloadResponse, 420 error, 421 ok 423 Messages starting one-to-one exchanges: 424 InfoRequest, 425 CreateAccountRequest, 426 RemoveAccountRequest, 427 ModifyAccountRequest, 428 DownloadRequest, 429 UploadRequest, 430 DeleteRequest 432 Messages in positive replies: 433 ok, 434 InfoResponse, 435 DownloadResponse 437 Messages in negative replies: error 439 Messages in one-to-many changes: none 441 Message Syntax: c.f.,Section 3 443 Message Semantics: c.f., Section 2 445 Contact Information: c.f., the editor's address section of this memo 446 3.1 Profile Initialization 448 Because all but one of the operations of the SACRED profile have 449 security requirements (cf., Section 2.3.1), before starting the 450 SACRED profile, the BEEP session will likely be tuned using either 452 http://iana.org/beep/TLS 454 or 456 http://iana.org/beep/TLS followed by 457 http://iana.org/SASL/DIGEST-MD5 459 Appendix B gives an example of tuning a BEEP session using DIGEST- 460 MD5 (i.e. it shows how to turn on BEEP security). 462 Regardless, upon completion of the negotiation process, a tuning 463 reset occurs in which both BEEP peers issue a new greeting. Consult 464 Section 3 of [BEEP] for an example of how a BEEP peer may choose to 465 issue different greetings based on whether confidentiality is in 466 use. 468 Any of the messages listed in section 3.2 below may be exchanged 469 during channel initialization (c.f., Section 2.3.1.2 of [BEEP]), 470 e.g., 472 C: 473 C: 474 C: ]]> 475 C: 476 C: 478 S: 479 S: ]]> 480 S: 482 Note that BEEP imposes both encoding and length limitations on the 483 messages that are piggybacked during channel initialization. 485 3.2 Profile Exchange 487 All messages are exchanged as "application/beep+xml" (c.f., Section 488 6.4 of [BEEP]): 490 Role MSG RPY ERR 491 ---- --- --- --- 492 I InfoRequest InfoResponse error 493 I CreateAccountRequest ok error 494 I RemoveAccountRequest ok error 495 I ModifyAccountRequest ok error 496 I DownloadRequest DownloadResponse error 497 I UploadRequest ok error 498 I DeleteRequest Ok error 499 3.3 Error handling 501 The "error" message from Section 2.3.1.5 of [BEEP] is used to convey 502 error information. Typically, after flagging an error, a peer will 503 initiate a graceful release of the BEEP session. 505 The following BEEP error reply codes from [BEEP] are to be used: 507 code Meaning 508 ==== ======= 509 421 service not available 510 450 requested action not taken (e.g., lock already in 511 use) 512 451 requested action aborted (e.g., local error in 513 processing) 514 454 temporary authentication failure 515 500 general syntax error (e.g., poorly-formed XML) 516 501 syntax error in parameters (e.g., non-valid XML) 517 504 parameter not implemented 518 530 authentication required 519 534 authentication mechanism insufficient (e.g., too 520 weak, sequence exhausted, etc.) 521 535 authentication failure 522 537 action not authorized for user 523 538 authentication mechanism requires encryption 524 550 requested action not taken (e.g., no requested 525 profiles are acceptable) 526 553 parameter invalid 527 554 transaction failed (e.g., policy violation) 529 The following SACRED-specific error reply codes can also be used: 531 code Meaning 532 ==== ======= 533 555 Extension (ProcessInfo) used not supported 534 556 Required extension (ProcessInfo) not present 535 557 StaleCredential (A bad LastModified value was 536 contained in an UploadRequest.) 538 3.4 SASL authorization identity 540 The use of the SASL authorization identity in this protocol is 541 implementation-specific. If used, the authorization identity is not 542 a substitute for the credential selector field, but may be used to 543 affect authorization for access to credentials. 545 4. IANA Considerations 547 If the IANA approves this memo for standards-track publication, then 548 the IANA registers the BEEP profile specified in Section 4, and 549 selects an appropriate standards-track URI, e.g., 551 http://iana.org/beep/sacred/bss 553 The sacred protocol SHOULD be run over port <>. 555 The GSSAPI service name (required when using SASL) for this protocol 556 SHALL be "sacred". 558 5. Security Considerations 560 [REQS] calls for specifications to state how they address the 561 vulnerabilities listed below. 563 V1. A passive attacker can watch all packets on the network and 564 later carry out a dictionary attack. 565 - The use of DIGEST-MD5 and/or TLS counters this 566 vulnerability. 567 V2. An attacker can attempt to masquerade as a credential server 568 in an attempt to get a client to reveal information on line 569 that allows for a later dictionary attack. 570 - The use of server or mutual authentication counters this 571 vulnerability. 572 V3. An attacker can attempt to get a client to decrypt a chosen 573 "ciphertext" and get the client to make use of the resulting 574 plaintext - the attacker may then be able to carry out a 575 dictionary attack (e.g. if the plaintext resulting from 576 "decryption" of a random string is used as a DSA private 577 key). 578 - The use of server or mutual authentication counters this 579 vulnerability. 580 V4. An attacker could overwrite a repository entry so that when 581 a user subsequently uses what they think is a good 582 credential, they expose information about their password 583 (and hence the "real" credential). 584 - Server implementations SHOULD take measures to protect the 585 database. Clients MAY use the ClientInfo field to store e.g. 586 a signature over the Credential, which they then verify 587 before using the private component. 588 V5. An attacker can copy a credential server's repository and 589 carry out a dictionary attack. 590 - Server implementations SHOULD take measures to protect the 591 database. 592 V6. An attacker can attempt to masquerade as a client in an 593 attempt to get a server to reveal information that allows 594 for a later dictionary attack. 595 - The mutual authentication requirements of this protocol 596 counter this to a great extent. Additionally, credential 597 servers MAY choose to provide mechanisms that protect 598 against online dictionary attacks against user account 599 passwords, either by repeated access attempts to a single 600 user account (varying the password) or by attempting to 601 access many user accounts using the same password. 602 V7. An attacker can persuade a server that a successful login 603 has occurred, even if it hasn't. 604 - Client authentication prevents this. 605 V8. (Upload) An attacker can overwrite someone else's 606 credentials on the server. 607 - Only if they know the account password already (thanks to 608 mutual authentication). 609 V9. (When using password-based authentication) An attacker can 610 force a password change to a known (or "weak") password. 611 - Client authentication counters this. 612 V10. An attacker can attempt a man-in-the-middle attack for lots 613 of reasons... 614 - Mutual authentication plus the encryption of subsequent 615 messages prevents this. 616 V11. User enters password instead of name. 617 - Since the DIGEST-MD5 mechanism is only used after TLS 618 tuning, the user's name is also protected. 619 V12. An attacker could attempt various denial-of-service attacks. 620 - No specific countermeasures against DoS are proposed. 622 If the CreateAccountRequest message were sent over a cleartext 623 channel (or otherwise exposed) then an attacker could mount a 624 dictionary attack and recover the account password. This is why the 625 server authenticated TLS transport is REQUIRED for this operation. 627 If someone steals the server database they can launch a dictionary 628 attack. If the dictionary attack is successful, the attacker can 629 decrypt the user's credentials. An attacker that has learned the 630 user's account password can also upload new credentials, assuming 631 the user is authorized to modify the credentials, because someone 632 who knows the user's account password is assumed to be the user. 633 However, if someone steals the server database and is unsuccessful 634 at obtaining the user's account password through a dictionary 635 attack, they will be unable to upload new credentials. 637 Credential servers SHOULD incorporate measures that act to counter 638 denial of service attacks. In particular, they SHOULD drop inactive 639 connections and minimize the use of resources by un-authenticated 640 connections. A number of recommendations are listed at [DDOS]. 642 Various operations in the SACRED protocol depend upon server 643 authentication being provided by server authenticated TLS. SACRED 644 clients SHOULD take care that the correct server is at the far end 645 of the TLS "pipe" by performing the checks which are listed in 646 section 3.1 of RFC2818 [RFC2818]. Clients SHOULD also include the 647 optional BEEP serverName field in their "start" message and SHOULD 648 then ensure that the BEEP serverName is consistent with the checks 649 on the TLS server described in RFC2818. Failure to carry out these 650 checks could allow a spoof server access a user's credential. 652 If the SACRED account password were to be used in some other, less 653 secure protocol using DIGEST-MD5, then it might appear to be the 654 case that a man-in-the-middle (MITM) attack could be mounted. 655 However, this is not the case since the DIGEST-MD5 client hash 656 includes a client-selected "digest-uri-value" which in SACRED's case 657 will be "sacred/". In a MITM attack, those values will 658 be something else. A MITM attack as described is therefore thwarted 659 because digest-uri-value wouldn't match what the SACRED server is 660 expecting. 662 References 664 Normative: 666 [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol 667 Core", RFC 3080. 668 [DIGEST-MD5] "Using Digest Authentication as a SASL 669 Mechanism", Leach, P., Newman, C., RFC 2831. 670 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information 671 Syntax Standard," RSA Laboratories, June 2000. 672 [REQS] Arsenault, A., Farrell, S., "Securely Available 673 Credentials - Requirements", RFC 3157. 674 [RFC2026] Bradner, S., "The Internet Standards Process -- 675 Revision 3", RFC 2026. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", RFC 2119. 678 [SASL] Myers, J., "Simple Authentication and Security Layer 679 (SASL)", RFC 2222. 680 [TLS] Dierks, T., "The TLS Protocol - Version 1.0", RFC 681 2246. 682 [TLSAES] Chown, P., "Advanced Encryption Standard (AES) 683 Ciphersuites for Transport Layer Security (TLS)", 684 RFC 3268. 685 [XMLDSIG] Eastlake, D., et al. "XML-Signature Syntax and 686 Processing", RFC 3075. 687 [XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M. 688 Maloney, N. Mendelsohn, and H. Thompson. W3C 689 Recommendation, May 2001. Available at 690 http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ 691 Informative: 693 <> 696 [DDOS] "Recommendations for the Protection against 697 Distributed Denial-of-Service Attacks in the 698 Internet", 699 http://www.iwar.org.uk/comsec/resources/dos/ddos_en. 700 htm 701 [RFC2818] Rescorla, E., "HTTP over TLS", RFC 2818. 703 [RFC3...] Gustafson, D., Just, M., M. Nystrom, "Securely 704 Available Credentials - Credential Server 705 Framework," RFC 3..., . 706 [TRANS] Rose, M., "A Transient Prefix for Identifying 707 Profiles under Development by the Working Groups of 708 the IETF", RFC 3349. 709 [XKMS] Hallam-Baker, P. (ed), "XML Key Management 710 Specification", http://www.w3.org/TR/xkms2/ 711 [XBULK] Hughes, M (ed), "XML Key Management Specification - 712 Bulk Operation", http://www.w3.org/TR/xkms2-xbulk/ 714 Acknowledgements 716 Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman 717 (ckaufman@iris.com) co-authored earlier versions of this document. 718 Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work 719 adapting an earlier draft to the use of SRP (though SRP was 720 subsequently dropped, much of the framework survives). Marshall Rose 721 (mrose@dbc.mtview.ca.us) helped out a lot, in particular, with the 722 BEEP profile. And the following people were actively involved in the 723 mailing list discussions leading to this draft: 725 David Chizmadia (vze2729k@verizon.net), 726 Dave Crocker (dcrocker@brandenburg.com), 727 Lawrence Greenfield (leg+@andrew.cmu.edu), 728 Dale Gustafson (dale.gustafson@bpsi.net), 729 Mike Just (Mike.Just@entrust.com), 730 John Linn (jlinn@rsasecurity.com), 731 Neal McBurnett (neal@bcn.boulder.co.us), 732 Keith Moore (moore@cs.utk.edu), 733 Bob Morgan (rlmorgan@washington.edu), 734 Magnus Nystrom (magnus@rsasecurity.com), 735 Eamon O'Tuathail (eamon.otuathail@clipcode.com), 736 Gareth Richards (grichards@rsasecurity.com) 738 Of course, any and all errors remain the editor's responsibility. 740 Editor's Address 742 Stephen Farrell, 743 Distributed Systems Group, 744 Computer Science Department, 745 Trinity College Dublin, 746 IRELAND 747 Phone: +353-1-608-3070 748 Email: stephen.farrell@cs.tcd.ie 750 Full Copyright Statement 752 Copyright (C) The Internet Society (date). All Rights Reserved. 754 This document and translations of it may be copied and furnished to 755 others, and derivative works that comment on or otherwise explain it 756 or assist in its implementation may be prepared, copied, published 757 and distributed, in whole or in part, without restriction of any 758 kind, provided that the above copyright notice and this paragraph 759 are included on all such copies and derivative works. In addition, 760 the ASN.1 module presented in Appendix B may be used in whole or in 761 part without inclusion of the copyright notice. However, this 762 document itself may not be modified in any way, such as by removing 763 the copyright notice or references to the Internet Society or other 764 Internet organizations, except as needed for the purpose of 765 developing Internet standards in which case the procedures for 766 copyrights defined in the Internet Standards process shall be 767 followed, or as required to translate it into languages other than 768 English. 770 The limited permissions granted above are perpetual and will not be 771 revoked by the Internet Society or its successors or assigns. This 772 document and the information contained herein is provided on an "AS 773 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 774 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 775 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 776 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 777 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 779 Appendix A: XML Schema 781 782 787 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 880 881 882 883 884 885 886 887 888 889 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 932 933 Appendix B: An Example of Tuning with BEEP 935 Here is what tuning BEEP for authentication and confidentiality 936 looks like 937 using TLS and SASL's DIGEST-MD5: 939 L: 940 I: 942 ... each peer sends a greeting indicating the services that 943 it offers ... 945 L: RPY 0 0 . 0 233 946 L: Content-Type: application/beep+xml 947 L: 948 L: 949 L: 950 L: 951 L: 952 L: 953 L: END 954 I: RPY 0 0 . 0 52 955 I: Content-Type: application/beep+xml 956 I: 957 I: 958 I: END 960 ... the initiator starts a channel for TLS and piggybacks a request 961 to start the TLS negotiation ... 963 I: MSG 0 1 . 52 149 964 I: Content-Type: application/beep+xml 965 I: 966 I: 967 I: 968 I: <ready /> 969 I: 970 I: 971 I: END 973 ... the listener creates the channel and piggybacks its readiness to 974 start TLS ... 976 L: RPY 0 1 . 233 112 977 L: Content-Type: application/beep+xml 978 L: 979 L: 980 L: <proceed /> 981 L: 982 L: END 984 ... upon receiving the reply, the initiator starts up TLS ... 986 ... successful transport security negotiation ... 988 ... a new greeting is sent (cf., Section 9 of RFC 3080), note that 989 the listener no longer advertises TLS (we're already running 990 it) 992 L: RPY 0 0 . 0 186 993 L: Content-Type: application/beep+xml 994 L: 995 L: 996 L: 997 L: 998 L: 999 L: END 1000 I: RPY 0 0 . 0 52 1001 I: Content-Type: application/beep+xml 1002 I: 1003 I: 1004 I: END 1006 ... the initiator starts a channel for DIGEST-MD5 and piggybacks 1007 initialization information for the mecdhanism ... 1009 I: MSG 0 1 . 52 178 1010 I: Content-Type: application/beep+xml 1011 I: 1012 I: 1013 I: 1014 I: <blob> ... </blob> 1015 I: 1016 I: 1017 I: END 1019 ... the listener creates the channel and piggybacks a challenge ... 1021 L: RPY 0 1 . 186 137 1022 L: Content-Type: application/beep+xml 1023 L: 1024 L: 1025 L: <blob> ... </blob> 1026 L: 1027 L: END 1029 ... the initiator sends a response to the challenge ... 1031 I: MSG 1 0 . 0 58 1032 I: Content-Type: application/beep+xml 1033 I: 1034 I: ... 1035 I: END 1037 ... the listener accepts the challenge and tells the initiator 1038 that it is now authenticated ... 1040 L: RPY 1 0 . 0 66 1041 L: Content-Type: application/beep+xml 1042 L: 1043 L: 1044 L: END 1046 ... the initiator starts a channel for SACRED and piggybacks its 1047 initial SACRED request ... 1049 I: MSG 0 2 . 230 520 1050 I: Content-Type: application/beep+xml 1051 I: 1052 I: 1053 I: 1054 I: <?xml version="1.0" encoding="UTF-8"?> 1055 I: <sacred:DownloadRequest 1056 I: xmlns:sacred="urn:sacred-2002-11-20" 1057 I: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 1058 I: xsi:schemaLocation="urn:sacred-2002-11-20 sacred.xsd"> 1059 I: <CredentialSelector> 1060 I: magnus-credentials</CredentialSelector> 1061 I: </sacred:DownloadRequest> 1062 I: 1063 I: END 1065 ... the listener creates the channel and piggybacks the response to 1066 the 1067 initial SACRED request 1069 L: RPY 0 2 . 323 805 1070 L: Content-Type: application/beep+xml 1071 L: 1072 L: 1073 L: <?xml version="1.0" encoding="UTF-8"?> 1074 L: <sacred:DownloadResponse 1075 L: xmlns:sacred="urn:sacred-2002-11-20" 1076 L: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 1077 L: xsi:schemaLocation="urn:sacred-2002-11-20 sacred.xsd"> 1078 L: <Status>Success</Status> 1079 L: <Credential> 1080 L: <CredentialSelector> 1081 L: magnus-credential</CredentialSelector> 1082 L: <LastModified>2002-11-22T00:00:08Z</LastModified> 1083 L: <Payload> 1084 L: <sacred:SacredPKCS15 1085 L: xmlns:sacred="urn:sacred-2002-11-20">GpM7 1086 L: </sacred:SacredPKCS15> 1087 L: </Payload> 1088 L: </Credential> 1089 L: </sacred:DownloadResponse> 1090 L: 1091 L: END 1093 Appendix C: Provision SACRED using other Protocols 1095 SACRED may be implemented in a non-BEEP environment, providing that 1096 before any SACRED PDUs are sent, the application protocol must be 1097 protected according to the security mandates provided in Section 1098 2.3. 1100 For example, if SACRED is provisioned as the payload of an 1101 application protocol that supports SASL and TLS, then the 1102 appropriate SASL and/or TLS negotiation must successfully occur 1103 before exchanging Sacred PDUs. 1105 Alternatively, if the application protocol doesn't support SASL, 1106 then one or more PDUs are defined to facilitate a SASL negotiation, 1107 and the appropriate negotiation must occur before exchanging Sacred 1108 PDUs. 1110 Appendix D: Changes & Open Issues 1112 <> 1117 -09: More IESG nits/minor rewordings: 1118 - s/privacy/confidentiality/g 1119 - additional intro para and (informative) reference to fwrk rfc 1120 -08 (Couple of pre-IESG nits and AD issues): 1121 - Re-worded abstract (and consequently a bit of the intro too) 1122 as per AD advice 1123 - Removed contradictory sentence from 2.2.1 ("If no "matching" 1124 credential exists, the server returns an error.") 1125 - Added TLS_RSA_WITH_AES_128_CBC_SHA as a SHOULD and associated 1126 reference to RFC 3268, again as per AD advice. 1127 - Added a clarification about what's in LastModified for an 1128 initial upload (at end of fourth paragraph of 2.2.1) 1129 - Editor affiliation change 1131 -07 (WG Last-Call Issues): 1132 - Added explicit credential delete message 1133 -06: 1134 - Updated appendix B with Marshall's latest text (but including 1135 the serverName attribute in the initiator's first start 1136 message, as in -05) 1137 - Otherwise no change 1138 -05: 1139 - Credential payload element -> minOccurs="0" 1140 - Added security considerations for the compound authentication 1141 "issue" 1142 - Gratefully added rlbob SASL authorization id text 1143 - Extended Appendix B with Magnus' samples 1144 - Applied changes in "More editorials" mail 1145 - Clarified that we're using BEEP for security and what 1146 "tuning" means 1147 - Replaced schema with equivalent that "compiles" 1148 -04: 1149 - Replaced SASL-MD5 with DIGEST-MD5 everywhere 1150 - Updated appendix B and other BEEP issues according to 1151 Marshall Rose's Oct 6th recommendations 1152 - Applied all but three "editorial corrections" raised on list, 1153 see 1154 - Added a recommendation to download prior to modify 1155 - Fixed AuthXXXType extensibility as suggested by Gareth 1156 Richards 1157 -03: 1158 - Should the DTD or schema be normative? I'd usually go for the 1159 schema, but in this case the DTD seems much simpler. 1160 - Deleted DTD 1161 - Should we apply for a port number? (probably) 1162 - Mailed IANA and added IANA considerations section. 1164 - Multiple substrates issue 1165 - Decided at Minneapolis (Spring 2002) not to change. 1166 - Should we specify a max value where "unbounded" is in the 1167 schema or "+"/"*" in the DTD? 1168 - Nope. 1169 - Remove SASL-SRP and replace with something else 1170 - Done - changed to DIGEST-MD5 (rfc 2831). 1171 - SASL authorization identity issue 1172 - Waited some time for text that didn't arrive and so leaving 1173 current text as is. 1174 - Changed away from having a request with an empty sequence 1175 representing an implicit delete to where an explicit deletion 1176 request indicator (an XML attribute) is required 1177 - Added a service name: "The GSSAPI service name (required when 1178 using SASL) for this protocol SHALL be "SACRED"." (Note: I 1179 don't understand this and don't want to, but do let me know 1180 if its wrong:-) 1181 -02: 1182 - Changes as per mailing list discussion: 1183 - deleted (previous) section 2.4: session mgt & added sec. 1184 cons about DoS 1185 - Applied changes from the following threads: 1186 - "BEEP adjustments" 1187 - "MultipleCredentials" 1188 - "SRP adjustments" 1189 - "LastModified" 1190 - Other changes: 1191 - clarified how UploadRequest can delete one or more 1192 credential payloads 1193 - merged sections 2 and 3 since its much clearer that way 1194 - changed Credential structure about a bit due to moving 1195 LastModified 1196 -01: Changes as per mailing list discussion: 1197 - Change from authors to editor + acks 1198 - Included resolved comments from list: 1199 - password -> account pwd or cred pwd as appropriate 1200 - account mgt separated and optional 1201 - added example beep tuning 1202 - selector: no default, omit in d/l means all 1203 - changed LastModified scheme as per list comments 1204 - Excluded administrative operations (was an open issue) 1205 - Demoted hashed(username) concept to a note under security 1206 considerations (see V11). 1207 - Dropped idea of specifying a mapping between SRP id and cTLS 1208 certificate. 1209 - Dropped xkms & xbulk as normative references, but copied some 1210 stuff from them. 1211 -00: This version is adapted from draft-ietf-SACRED-protocol-beep- 1212 pdm-00.txt, the main changes are: 1213 - PDM -> SRP &/or TLS 1214 - Payload security -> SASL or TLS 1215 - Dropped username hashing 1216 - Dropped away-from-home