idnits 2.17.1 draft-ietf-sacred-protocol-beep-pdm-00.txt: -(850): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 17) being 62 lines 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. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 751 has weird spacing: '... code mea...' == Line 855 has weird spacing: '...esponse error...' == Line 857 has weird spacing: '...esponse erro...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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 (June 2001) is 8323 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: 'PDM' is mentioned on line 143, but not defined == Missing Reference: 'Encrypted' is mentioned on line 183, but not defined == Missing Reference: 'XLMDSIG' is mentioned on line 674, but not defined == Unused Reference: 'AES' is defined on line 879, but no explicit reference was found in the text == Unused Reference: 'PKCS15' is defined on line 882, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 889, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AES' -- Possible downref: Non-RFC (?) normative reference: ref. 'PKCS15' == Outdated reference: A later version (-03) exists of draft-ietf-sacred-reqs-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sacred-reqs (ref. 'REQS') -- Possible downref: Non-RFC (?) normative reference: ref. 'XKMS' ** Downref: Normative reference to an Experimental RFC: RFC 2075 (ref. 'XMLDSIG') Summary: 6 errors (**), 0 flaws (~~), 15 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Stephen Farrell 3 expires in six months Baltimore Technologies 4 Radia Perlman 5 Sun Microsystems 6 Charlie Kaufman 7 Iris Associates 8 Marshall Rose 9 Invisible Worlds, Inc. 10 June 2001 12 Securely Available Credentials - The PDM Protocol 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of [RFC2026]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. Internet-Drafts are draft documents valid for a maximum of 24 six months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 This document describes a PDM-based protocol for securely available 38 credentials. 40 Discussion of this draft is taking place on the SACRED mailing list 41 of the IETF SACRED working group (see http://www.imc.org/ietf-sacred 42 for subscription information). 44 Table Of Contents 46 Status of this Memo.............................................1 47 Abstract........................................................1 48 Table Of Contents...............................................2 49 1. Introduction.................................................2 50 2. The protocol.................................................3 51 3. Computation at the client machine............................9 52 4. Computation at the server machine............................9 53 5. XML Messages.................................................9 54 6. BEEP Profile for Sacred.....................................16 55 7. IANA Considerations.........................................17 56 8. Security Considerations.....................................17 57 References.....................................................18 58 Acknowledgements...............................................18 59 Authors' Addresses.............................................18 60 Full Copyright Statement.......................................19 61 Appendix A: Schema.............................................19 62 Appendix B: DTD................................................22 63 Appendix C: Open Issues........................................24 65 1. Introduction 67 We describe a protocol whereby a user can acquire cryptographic 68 credentials (e.g., private keys, PKCS#15 structures) from a 69 workstation with locally trusted software but with no user-specific 70 configuration. This is somewhat less secure than a smart card, but 71 can be used until smart cards and smart card readers on workstations 72 become ubiquitous, and can be useful even after smart cards are 73 ubiquitous, as a backup strategy when a user's smart card is lost or 74 malfunctioning. 76 The protocol sets out to meet the requirements in [REQS]. 78 This protocol assumes a reasonably powerful workstation (e.g., 400 79 MHz) since it is computationally expensive at the client end. 81 This protocol strives to maximize server performance and make the 82 server more robust against denial of service attacks by saving as 83 much computation as possible for the server. For credential 84 download, this protocol requires only a single exponentiation at the 85 server, and is secure with smaller moduli than other protocols 86 because the modulus itself is secret. Traditional Diffie-Hellman 87 with 500 -bit fixed modulus is estimated to take 8000 MIP-years to 88 break, so when Diffie-Hellman is used in the traditional way 89 (publicly known moduli), it is recommended that the moduli be 1000 90 bits. But in this scheme, it would require breaking 500-bit Diffie- 91 Hellman per user per password guess. It would be far less expensive 92 to do an on-line attack for each guessed password than to eavesdrop 93 on a successful authentication, guess passwords (and therefore 94 moduli) and break Diffie-Hellman for each password guess. By using 95 smaller moduli we save the server additional computation, somewhere 96 between a factor of 2 and 8 over computation using 1000 bit moduli. 98 We assume the only authentication information available to the user 99 is a password. 101 Many user-chosen passwords are vulnerable to dictionary attacks. So 102 this protocol is designed to give no information with which an 103 attacker can acquire information for launching a dictionary attack, 104 whether by eavesdropping or by impersonating either the client or 105 server. 107 The protocol also allows a user to change her password and/or 108 credentials and upload the new values to the server. The protocol 109 ensures that only someone that knew the old password is able to 110 modify the credentials. The protocol does not preclude configuring a 111 server to disallow credential upload from some users. 113 We also specify a protocol in which a systems administrator can 114 authenticate, and if authorized, create new user entries with 115 downloadable credentials, and/or modify existing user entries. 117 If someone steals the server database they can launch a dictionary 118 attack. If the dictionary attack is successful, the attacker can 119 decrypt the user's credentials. An attacker that has learned the 120 user's password can also upload new credentials, assuming the user 121 is authorized to modify the credentials, because someone who knows 122 the user's password is assumed to be the user. However, if someone 123 steals the server database and is unsuccessful at obtaining the 124 user's password through a dictionary attack, they will be unable to 125 upload new credentials. 127 A common error is for a user to type her password instead of her 128 name. If the name is sent over the wire in the clear, this leads to 129 the possibility of the user's password being over the wire in the 130 clear when the user has mistakenly typed her password instead of her 131 name. To guard against this we send the hash of the user's name 132 rather than the user's name. This means that the protocol should 133 canonicalize the user's name (for instance, convert all letters to 134 lowercase), since the server will not be able to recognize an 135 approximation of the name. 137 2. The protocol 139 We assume the credentials server has a name, such as "Bob". The 140 purpose of the server name is to generate a quantity X that will be 141 different for each server that a user might interact with, even if 142 the user has the same password on these servers. For more 143 description of the cryptographic basis of this protocol see [PDM]. 145 The credentials server stores for each user/account: 147 - username (e.g. "Alice") 148 This can optionally contain a "realm" component, where the realm 149 is an FQDN (e.g. "Alice@baltimore.ie") 151 - p: (safe prime pseudorandomly generated from seed h("Alice", 152 password) 153 This prime is used as the modulus in a Diffie-Hellman exchange. 155 - pub: public RSA key (required for credential uploads only) 156 Alice might use other key pairs, or public keys that are not RSA 157 keys, for other applications. These can be included, along with 158 the private RSA key needed for the credential upload portion of 159 the PDM-sacred protocol, in the encrypted credential. All 160 credentials (including the private key for uploads) are downloaded 161 with the same credential bundle "Y" (next item). 163 - Y=Alice's credentials encrypted with her password 164 The credentials consists of (an optional user string, RSA public 165 and private key, optional payload, date last changed and TTL). 166 Some of these fields are encrypted with the user's password 167 (marked below). 168 - Date last changed is there to alert the user in case someone 169 unauthorized has somehow managed to replace the current 170 credential with an older version. 171 - The (optional) user string is used to allow users to store more 172 than one credential payload under the same password at the same 173 server. 174 - (Optionally) A time-to-live value specifying the number of 175 seconds for which the credential SHOULD be usable following 176 download. 177 - The RSA private key used for signing credential uploads, and 178 perhaps for other purposes. [Encrypted] 179 - "Payload" is the set of information being managed by this 180 protocol (e.g., a PKCS#15 structure). If the RSA private key 181 used for the credential upload is all the user needs for 182 credentials, then the "payload" can be zero length. Typically, 183 the payload will contain a PKCS#15 structure. [Encrypted] 185 - X=h("Alice", "Bob", Alice's password) 186 This quantity is used by the protocol to ensure that two servers 187 on which Alice uses the same password will not be able to 188 impersonate each other to Alice. 190 <> 193 There are two protocols described here. The first is for credentials 194 download; the second for credentials upload. Credentials download 195 consists of two messages, following which the BEEP session MAY be 196 closed. Credentials upload consists of the same first two messages 197 followed by two more messages to upload new credentials. If a 198 systems administrator is modifying many user accounts during the 199 same BEEP session, messages 3 and 4 are repeated for each user 200 account being modified. 202 2.1 Credentials Download 204 Alice and Bob establish a Diffie-Hellman key based on an exchange 205 using 2 as the base and p as the modulus, and private exponents A 206 (for Alice) and B (for Bob). Bob returns Alice's credential Y 207 encrypted with the high quality secret 2^AB mod p. We save Bob work 208 by having him always use the same B for Alice, and have 2^B mod p 209 pre-computed and stored. We can also have Bob choose a random number 210 R. R is ignored by Alice if all she is doing is downloading 211 credentials. If she is uploading credentials, though, she will sign 212 R using the RSA private key stored (encrypted) within Y, and the new 213 information that needs to be stored. Bob can verify the signature 214 using the RSA public key stored (in clear) within Y. 216 The purpose of the signature is to ensure that someone that steals 217 Bob's database cannot upload a credential without doing a successful 218 dictionary attack to obtain Alice's password and decrypt the stored 219 credential. The off-line dictionary attack is necessary in order to 220 retrieve the RSA private key required to sign the value R. 222 In the basic download protocol, the human Alice types her name and 223 password into her workstation, which computes p. The exchange then 224 consists of: 226 Message 1: Alice to Bob: h("Alice"), 2^A mod p 227 Message 2: Bob to Alice: "Bob", 2^B mod p, {Y}K 229 Where K=h(2^AB mod p, X) 231 Note our notation: 233 {data}K means "data" encrypted based on key K 234 [data]Alice means "data" signed with Alice's private key 236 2.2 Credentials upload 238 In this protocol the client machine obtains the old credentials, 239 decrypts them, and prepares new credentials based on the new 240 password, and uploads those. 242 There was no need to explicitly authenticate the server in the 243 credentials download case, because the credentials are self- 244 authenticating, and if correct, it doesn't matter who gave them to 245 the client. The credentials are self-authenticating due to the 246 inclusion of a digest with the encryption. 248 For download, there was also no need to explicitly authenticate the 249 client because nobody without knowledge of the password would be 250 able to make use of the credentials. And there was no need to worry 251 about someone who stole the server database impersonating the client 252 because if someone stole the server database they would already know 253 the credential, so there was no reason to prevent them from 254 downloading them. 256 Things are different for credentials upload. It is important for the 257 server to know that the new credential is being stored by someone 258 who knew the old password (so that a valid credential isn't 259 overwritten with garbage). The client wants to make sure it is 260 storing the credential at a valid server, and not giving the new 261 credential to an imposter, so the client must authenticate the 262 server. Even if the new credentials are encrypted with a strong 263 session key that only a server that knew the old credential could 264 derive, it is still important for the client to know that when it is 265 told that the new credential was stored, that it really was stored. 267 Another vulnerability that needs to be avoided in upload that did 268 not exist in download is that it is important to ensure that someone 269 that has read-only access to the server database cannot replace the 270 user's credential via the protocol, even if all they can replace it 271 with is garbage. 273 Messages 1 and 2 download the credential and establish a strong 274 secret K (=h(2^AB mod p, X)) between the client and server. This 275 time, Alice should include an "upload requested" flag in message 1, 276 and Bob should include R in message 2: 278 Message 1: Alice to Bob: h("Alice"), 2^A mod p, "upload" 279 Message 2: Bob to Alice: "Bob", 2^B mod p, R, {Y}K 281 Messages 3 and 4 accomplish mutual authentication and upload of the 282 new credential. This is done so that someone who stole the server 283 database but did not successfully derive the user's password through 284 a dictionary attack would not be able to impersonate the client and 285 overwrite the user's credential. 287 Message 3: {[username,sequence number, R, new Y, and optionally: new 288 p, X, B, pub, 2^B mod p]signed by Alice's private key}K 290 Note: username is present to allow a system administrator to keep a 291 connection open and upload new credentials for many users. The 292 private key with which the message is signed is the private key of 293 whoever initiated the session in messages 1 and 2, which we call 294 Alice. "username" might be the name of a user for whom Alice is 295 authorized to create or modify credentials. 297 "Sequence number" allows multiple uploads of the same user account, 298 so that one with a smaller sequence number within the same BEEP 299 session is ignored. 301 This prevents the (admittedly obscure) threat of someone replaying 302 previous message 3's within the same BEEP session. The encrypted 303 sequence number in message 4 serves as an acknowledgement. 305 Message 4: {sequence number}K 307 This serves as an acknowledgement to the client that this upload was 308 successful. 310 Credentials might change because the user changed her password, or 311 one of the items included in the credential (such as a private key) 312 might change even if the password does not change. Or she might 313 change both the password and the contents of the credential. In 314 either case Y will be new. But if the password has not changed, then 315 p and X would not change. So p and X are optional in message 3.. 317 The only reason to include new B and 2^B mod p in message 3 is to 318 save the server one exponentiation (to calculate the new 2^B mod p). 319 The server can accept the values from the client or calculate its 320 own. Optionally, when the server has spare cycles, it can gradually 321 choose new B's for each user and replace B and 2^B mod p for that 322 user. 324 Message 4 serves as an acknowledgement that the new credentials have 325 been received by a server that knew the old credentials (and so was 326 able to calculate K). 328 The server should not send the acknowledgement until the new 329 credentials have been written to stable storage. 331 2.3 Away-from-home operation 333 If the user includes the optional realm component in message 1 then 334 the user wants to play the sacred protocol with the server named in 335 the realm component of the user name (call this the target server). 337 In this case, if the server initially contacted is not the one named 338 in the realm part of the name, then the initial server MUST be able 339 to act as a proxy on the user's behalf. That is, the initial server 340 MUST be able to forward all packets between the user and the target 341 server and vice versa. 343 The initial and target servers MUST be able to, and SHOULD always, 344 use mutually authenticated TLS to secure and authenticate the BEEP 345 sessions between them. 347 An initial server MAY refuse to act as a proxy (for policy reasons). 348 A target server MAY refuse to accept requests via a proxy (for 349 policy reasons). Implementations SHOULD support controls allowing 350 enforcement of this policy. 352 In this mode the messages exchanged for download are: 354 Message 1: Alice to Bob: h("Alice@host.somewhere.com"), 355 "host.somewhere.com", 2^A mod p 357 ...Bob and host.somewhere.com establish a TLS-secured BEEP session 358 with mutual authentication... 359 Message 1': Bob to Target: bytes from message 1 360 Message 2': Target to Bob: "Target", 2^B mod p, {Y}K 361 Message 2: Bob to Alice: bytes from message 2' 363 The diagram below shows the interactions involved: 365 +--------+ +---------+ +---------+ 366 | User | | Proxy | | Home | 367 | | Message 1 | | | | 368 | +------------->| | Message1 | | 369 | | | +----------->| | 370 | | | | | | 371 | | | |<-----------+ | 372 | |<-------------+ | Message 2 | | 373 | | Message2 | | | | 374 +--------+ +---------+ +---------+ 376 Implementations MUST NOT support credentials upload in away-from- 377 home fashion. 379 <> 381 <> 385 2.4 Handling multiple payloads 387 When a user has more than one credential stored on a single server, 388 under a single username, then the user can nominate the credential 389 requested in the various messages above using the optional user 390 string stored by the server. 392 Servers SHOULD treat the first credential stored (time-wise) under 393 that username as the default for the account. 395 User strings MAY be included in the upload protocol. 397 It is an error to have more than one credential stored under the 398 same account where neither has a user string. That is, there can 399 only be one default. It is also an error to have more than one 400 credential stored under the same account where both have the same 401 user string. 403 Including the user strings the protocol looks like: 405 Message 1: Alice to Bob: h("Alice"), h("user string"), 2^A mod p 406 Message 2: Bob to Alice: "Bob", 2^B mod p, {Y}K 407 The upload protocol is not affected since the user string is an 408 optional part of Y in any case. The user string is hashed above for 409 the same reasons as the username. 411 3. Computation at the client machine 413 The user types her name and password. From this the client machine 414 calculates p, and finds an appropriate credential downloading server 415 either directly or via a SACRED proxy. 417 The client machine initiates a BEEP session, starts the BEEP profile 418 for PDM, chooses a random Diffie-Hellman exponent A, and sends 419 message 1. The server responds with message 2, which enables the 420 client machine to calculate X (because it is supplied with the 421 server name), 2^AB mod p, and therefore K. 423 It uses K to decrypt bytes from message 2, giving Y, and then uses 424 the user's password to decrypt (parts of) Y to obtain the user's 425 credentials. That is, the payload of Y is doubly encrypted when 426 transferred over the network. 428 If a user string was supplied, then the client MUST verify that Y 429 contains the same string. 431 If the client machine has a suitable human user interface, then it 432 SHOULD display the user string and the date last modified. 434 <> 436 4. Computation at the server machine 438 The server receives message1 and looks up an entry in its database 439 using the hashed username. 441 The server calculates K, using 2^A mod p from message1 and X and 2^B 442 mod p, from its database. 444 The server encrypts Y using K (assuming that Y is stored partly 445 encrypted under the user's password), and returns message2. 447 If message1 indicated that the client wishes to follow the download 448 with an upload, then the server generates a random string R for 449 inclusion in message2. The server MUST maintain state in order to be 450 able to verify that the same R is used in message3. 452 <> 454 5. XML Messages 456 This section describes the message formats used, which are based on 457 XML. Appendices A & B provide schema and DTD for the sacred 458 elements. 460 The approach taken here is to define sacred elements that are 461 compatible with the elements used in [XKMS] and [XMLDSIG], so that 462 an implementation of this protocol can easily also support XKMS, and 463 vice versa. 465 It is also intended that other sacred protocol instances (e.g. using 466 different a authentication scheme, credential format or transport 467 protocol) can re-use many of the definitions here. 469 5.1 Download example 471 The example below briefly describes how messages 1 and 2 are handled 472 in XML. 474 475 =asedsd= 476 =asdss= 477 478 =asdfasfs= 479 480 482 In this example h("Alice") is , h("user string") is 483 and contains 2^A mod p. 485 486 =asedsd= 487 =asdss= 488 489 =sfdsdfs= 490 491 492 =asdsdsds= 493 494 496 Here, 2^B mod p is in , and the remaining information 497 (other than status codes) is in the < ProtectedCredential >. 498 h("Alice") and h("user string") are repeated (in case routing of 499 away-from-home requests is needed). {Y}K is in 500 . 502 Decryption (using K) of gives a 503 element (Y). 505 506 Alice 507 email cred 508 November 17th 1965 509 10000 510 511 ... 512 513 532 =asdasds= 533 534 535 ... 536 537 539 In the above the PKCS#15 payload is in a element and the 540 RSA private key used for authenticating credential uploads is in the 541 element. 543 5.2 All messages 545 All sacred messages have a "protocol" attribute that specifies the 546 version of the sacred protocol. For this specification the version 547 MUST be: 549 "sacred-2001-06-26" 551 <> 553 The type "ds:CryptoBinary" (inherited from [XMLDSIG]) is used for 554 all binary values. The value in such elements MUST be the base64 555 encoding of the binary value in network byte order. See [XMLDSIG] 556 for further details and example. 558 For cases, where the content of a binary field is likely to be 559 changed by some future sacred protocol variant (e.g. if some other 560 authentication scheme rather than PDM were used), we have defined 561 the type "TypedCryptoBinary" which contains a "ds:CryptoBinary" 562 element but with an additional "scheme" attribute specifying the 563 scheme in question. 565 For this specification a fixed scheme of "pdm" is used everywhere. 567 Where encryption is used in this specification the following rules 568 apply: 570 <> 574 1.Only entire elements are encrypted, in which case the recovered 575 plaintext MUST contain all the bytes from the leading "<" to the 576 final ">" characters 577 2.A sixteen byte random value MUST be prepended to the above 578 3.A SHA-1 digest is calculated over those bytes and appended to the 579 end of the data to be encrypted 580 4.Padding bytes are subsequently added to the end of the data to be 581 encrypted so that the final number of bytes is a multiple of 16; 582 if one padding byte is added then it MUST have the value '01'H, if 583 two bytes then '02'H, etc; if the unpadded data is already a 584 multiple of 16 bytes long, then 16 bytes are added, each with the 585 value '10'H 586 5.Those bytes are encrypted with the relevant key using AES in CBC 587 mode 588 6.The result of encryption is base64 encoded in placed into the 589 appropriate element according to the schema below 591 <> 593 When a password is used for encryption, the PKCS#5 PRKDF2 key 594 derivation function MUST be used to derive a key from the password. 596 The fixed types used by this specification include (in each case 597 "&sacred" expands to "sacred-2001-06-26"): 599 "&sacred#pdm" used for typing Verifier elements; refers to the 600 PDM authentication scheme described here 601 "&sacred#aes" denotes the AES based ciphersuite described 602 above 603 "&sacred#rsa-siging"denotes the RSA based credential upload 604 authentication scheme 605 "&sacred#pkcs-15" labels a payload as containing a PKCS#15 606 structure 608 5.3 Message 1 610 <> 613 The schema for message 1 is: 615 - HashedName MUST contain the SHA-1 digest of the UTF8 encoding of 616 the user's name 618 - Realm, if present, MUST contain the FQDN of the host which is the 619 user's "home" sacred server; when Realm is specified the user name 620 string that is digested for HashName MUST also include the realm 621 part of the name (note: This means that servers MUST be able to 622 handle two different values of HashedName for each account, with 623 and without the FQDN) 624 - HashedCredSel, when present MUST contain the SHA-1 digest of the 625 UTF8 encoding of the user string 626 - Verifier MUST have scheme set to "PDM" and MUST contain the base64 627 encoding of "2^A mod p" 628 - The optional UploadToFollow attribute MUST have the value "true" 629 or "false". If no UploadToFollow attribute is present then the 630 value "false" MUST be assumed. This attribute indicates that the 631 client wishes to follow the download operation with subsequent 632 uploads and that the server MUST return an "R" value. If a server 633 implementation does not support credential uploads it MUST respond 634 with an error whenever a request with UploadToFollow is set to 635 "true" 637 5.4 Message 2 639 The schema for message 2 is: 641 - HashedName MUST be as in message 1 642 - HashedCredSel MUST be as in message 1 (missing or same value) 643 - Verifier MUST have scheme set to "PDM" and MUST contain the base64 644 encoding of "2^B mod p" 645 - ProtectedCredential MUST contain a SacredCredential element 646 encrypted with key K 647 - UploadChallenge MUST be present if the UploadToFollow attribute 648 from message 1 had the value "true", in which case, it MUST 649 contain the base64 encoded a random value, R 651 Upon decryption of ProectedCredential a SacredCredential MUST be 652 recovered with the following schema: 654 - KeyID MUST be the UTF8 encoding of the user name, and MUST be the 655 value which when digested using SHA-1 is HashedName in messages 1 656 and 2 657 - CredentialSelector, if present, MUST be the UTF8 encoding of the 658 user name, and MUST be the value which when digested using SHA-1 659 is HashedCredSel in messages 1 and 2 660 - LastModified MUST contain a human-readable time value, for 661 example, "November 17th 1965" or "19651117120000" 662 - TimeToLive MUST contain an integer value, specifying the number of 663 seconds from the download time for which this credential SHOULD be 664 used; following the expiry of this period, client implementations 665 SHOULD delete the credential from local storage 666 - UploadValidator MUST contain the "pub" value in an RSAKeyValue 667 KeyInfo element, as specified in [XMLDSIG] 668 - EncryptedCredentialElements MUST contain a PlainSacredCredential 669 structure encrypted using the user's password 671 - The Signature element MAY contain the HMAC-SHA1 protection of the 672 entire SacredCredential element, using the PRKDF2-derived value 673 (from the password) as a key; this is an enveloped signature in 674 [XLMDSIG] terms; implementations MUST support the use of this 675 field, but MAY allow user's to turn this feature "off" 677 Upon decryption of EncryptedCredentialElements, a 678 PlainSacredCredential is recoved, with the following schema: 680 - At least one Payload element MUST be present, which MUST contain 681 the base64 encoding of a PKCS#15 structure, (this is represented 682 as a ds:KeyInfo containing a SacredPKCS15 element); additional 683 payload elements MAY be present if they use other ds:KeyInfo types 684 (i.e. only one PKCS#15 is allowed); implementations MUST ignore 685 these additional Payload elements if they cannot process them 686 - One RSA private key MUST be present in the SignatureAuth element 687 of the UploadAuthenticator; the scheme attribute of the 688 UploadAuthenticator element MUST be present and MUST have the 689 value "RSA-SIGNATURE" 691 5.5 Message 3 693 Note that implementations MAY support one user/account carrying out 694 messages 1 and 2, and that same user being allowed to run the upload 695 protocol for other users/accounts (i.e. an administrator type). 696 Conformant implementations MAY also refuse to allow all such 697 requests and only allow upload of a credential "owned" by the same 698 account, or MAY refuse all upload requests entirely (though they 699 MUST produce an appropriate error in response to message 1 in such 700 cases). 702 The schema for message 3 is: 704 - UploadChallenge MUST contain the value from message 2 above; the 705 server MUST ensure that the same UploadChallenge value is used for 706 all SacredUploadRequest messages for this BEEP session 707 - SequenceNumber MUST contain a unique string for this BEEP session 708 (note: it does not have to be numeric); the server MUST ensure 709 that a different value is used for every SacredUploadRequest for 710 this BEEP session 711 - NewCredential contains a SacredCredential structure which would be 712 acceptable for inclusion in a future message 2; this structure 713 MUST be encrypted using the key K, which was agreed as a result of 714 exchanging messages 1 and 2 715 - UploadVerifier MUST contain a signature, verifiable using the 716 public key from the credential downloaded in message 2 (i.e. NOT 717 using the public key from the NewCredential in this message), over 718 the entire SacredUploadRequest (i.e. an enveloped signature in 719 [XMLDSIG] terms) 721 5.6 Message 4 722 The schema for message 4 is: 724 - UploadAck MUST contain the encrypted (using the K from messages 725 1/2) SequenceNumber of the corresponding message 3 727 5.7 Error handling 729 <> 733 With the exception of the cases below, the �error� message from 734 Section 2.3.1.5 of [BEEP] is used to convey error information. 735 Typically, after flagging an error, a peer will initiate a graceful 736 release of the BEEP session. 738 The exceptions to this are: 740 - All errors as a result of a "bad" message 1 (regardless of the 741 type of error) MUST result in the server emitting a properly 742 structured message 2, but one which contains random values 743 - In the case of server-server interactions (the away-from-home 744 case) the servers MAY keep the BEEP session open 746 The following BEEP error reply codes are to be used: 748 <> 751 code meaning 752 ==== ======= 753 421 service not available 755 450 requested action not taken 756 (e.g., lock already in use) 758 451 requested action aborted 759 (e.g., local error in processing) 761 454 temporary authentication failure 763 500 general syntax error 764 (e.g., poorly-formed XML) 766 501 syntax error in parameters 767 (e.g., non-valid XML) 769 504 parameter not implemented 771 530 authentication required 773 534 authentication mechanism insufficient 774 (e.g., too weak, sequence exhausted, etc.) 776 535 authentication failure 778 537 action not authorized for user 780 538 authentication mechanism requires encryption 782 550 requested action not taken 783 (e.g., no requested profiles are acceptable) 785 553 parameter invalid 787 554 transaction failed 788 (e.g., policy violation) 790 5.8 Extensibility 792 The sections above defined the elements that MUST/MAY be included in 793 messages 1 to 4. Clients and servers which are presented with 794 messages which are syntactically valid but which include other 795 fields MUST ignore all of those fields. 797 Future memos may define alternative versions of the BEEP profile for 798 PDM. When a BEEP peer sends its greeting, it indicates which 799 profiles it is willing to support. Accordingly, when the BEEP client 800 asks to start a channel, it indicates the versions it supports, and 801 if any of these are acceptable to the BEEP server, it specifies 802 which profile it is starting. 804 6. BEEP Profile for Sacred 806 The protocol described in this memo is realized as a [BEEP] profile. 808 Profile Identification: http://xml.resource.org/profiles/pdm 810 Messages Exchanged during Channel Creation: SacredDownloadRequest, 811 SacredDownloadResponse, error 813 Messages starting one-to-one exchanges: SacredDownloadRequest, 814 SacredUploadRequest 816 Messages in positive replies: SacredDownloadResponse, 817 SacredUploadResponse 819 Messages in negative replies: error 821 Messages in one-to-many changes: none 823 Message Syntax: c.f.,Section 5 824 Message Semantics: c.f., Section 2 826 Contact Information: c.f., the Authors� Addresses section of this 827 memo 829 6.1 Profile Initialization 831 The SacredDownloadRequest and SacredDownloadResponse may be 832 exchanged during channel initialization (c.f., Section 2.3.1.2 of 833 [BEEP]), e.g., 835 C: 836 C: 837 C: ]]> 838 C: 839 C: 841 S: 842 S: ]]> 843 S: 845 Note that BEEP imposes both encoding and length limitations on the 846 messages that are piggybacked during channel initialization. 848 6.2 Profile Exchange 850 All messages are exchanged as �application/beep+xml� (c.f., Section 851 6.4 of [BEEP]): 853 Role MSG RPY ERR 855 I SacredDownloadRequest SacredDownloadResponse error 857 I SacredUploadRequest SacredUploadResponse error 859 7. IANA Considerations 861 If the IANA approves this memo for standards-track publication, then 862 the IANA registers the BEEP profile specified in Section 6, and 863 selects an appropriate standards-track URI, e.g., 865 http://iana.org/beep/pdm 867 8. Security Considerations 869 <> 871 Note that Section 2.3 requires that the BEEP session be tuned for 872 privacy before the BEEP profile for PDM is started. Accordingly, 873 implementations may wish to advertise only tuning profiles used for 874 privacy in their initial greeting (c.f., Section 3 of [BEEP]), and 875 then advertise the BEEP profile for PDM after a tuning restart. 877 References 879 [AES] AES home page: http://csrc.nist.gov/encryption/aes/ 880 [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol 881 Core", RFC 3080. 882 [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax 883 Standard," RSA Laboratories, June 2000. 884 [REQS] Arsenault, A., Farrell, S., "Securely Available 885 Credentials - Requirements" 886 draft-ietf-sacred-reqs-02.txt - work-in-progress 887 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 888 3", RFC 2026. 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", RFC 2119. 891 [XKMS] Hallam-Baker, P. et al, "XML Key Management 892 Specification", http://www.w3.org/TR/XKMS 893 [XMLDSIG] Eastlake, D., et al. "XML-Signature Syntax and 894 Processing", RFC 2075. 896 Acknowledgements 898 <> 900 Authors' Addresses 902 Stephen Farrell, 903 Baltimore Technologies, 904 39 Parkgate Street, 905 Dublin 8, 906 IRELAND 907 Phone: +353-1-881-6000 908 Email: stephen.farrell@baltimore.ie 910 Radia Perlman 911 Sun Microsystems 912 Email: radia.perlman@sun.com 914 Charlie Kaufman 915 Iris Associates 916 Email: ckaufman@iris.com 918 Marshall T. Rose 919 Invisible Worlds, Inc. 920 131 Stony Circle 921 Suite 500 922 Santa Rose, CA 95401 923 US 924 Phone: +1 707 578 2350 925 EMail: mrose@invisible.net 926 URI: http://invisible.net/ 928 Full Copyright Statement 930 Copyright (C) The Internet Society (date). All Rights Reserved. 932 This document and translations of it may be copied and furnished to 933 others, and derivative works that comment on or otherwise explain it 934 or assist in its implementation may be prepared, copied, published 935 and distributed, in whole or in part, without restriction of any 936 kind, provided that the above copyright notice and this paragraph 937 are included on all such copies and derivative works. In addition, 938 the ASN.1 module presented in Appendix B may be used in whole or in 939 part without inclusion of the copyright notice. However, this 940 document itself may not be modified in any way, such as by removing 941 the copyright notice or references to the Internet Society or other 942 Internet organizations, except as needed for the purpose of 943 developing Internet standards in which case the procedures for 944 copyrights defined in the Internet Standards process shall be 945 followed, or as required to translate it into languages other than 946 English. 948 The limited permissions granted above are perpetual and will not be 949 revoked by the Internet Society or its successors or assigns. This 950 document and the information contained herein is provided on an "AS 951 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 952 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 953 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 954 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 955 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 957 Appendix A: Schema 959 960 969 975 976 977 978 979 980 982 984 985 986 987 989 990 992 993 994 995 996 997 999 1000 1002 1005 1006 1007 1008 1010 1011 1012 1013 1014 1015 1017 1018 1019 1020 1021 1022 1024 1025 1026 1027 1028 1029 1030 1031 1032 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1045 1046 1047 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1062 1063 1064 1065 1066 1067 1069 1070 1072 1073 1075 1077 1078 1079 1081 1082 1083 1084 1085 1087 1088 1089 1090 1092 1093 1094 1095 1096 1097 1098 1099 1101 1102 1103 1105 1107 1109 1111 1113 1115 1116 1118 1120 Appendix B: DTD 1122 In cases of conflict, the schema in Appendix B above is to be 1123 followed. 1125 <> 1129 1130 1131 1132 1136 1139 1141 1145 1147 1150 1151 1153 1156 1157 1160 1161 1164 1165 1166 1167 1168 1169 1171 1174 1175 1178 1179 1180 1181 1182 1185 1186 1187 1188 1191 1192 1195 1196 1199 1200 1201 1204 1205 1208 1209 1212 1213 1214 1215 1216 1217 1218 1220 Appendix C: Open Issues 1222 There are various decisions we made which the working group might 1223 like to debate. 1225 (1) We can fix the size of the moduli at 512-bits. If the only 1226 attack on the protocol is to break 512-bit Diffie-Hellman for each 1227 guessed password, 512 is a secure size for this protocol. 1229 If it is desired to use larger moduli, in case someone finds some 1230 attack for which Diffie-Hellman can be simultaneously broken for 1231 multiple p's, then computation at the client for computing p will be 1232 excessive. For instance, on a 400-Mhz processor, we estimate 30 1233 seconds to generate a 768-bit p, and 110 seconds to generate a 1024- 1234 bit key, whereas to generate a 512-bit key will take less than 10 1235 seconds. 1237 If it is desired to use larger moduli, computation at the client can 1238 be made tolerable through allowing the user to type an additional 1239 character, a "hint". The hint character would be told to the user, 1240 and would be a function of the p resulting from that user's choice 1241 of password. Each time p is calculated from the password without the 1242 hint, the user is informed that in the future, calculation would 1243 proceed more quickly if the user additionally remembered and typed 1244 the extra character. 1246 (2) The hint is one of 64 characters (uppercase letters, lowercase 1247 letters, numbers, "+", or "=") which represents 6 bits. This enables 1248 the client machine, when computing p, to ignore all candidate p's 1249 that do not contain those 6 bits at a particular offset. The bottom 1250 3 bits of p are constrained to be "011" because due to an obscure 1251 number theoretic theorem known as the quadratic reciprocity theorem, 1252 if p=3 mod 8, and p is a safe prime (also known as a Sophie-Germain 1253 prime), which is defined to be a prime p such that p and also (p- 1254 1)/2 are prime, then 2 will be a generator. 1256 So since bits 0, 1, and 2 are constrained, we would suggest using 1257 bits 3-8 to represent the 64 possible values of the user hint. With 1258 a user-supplied hint, computing a 1024-bit prime takes under 2 1259 seconds. 1261 Adding a user-supplied hint does not affect the on-the-wire 1262 protocol. It merely affects the user interface at the client. One 1263 possible user interface is for the user to supply a hint by typing 1264 the password, followed by space, followed by the hint character. 1265 This assumes that space would not be a legal character in a 1266 password. If there are no characters illegal in a password, then 1267 the client machine can prompt the user for the hint character, as in 1268 "password?", "hint (if known)?". 1270 (3) Should the RSA key used to validate uploads be usable for 1271 anything other than sacred, or should we allow it to be used for 1272 other purposes?