INTERNET-DRAFT Stephen Farrell expires in six months Baltimore Technologies Radia Perlman Sun Microsystems Charlie Kaufman Iris Associates Marshall Rose Invisible Worlds, Inc. June 2001 Securely Available Credentials - The PDM Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a PDM-based protocol for securely available credentials. Discussion of this draft is taking place on the SACRED mailing list of the IETF SACRED working group (see http://www.imc.org/ietf-sacred for subscription information). Farrell & al [Page 1] INTERNET-DRAFT June 2001 Table Of Contents Status of this Memo.............................................1 Abstract........................................................1 Table Of Contents...............................................2 1. Introduction.................................................2 2. The protocol.................................................3 3. Computation at the client machine............................9 4. Computation at the server machine............................9 5. XML Messages.................................................9 6. BEEP Profile for Sacred.....................................16 7. IANA Considerations.........................................17 8. Security Considerations.....................................17 References.....................................................18 Acknowledgements...............................................18 Authors' Addresses.............................................18 Full Copyright Statement.......................................19 Appendix A: Schema.............................................19 Appendix B: DTD................................................22 Appendix C: Open Issues........................................24 1. Introduction We describe a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS#15 structures) from a workstation with locally trusted software but with no user-specific configuration. This is somewhat less secure than a smart card, but can be used until smart cards and smart card readers on workstations become ubiquitous, and can be useful even after smart cards are ubiquitous, as a backup strategy when a user's smart card is lost or malfunctioning. The protocol sets out to meet the requirements in [REQS]. This protocol assumes a reasonably powerful workstation (e.g., 400 MHz) since it is computationally expensive at the client end. This protocol strives to maximize server performance and make the server more robust against denial of service attacks by saving as much computation as possible for the server. For credential download, this protocol requires only a single exponentiation at the server, and is secure with smaller moduli than other protocols because the modulus itself is secret. Traditional Diffie-Hellman with 500 -bit fixed modulus is estimated to take 8000 MIP-years to break, so when Diffie-Hellman is used in the traditional way (publicly known moduli), it is recommended that the moduli be 1000 bits. But in this scheme, it would require breaking 500-bit Diffie- Hellman per user per password guess. It would be far less expensive to do an on-line attack for each guessed password than to eavesdrop on a successful authentication, guess passwords (and therefore Farrell & al [Page 2] INTERNET-DRAFT June 2001 moduli) and break Diffie-Hellman for each password guess. By using smaller moduli we save the server additional computation, somewhere between a factor of 2 and 8 over computation using 1000 bit moduli. We assume the only authentication information available to the user is a password. Many user-chosen passwords are vulnerable to dictionary attacks. So this protocol is designed to give no information with which an attacker can acquire information for launching a dictionary attack, whether by eavesdropping or by impersonating either the client or server. The protocol also allows a user to change her password and/or credentials and upload the new values to the server. The protocol ensures that only someone that knew the old password is able to modify the credentials. The protocol does not preclude configuring a server to disallow credential upload from some users. We also specify a protocol in which a systems administrator can authenticate, and if authorized, create new user entries with downloadable credentials, and/or modify existing user entries. If someone steals the server database they can launch a dictionary attack. If the dictionary attack is successful, the attacker can decrypt the user's credentials. An attacker that has learned the user's password can also upload new credentials, assuming the user is authorized to modify the credentials, because someone who knows the user's password is assumed to be the user. However, if someone steals the server database and is unsuccessful at obtaining the user's password through a dictionary attack, they will be unable to upload new credentials. A common error is for a user to type her password instead of her name. If the name is sent over the wire in the clear, this leads to the possibility of the user's password being over the wire in the clear when the user has mistakenly typed her password instead of her name. To guard against this we send the hash of the user's name rather than the user's name. This means that the protocol should canonicalize the user's name (for instance, convert all letters to lowercase), since the server will not be able to recognize an approximation of the name. 2. The protocol We assume the credentials server has a name, such as "Bob". The purpose of the server name is to generate a quantity X that will be different for each server that a user might interact with, even if the user has the same password on these servers. For more description of the cryptographic basis of this protocol see [PDM]. The credentials server stores for each user/account: Farrell & al [Page 3] INTERNET-DRAFT June 2001 - username (e.g. "Alice") This can optionally contain a "realm" component, where the realm is an FQDN (e.g. "Alice@baltimore.ie") - p: (safe prime pseudorandomly generated from seed h("Alice", password) This prime is used as the modulus in a Diffie-Hellman exchange. - pub: public RSA key (required for credential uploads only) Alice might use other key pairs, or public keys that are not RSA keys, for other applications. These can be included, along with the private RSA key needed for the credential upload portion of the PDM-sacred protocol, in the encrypted credential. All credentials (including the private key for uploads) are downloaded with the same credential bundle "Y" (next item). - Y=Alice's credentials encrypted with her password The credentials consists of (an optional user string, RSA public and private key, optional payload, date last changed and TTL). Some of these fields are encrypted with the user's password (marked below). - Date last changed is there to alert the user in case someone unauthorized has somehow managed to replace the current credential with an older version. - The (optional) user string is used to allow users to store more than one credential payload under the same password at the same server. - (Optionally) A time-to-live value specifying the number of seconds for which the credential SHOULD be usable following download. - The RSA private key used for signing credential uploads, and perhaps for other purposes. [Encrypted] - "Payload" is the set of information being managed by this protocol (e.g., a PKCS#15 structure). If the RSA private key used for the credential upload is all the user needs for credentials, then the "payload" can be zero length. Typically, the payload will contain a PKCS#15 structure. [Encrypted] - X=h("Alice", "Bob", Alice's password) This quantity is used by the protocol to ensure that two servers on which Alice uses the same password will not be able to impersonate each other to Alice. <> There are two protocols described here. The first is for credentials download; the second for credentials upload. Credentials download consists of two messages, following which the BEEP session MAY be closed. Credentials upload consists of the same first two messages followed by two more messages to upload new credentials. If a systems administrator is modifying many user accounts during the Farrell & al [Page 4] INTERNET-DRAFT June 2001 same BEEP session, messages 3 and 4 are repeated for each user account being modified. 2.1 Credentials Download Alice and Bob establish a Diffie-Hellman key based on an exchange using 2 as the base and p as the modulus, and private exponents A (for Alice) and B (for Bob). Bob returns Alice's credential Y encrypted with the high quality secret 2^AB mod p. We save Bob work by having him always use the same B for Alice, and have 2^B mod p pre-computed and stored. We can also have Bob choose a random number R. R is ignored by Alice if all she is doing is downloading credentials. If she is uploading credentials, though, she will sign R using the RSA private key stored (encrypted) within Y, and the new information that needs to be stored. Bob can verify the signature using the RSA public key stored (in clear) within Y. The purpose of the signature is to ensure that someone that steals Bob's database cannot upload a credential without doing a successful dictionary attack to obtain Alice's password and decrypt the stored credential. The off-line dictionary attack is necessary in order to retrieve the RSA private key required to sign the value R. In the basic download protocol, the human Alice types her name and password into her workstation, which computes p. The exchange then consists of: Message 1: Alice to Bob: h("Alice"), 2^A mod p Message 2: Bob to Alice: "Bob", 2^B mod p, {Y}K Where K=h(2^AB mod p, X) Note our notation: {data}K means "data" encrypted based on key K [data]Alice means "data" signed with Alice's private key 2.2 Credentials upload In this protocol the client machine obtains the old credentials, decrypts them, and prepares new credentials based on the new password, and uploads those. There was no need to explicitly authenticate the server in the credentials download case, because the credentials are self- authenticating, and if correct, it doesn't matter who gave them to the client. The credentials are self-authenticating due to the inclusion of a digest with the encryption. For download, there was also no need to explicitly authenticate the client because nobody without knowledge of the password would be able to make use of the credentials. And there was no need to worry Farrell & al [Page 5] INTERNET-DRAFT June 2001 about someone who stole the server database impersonating the client because if someone stole the server database they would already know the credential, so there was no reason to prevent them from downloading them. Things are different for credentials upload. It is important for the server to know that the new credential is being stored by someone who knew the old password (so that a valid credential isn't overwritten with garbage). The client wants to make sure it is storing the credential at a valid server, and not giving the new credential to an imposter, so the client must authenticate the server. Even if the new credentials are encrypted with a strong session key that only a server that knew the old credential could derive, it is still important for the client to know that when it is told that the new credential was stored, that it really was stored. Another vulnerability that needs to be avoided in upload that did not exist in download is that it is important to ensure that someone that has read-only access to the server database cannot replace the user's credential via the protocol, even if all they can replace it with is garbage. Messages 1 and 2 download the credential and establish a strong secret K (=h(2^AB mod p, X)) between the client and server. This time, Alice should include an "upload requested" flag in message 1, and Bob should include R in message 2: Message 1: Alice to Bob: h("Alice"), 2^A mod p, "upload" Message 2: Bob to Alice: "Bob", 2^B mod p, R, {Y}K Messages 3 and 4 accomplish mutual authentication and upload of the new credential. This is done so that someone who stole the server database but did not successfully derive the user's password through a dictionary attack would not be able to impersonate the client and overwrite the user's credential. Message 3: {[username,sequence number, R, new Y, and optionally: new p, X, B, pub, 2^B mod p]signed by Alice's private key}K Note: username is present to allow a system administrator to keep a connection open and upload new credentials for many users. The private key with which the message is signed is the private key of whoever initiated the session in messages 1 and 2, which we call Alice. "username" might be the name of a user for whom Alice is authorized to create or modify credentials. "Sequence number" allows multiple uploads of the same user account, so that one with a smaller sequence number within the same BEEP session is ignored. This prevents the (admittedly obscure) threat of someone replaying previous message 3's within the same BEEP session. The encrypted sequence number in message 4 serves as an acknowledgement. Farrell & al [Page 6] INTERNET-DRAFT June 2001 Message 4: {sequence number}K This serves as an acknowledgement to the client that this upload was successful. Credentials might change because the user changed her password, or one of the items included in the credential (such as a private key) might change even if the password does not change. Or she might change both the password and the contents of the credential. In either case Y will be new. But if the password has not changed, then p and X would not change. So p and X are optional in message 3.. The only reason to include new B and 2^B mod p in message 3 is to save the server one exponentiation (to calculate the new 2^B mod p). The server can accept the values from the client or calculate its own. Optionally, when the server has spare cycles, it can gradually choose new B's for each user and replace B and 2^B mod p for that user. Message 4 serves as an acknowledgement that the new credentials have been received by a server that knew the old credentials (and so was able to calculate K). The server should not send the acknowledgement until the new credentials have been written to stable storage. 2.3 Away-from-home operation If the user includes the optional realm component in message 1 then the user wants to play the sacred protocol with the server named in the realm component of the user name (call this the target server). In this case, if the server initially contacted is not the one named in the realm part of the name, then the initial server MUST be able to act as a proxy on the user's behalf. That is, the initial server MUST be able to forward all packets between the user and the target server and vice versa. The initial and target servers MUST be able to, and SHOULD always, use mutually authenticated TLS to secure and authenticate the BEEP sessions between them. An initial server MAY refuse to act as a proxy (for policy reasons). A target server MAY refuse to accept requests via a proxy (for policy reasons). Implementations SHOULD support controls allowing enforcement of this policy. In this mode the messages exchanged for download are: Message 1: Alice to Bob: h("Alice@host.somewhere.com"), "host.somewhere.com", 2^A mod p Farrell & al [Page 7] INTERNET-DRAFT June 2001 ...Bob and host.somewhere.com establish a TLS-secured BEEP session with mutual authentication... Message 1': Bob to Target: bytes from message 1 Message 2': Target to Bob: "Target", 2^B mod p, {Y}K Message 2: Bob to Alice: bytes from message 2' The diagram below shows the interactions involved: +--------+ +---------+ +---------+ | User | | Proxy | | Home | | | Message 1 | | | | | +------------->| | Message1 | | | | | +----------->| | | | | | | | | | | |<-----------+ | | |<-------------+ | Message 2 | | | | Message2 | | | | +--------+ +---------+ +---------+ Implementations MUST NOT support credentials upload in away-from- home fashion. <> <> 2.4 Handling multiple payloads When a user has more than one credential stored on a single server, under a single username, then the user can nominate the credential requested in the various messages above using the optional user string stored by the server. Servers SHOULD treat the first credential stored (time-wise) under that username as the default for the account. User strings MAY be included in the upload protocol. It is an error to have more than one credential stored under the same account where neither has a user string. That is, there can only be one default. It is also an error to have more than one credential stored under the same account where both have the same user string. Including the user strings the protocol looks like: Message 1: Alice to Bob: h("Alice"), h("user string"), 2^A mod p Message 2: Bob to Alice: "Bob", 2^B mod p, {Y}K Farrell & al [Page 8] INTERNET-DRAFT June 2001 The upload protocol is not affected since the user string is an optional part of Y in any case. The user string is hashed above for the same reasons as the username. 3. Computation at the client machine The user types her name and password. From this the client machine calculates p, and finds an appropriate credential downloading server either directly or via a SACRED proxy. The client machine initiates a BEEP session, starts the BEEP profile for PDM, chooses a random Diffie-Hellman exponent A, and sends message 1. The server responds with message 2, which enables the client machine to calculate X (because it is supplied with the server name), 2^AB mod p, and therefore K. It uses K to decrypt bytes from message 2, giving Y, and then uses the user's password to decrypt (parts of) Y to obtain the user's credentials. That is, the payload of Y is doubly encrypted when transferred over the network. If a user string was supplied, then the client MUST verify that Y contains the same string. If the client machine has a suitable human user interface, then it SHOULD display the user string and the date last modified. <> 4. Computation at the server machine The server receives message1 and looks up an entry in its database using the hashed username. The server calculates K, using 2^A mod p from message1 and X and 2^B mod p, from its database. The server encrypts Y using K (assuming that Y is stored partly encrypted under the user's password), and returns message2. If message1 indicated that the client wishes to follow the download with an upload, then the server generates a random string R for inclusion in message2. The server MUST maintain state in order to be able to verify that the same R is used in message3. <> 5. XML Messages This section describes the message formats used, which are based on XML. Appendices A & B provide schema and DTD for the sacred elements. Farrell & al [Page 9] INTERNET-DRAFT June 2001 The approach taken here is to define sacred elements that are compatible with the elements used in [XKMS] and [XMLDSIG], so that an implementation of this protocol can easily also support XKMS, and vice versa. It is also intended that other sacred protocol instances (e.g. using different a authentication scheme, credential format or transport protocol) can re-use many of the definitions here. 5.1 Download example The example below briefly describes how messages 1 and 2 are handled in XML. =asedsd= =asdss= =asdfasfs= In this example h("Alice") is , h("user string") is and contains 2^A mod p. =asedsd= =asdss= =sfdsdfs= =asdsdsds= Here, 2^B mod p is in , and the remaining information (other than status codes) is in the < ProtectedCredential >. h("Alice") and h("user string") are repeated (in case routing of away-from-home requests is needed). {Y}K is in . Decryption (using K) of gives a element (Y). Alice email cred November 17th 1965 10000 ... Farrell & al [Page 10] INTERNET-DRAFT June 2001 =asdasds= ... In the above the PKCS#15 payload is in a element and the RSA private key used for authenticating credential uploads is in the element. 5.2 All messages All sacred messages have a "protocol" attribute that specifies the version of the sacred protocol. For this specification the version MUST be: "sacred-2001-06-26" <> The type "ds:CryptoBinary" (inherited from [XMLDSIG]) is used for all binary values. The value in such elements MUST be the base64 encoding of the binary value in network byte order. See [XMLDSIG] for further details and example. For cases, where the content of a binary field is likely to be changed by some future sacred protocol variant (e.g. if some other authentication scheme rather than PDM were used), we have defined the type "TypedCryptoBinary" which contains a "ds:CryptoBinary" element but with an additional "scheme" attribute specifying the scheme in question. Farrell & al [Page 11] INTERNET-DRAFT June 2001 For this specification a fixed scheme of "pdm" is used everywhere. Where encryption is used in this specification the following rules apply: <> 1.Only entire elements are encrypted, in which case the recovered plaintext MUST contain all the bytes from the leading "<" to the final ">" characters 2.A sixteen byte random value MUST be prepended to the above 3.A SHA-1 digest is calculated over those bytes and appended to the end of the data to be encrypted 4.Padding bytes are subsequently added to the end of the data to be encrypted so that the final number of bytes is a multiple of 16; if one padding byte is added then it MUST have the value '01'H, if two bytes then '02'H, etc; if the unpadded data is already a multiple of 16 bytes long, then 16 bytes are added, each with the value '10'H 5.Those bytes are encrypted with the relevant key using AES in CBC mode 6.The result of encryption is base64 encoded in placed into the appropriate element according to the schema below <> When a password is used for encryption, the PKCS#5 PRKDF2 key derivation function MUST be used to derive a key from the password. The fixed types used by this specification include (in each case "&sacred" expands to "sacred-2001-06-26"): "&sacred#pdm" used for typing Verifier elements; refers to the PDM authentication scheme described here "&sacred#aes" denotes the AES based ciphersuite described above "&sacred#rsa-siging"denotes the RSA based credential upload authentication scheme "&sacred#pkcs-15" labels a payload as containing a PKCS#15 structure 5.3 Message 1 <> The schema for message 1 is: - HashedName MUST contain the SHA-1 digest of the UTF8 encoding of the user's name Farrell & al [Page 12] INTERNET-DRAFT June 2001 - Realm, if present, MUST contain the FQDN of the host which is the user's "home" sacred server; when Realm is specified the user name string that is digested for HashName MUST also include the realm part of the name (note: This means that servers MUST be able to handle two different values of HashedName for each account, with and without the FQDN) - HashedCredSel, when present MUST contain the SHA-1 digest of the UTF8 encoding of the user string - Verifier MUST have scheme set to "PDM" and MUST contain the base64 encoding of "2^A mod p" - The optional UploadToFollow attribute MUST have the value "true" or "false". If no UploadToFollow attribute is present then the value "false" MUST be assumed. This attribute indicates that the client wishes to follow the download operation with subsequent uploads and that the server MUST return an "R" value. If a server implementation does not support credential uploads it MUST respond with an error whenever a request with UploadToFollow is set to "true" 5.4 Message 2 The schema for message 2 is: - HashedName MUST be as in message 1 - HashedCredSel MUST be as in message 1 (missing or same value) - Verifier MUST have scheme set to "PDM" and MUST contain the base64 encoding of "2^B mod p" - ProtectedCredential MUST contain a SacredCredential element encrypted with key K - UploadChallenge MUST be present if the UploadToFollow attribute from message 1 had the value "true", in which case, it MUST contain the base64 encoded a random value, R Upon decryption of ProectedCredential a SacredCredential MUST be recovered with the following schema: - KeyID MUST be the UTF8 encoding of the user name, and MUST be the value which when digested using SHA-1 is HashedName in messages 1 and 2 - CredentialSelector, if present, MUST be the UTF8 encoding of the user name, and MUST be the value which when digested using SHA-1 is HashedCredSel in messages 1 and 2 - LastModified MUST contain a human-readable time value, for example, "November 17th 1965" or "19651117120000" - TimeToLive MUST contain an integer value, specifying the number of seconds from the download time for which this credential SHOULD be used; following the expiry of this period, client implementations SHOULD delete the credential from local storage - UploadValidator MUST contain the "pub" value in an RSAKeyValue KeyInfo element, as specified in [XMLDSIG] - EncryptedCredentialElements MUST contain a PlainSacredCredential structure encrypted using the user's password Farrell & al [Page 13] INTERNET-DRAFT June 2001 - The Signature element MAY contain the HMAC-SHA1 protection of the entire SacredCredential element, using the PRKDF2-derived value (from the password) as a key; this is an enveloped signature in [XLMDSIG] terms; implementations MUST support the use of this field, but MAY allow user's to turn this feature "off" Upon decryption of EncryptedCredentialElements, a PlainSacredCredential is recoved, with the following schema: - At least one Payload element MUST be present, which MUST contain the base64 encoding of a PKCS#15 structure, (this is represented as a ds:KeyInfo containing a SacredPKCS15 element); additional payload elements MAY be present if they use other ds:KeyInfo types (i.e. only one PKCS#15 is allowed); implementations MUST ignore these additional Payload elements if they cannot process them - One RSA private key MUST be present in the SignatureAuth element of the UploadAuthenticator; the scheme attribute of the UploadAuthenticator element MUST be present and MUST have the value "RSA-SIGNATURE" 5.5 Message 3 Note that implementations MAY support one user/account carrying out messages 1 and 2, and that same user being allowed to run the upload protocol for other users/accounts (i.e. an administrator type). Conformant implementations MAY also refuse to allow all such requests and only allow upload of a credential "owned" by the same account, or MAY refuse all upload requests entirely (though they MUST produce an appropriate error in response to message 1 in such cases). The schema for message 3 is: - UploadChallenge MUST contain the value from message 2 above; the server MUST ensure that the same UploadChallenge value is used for all SacredUploadRequest messages for this BEEP session - SequenceNumber MUST contain a unique string for this BEEP session (note: it does not have to be numeric); the server MUST ensure that a different value is used for every SacredUploadRequest for this BEEP session - NewCredential contains a SacredCredential structure which would be acceptable for inclusion in a future message 2; this structure MUST be encrypted using the key K, which was agreed as a result of exchanging messages 1 and 2 - UploadVerifier MUST contain a signature, verifiable using the public key from the credential downloaded in message 2 (i.e. NOT using the public key from the NewCredential in this message), over the entire SacredUploadRequest (i.e. an enveloped signature in [XMLDSIG] terms) 5.6 Message 4 Farrell & al [Page 14] INTERNET-DRAFT June 2001 The schema for message 4 is: - UploadAck MUST contain the encrypted (using the K from messages 1/2) SequenceNumber of the corresponding message 3 5.7 Error handling <> With the exception of the cases below, the ôerrorö message from Section 2.3.1.5 of [BEEP] is used to convey error information. Typically, after flagging an error, a peer will initiate a graceful release of the BEEP session. The exceptions to this are: - All errors as a result of a "bad" message 1 (regardless of the type of error) MUST result in the server emitting a properly structured message 2, but one which contains random values - In the case of server-server interactions (the away-from-home case) the servers MAY keep the BEEP session open The following BEEP error reply codes are to be used: <> code meaning ==== ======= 421 service not available 450 requested action not taken (e.g., lock already in use) 451 requested action aborted (e.g., local error in processing) 454 temporary authentication failure 500 general syntax error (e.g., poorly-formed XML) 501 syntax error in parameters (e.g., non-valid XML) 504 parameter not implemented 530 authentication required 534 authentication mechanism insufficient Farrell & al [Page 15] INTERNET-DRAFT June 2001 (e.g., too weak, sequence exhausted, etc.) 535 authentication failure 537 action not authorized for user 538 authentication mechanism requires encryption 550 requested action not taken (e.g., no requested profiles are acceptable) 553 parameter invalid 554 transaction failed (e.g., policy violation) 5.8 Extensibility The sections above defined the elements that MUST/MAY be included in messages 1 to 4. Clients and servers which are presented with messages which are syntactically valid but which include other fields MUST ignore all of those fields. Future memos may define alternative versions of the BEEP profile for PDM. When a BEEP peer sends its greeting, it indicates which profiles it is willing to support. Accordingly, when the BEEP client asks to start a channel, it indicates the versions it supports, and if any of these are acceptable to the BEEP server, it specifies which profile it is starting. 6. BEEP Profile for Sacred The protocol described in this memo is realized as a [BEEP] profile. Profile Identification: http://xml.resource.org/profiles/pdm Messages Exchanged during Channel Creation: SacredDownloadRequest, SacredDownloadResponse, error Messages starting one-to-one exchanges: SacredDownloadRequest, SacredUploadRequest Messages in positive replies: SacredDownloadResponse, SacredUploadResponse Messages in negative replies: error Messages in one-to-many changes: none Message Syntax: c.f.,Section 5 Farrell & al [Page 16] INTERNET-DRAFT June 2001 Message Semantics: c.f., Section 2 Contact Information: c.f., the AuthorsÆ Addresses section of this memo 6.1 Profile Initialization The SacredDownloadRequest and SacredDownloadResponse may be exchanged during channel initialization (c.f., Section 2.3.1.2 of [BEEP]), e.g., C: C: C: ]]> C: C: S: S: ]]> S: Note that BEEP imposes both encoding and length limitations on the messages that are piggybacked during channel initialization. 6.2 Profile Exchange All messages are exchanged as ôapplication/beep+xmlö (c.f., Section 6.4 of [BEEP]): Role MSG RPY ERR I SacredDownloadRequest SacredDownloadResponse error I SacredUploadRequest SacredUploadResponse error 7. IANA Considerations If the IANA approves this memo for standards-track publication, then the IANA registers the BEEP profile specified in Section 6, and selects an appropriate standards-track URI, e.g., http://iana.org/beep/pdm 8. Security Considerations <> Note that Section 2.3 requires that the BEEP session be tuned for privacy before the BEEP profile for PDM is started. Accordingly, implementations may wish to advertise only tuning profiles used for Farrell & al [Page 17] INTERNET-DRAFT June 2001 privacy in their initial greeting (c.f., Section 3 of [BEEP]), and then advertise the BEEP profile for PDM after a tuning restart. References [AES] AES home page: http://csrc.nist.gov/encryption/aes/ [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080. [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000. [REQS] Arsenault, A., Farrell, S., "Securely Available Credentials - Requirements" draft-ietf-sacred-reqs-02.txt - work-in-progress [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [XKMS] Hallam-Baker, P. et al, "XML Key Management Specification", http://www.w3.org/TR/XKMS [XMLDSIG] Eastlake, D., et al. "XML-Signature Syntax and Processing", RFC 2075. Acknowledgements <> Authors' Addresses Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8, IRELAND Phone: +353-1-881-6000 Email: stephen.farrell@baltimore.ie Radia Perlman Sun Microsystems Email: radia.perlman@sun.com Charlie Kaufman Iris Associates Email: ckaufman@iris.com Marshall T. Rose Invisible Worlds, Inc. 131 Stony Circle Suite 500 Santa Rose, CA 95401 US Phone: +1 707 578 2350 EMail: mrose@invisible.net Farrell & al [Page 18] INTERNET-DRAFT June 2001 URI: http://invisible.net/ Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 module presented in Appendix B may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix A: Schema Farrell & al [Page 19] INTERNET-DRAFT June 2001 Farrell & al [Page 20] INTERNET-DRAFT June 2001 Farrell & al [Page 21] INTERNET-DRAFT June 2001 Appendix B: DTD In cases of conflict, the schema in Appendix B above is to be followed. <> Farrell & al [Page 23] INTERNET-DRAFT June 2001 Appendix C: Open Issues There are various decisions we made which the working group might like to debate. (1) We can fix the size of the moduli at 512-bits. If the only attack on the protocol is to break 512-bit Diffie-Hellman for each guessed password, 512 is a secure size for this protocol. If it is desired to use larger moduli, in case someone finds some attack for which Diffie-Hellman can be simultaneously broken for multiple p's, then computation at the client for computing p will be excessive. For instance, on a 400-Mhz processor, we estimate 30 seconds to generate a 768-bit p, and 110 seconds to generate a 1024- bit key, whereas to generate a 512-bit key will take less than 10 seconds. If it is desired to use larger moduli, computation at the client can be made tolerable through allowing the user to type an additional character, a "hint". The hint character would be told to the user, and would be a function of the p resulting from that user's choice Farrell & al [Page 24] INTERNET-DRAFT June 2001 of password. Each time p is calculated from the password without the hint, the user is informed that in the future, calculation would proceed more quickly if the user additionally remembered and typed the extra character. (2) The hint is one of 64 characters (uppercase letters, lowercase letters, numbers, "+", or "=") which represents 6 bits. This enables the client machine, when computing p, to ignore all candidate p's that do not contain those 6 bits at a particular offset. The bottom 3 bits of p are constrained to be "011" because due to an obscure number theoretic theorem known as the quadratic reciprocity theorem, if p=3 mod 8, and p is a safe prime (also known as a Sophie-Germain prime), which is defined to be a prime p such that p and also (p- 1)/2 are prime, then 2 will be a generator. So since bits 0, 1, and 2 are constrained, we would suggest using bits 3-8 to represent the 64 possible values of the user hint. With a user-supplied hint, computing a 1024-bit prime takes under 2 seconds. Adding a user-supplied hint does not affect the on-the-wire protocol. It merely affects the user interface at the client. One possible user interface is for the user to supply a hint by typing the password, followed by space, followed by the hint character. This assumes that space would not be a legal character in a password. If there are no characters illegal in a password, then the client machine can prompt the user for the hint character, as in "password?", "hint (if known)?". (3) Should the RSA key used to validate uploads be usable for anything other than sacred, or should we allow it to be used for other purposes? Farrell & al [Page 25]