[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at


   This document describes a PDM-based protocol for securely available

   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
   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
   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

   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

   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",
     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
     - (Optionally) A time-to-live value specifying the number of
        seconds for which the credential SHOULD be usable following
     - 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.

   <<Note: the extent to which the "upload" private key is usable for
   "other" purposes should be discussed on the list.>>

   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

   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

   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.

   <<Note1: how to handle the proxying functionality is still tbd.>>

   <<Note2: is it ok to use X=h("Alice","Target",pwd) in this case?
   That is, is there any vulnerability if X doesn't include the realm

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.

   <<Upload processing TBD.>>

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.

   <<Upload processing TBD.>>

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

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.

   <SacredDownloadQuery protocol="&sacred">
        <HashedKeyID> =asedsd= </HashedKeyID>
        <HashedCredSelector> =asdss= </HashedCredSelector>
        <Verifier Id="&sacred#pdm">

   In this example h("Alice") is <HashedKeyID>, h("user string") is
   <HashedCredSelector> and <Verifier> contains 2^A mod p.

   <SacredDownloadResponse protocol="&sacred" >
        <HashedKeyID> =asedsd= </HashedKeyID>
        <HashedCredSelector> =asdss= </HashedCredSelector>
        <Verifier Id="&sacred#pdm">
        <ProtectedCredential Id="&sacred#aes">

   Here, 2^B mod p is in <Verifier>, 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 <ProtectedCredential> gives a
   <SacredCrendential> element (Y).

        <KeyID> Alice </KeyID>
        <CredentialSelector>email cred</CredentialSelector>
        <LastModified> November 17th 1965 </LastModified>
        <TimeToLive> 10000 </TimeToLive>
        <UploadValidator scheme="&sacred#rsa-signing">

Farrell & al                                                 [Page 10]

INTERNET-DRAFT                                               June 2001

        <EncryptedCredentialElements method="&sacred#aes>
               <CipherData> =asdasds= </CipherData>
        <ds:Signature> ... </ds:Signature>

   In the above, the time the credentials were last modified is in
   <LastModified>, the number of seconds for which this credential
   should be used is in <TimeToLive> and the user string is in
   <CredentialSelector>. The RSA public key (pub) is in the
   <UploadVerifier> element and the encrypted parts of Y are in the
   <CipherData>. Finally, a <Signature> element contains a HMAC value
   for Y, using the user's password as a key.

   Decryption (using the user's password) of
   <EncryptedCredentialElements> gives a <PlainSacredCredential>.

        <Payload format="&sacred#pkcs-15">
        <UploadAuthenticator scheme="&sacred#rsa-signing">

   In the above the PKCS#15 payload is in a <Payload> element and the
   RSA private key used for authenticating credential uploads is in the
   <UploadAuthenticator> 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:


   <<Note: this *will* be replaced with a real value at some point.>>

   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

   <<Have to cut&paste from XMLENC unless they finish first or else use
   PKCS#1, CMS or equivalent. Haven't checked XLMENC just yet so
   probably some inaccuracies here for now.>>

   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
   6.The result of encryption is base64 encoded in placed into the
     appropriate element according to the schema below

   <<Need some more details on key derivation from PWD later.>>

   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
   "&sacred#rsa-siging"denotes the RSA based credential upload
                       authentication scheme
   "&sacred#pkcs-15"   labels a payload as containing a PKCS#15

5.3 Message 1

   <<Fragments of the schema will be copied to these sections in
   future. Refer to appendix A for this version.>>

   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

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

   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

   <<Need to check that no errors help with on-line password guessing
   and probably more information to help with server-server

   With the exception of the cases below, the ôerrorö message from
   Section 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:

   <<Note: its not clear if all these are needed, nor whether new codes
   are required. This set is copied straight from [BEEP].>>

      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,

   Messages in positive replies: SacredDownloadResponse,

   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

6.1 Profile Initialization

   The SacredDownloadRequest and SacredDownloadResponse may be
   exchanged during channel initialization (c.f., Section of
   [BEEP]), e.g.,

        C: <start number='1'>
        C:     <profile uri='http://xml.resource.org/profiles/pdm'>
        C:             <![CDATA[<SacredDownloadRequest ...>]]>
        C:     </profile>
        C: </start>

        S: <profile uri='http://xml.resource.org/profiles/pdm'>
        S:     <![CDATA[<SacredDownloadResponse ...>]]>
        S: </profile>

   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.,


8. Security Considerations

   <<lots tbd incl. add in vulnerabilty stuff w.r.t reqs.>>

   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.


   [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.



Authors' Addresses

   Stephen Farrell,
   Baltimore Technologies,
   39 Parkgate Street,
   Dublin 8,
   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
   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

   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

Appendix A: Schema

   <?xml version="1.0"?>
   <!--DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
   "XMLSchema.dtd" [
    <!ATTLIST schema
    xmlns:sacred CDATA #FIXED "sacred-2001-06-26"
    <!ENTITY sacred 'sacred-2001-06-26'>
    <!ENTITY % p ''>
    <!ENTITY % s ''>
   ] -->

    <!-- Message 1 -->
    <element name="SacredDownloadRequest">

Farrell & al                                                 [Page 19]

INTERNET-DRAFT                                               June 2001

          <element name="HashedName" type="ds:CryptoBinary"/>
          <element name="Realm" type="string"
            minOccurs="0" maxOccurs="1">
          <element name="HashedCredSel" type="ds:CryptoBinary"
            minOccurs="0" maxOccurs="1"/>
          <element name="Verifier" type="sacred:TypedCryptoBinary"/>
        <attribute name="protocol" type="ID" use="optional"/>
        <attribute name="UploadToFollow"
            type="boolean" use="optional"/>

    <!-- Message 2 -->
    <element name="SacredDownloadResponse">
          <element name="HashedName" type="ds:CryptoBinary"/>
          <element name="HashedCredSel" type="ds:CryptoBinary"
            minOccurs="0" maxOccurs="1"/>
          <element name="Verifier" type="sacred:TypedCryptoBinary"/>
          <element name="ProtectedCredential"
          <element name="UploadChallenge"
            minOccurs="0" maxOccurs="1"/>
        <attribute name="protocol" type="ID" use="optional"/>

    <!-- Message 3 -->
    <element name="SacredUploadRequest">
          <element name="SequenceNumber" type="string"/>
          <element name="UploadChallenge"
          <element name="NewCredential" type="sacred:CipherDataType"/>
          <element name="UploadVerifier" type="ds:Signature"/>
        <attribute name="protocol" type="ID" use="optional"/>

    <!-- Message 4 -->
    <element name="SacredUploadResponse">
          <element name="UploadAck" type="sacred:CipherDataType" />

Farrell & al                                                 [Page 20]

INTERNET-DRAFT                                               June 2001

        <attribute name="protocol" type="ID" use="optional"/>

    <!-- A ds:CryptoBinary with a type -->
    <!-- used where variants of sacred protocols are likely -->
    <!-- to want replacability -->
    <complexType name="TypedCryptoBinary">
        <extension base="ds:CryptoBinary">
          <attribute name="Id" type="ID" use="optional"/>

    <!-- Some new ds:KeyInfo things -->
    <element name="SacredPKCS15" type="ds:CryptoBinary"/>
    <element name="ProtectedCredential" type="sacred:CipherDataType"/>

    <!-- Short term alternative for XML encrypytion standard -->
    <!-- CipherData -->
    <complexType name="CipherDataType">
        <choice maxOccurs="1">
          <element name="CipherData" type="ds:CryptoBinary"/>
          <!-- Leaving room for XML encryption standard formats. -->
          <any namespace="##other" processContents="lax"/>
      <attribute name="scheme" type="ID" use="optional"/>

    <!-- Deciphered form of credential -->
    <element name="SacredCredential">
          <element name="KeyID" type="uriReference"/>
          <element name="CredentialSelector" type="string"
             minOccurs="0" maxOccurs="1"/>
          <element name="LastModified" type="timeInstant"/>
          <element name="TimeToLive" type="string"
             minOccurs="0" maxOccurs="1"/>
          <element name="UploadValidator" type="ds:KeyInfoType"/>
          <element name="EncryptedCredentialElements"
          <element name="Signature" type="ds:SignatureType"
             minOccurs="0" maxOccurs="1"/>

    <!-- Inner format of deciphered credential -->
    <element name="PlainSacredCredential">

Farrell & al                                                 [Page 21]

INTERNET-DRAFT                                               June 2001

          <element name="Payload" type="ds:KeyInfoType"
              minOccurs="0" maxOccurs="unbounded"/>
          <element name="UploadAuthenticator">
                <element name="SignatureAuth"
                <any namespace="##other" processContents="lax"/>
              <attribute name="scheme" type="ID" use="required"/>

    <complexType name="RSAPrivateKeyType">
           <element name='PrivateExponent' type='ds:CryptoBinary'
               minOccurs='1' maxOccurs='1'/>
           <element name='P' type='ds:CryptoBinary'
               minOccurs='0' maxOccurs='1'/>
           <element name='Q' type='ds:CryptoBinary'
               minOccurs='0' maxOccurs='1'/>
           <element name='DP' type='ds:CryptoBinary'
               minOccurs='0' maxOccurs='1'/>
           <element name='DQ' type='ds:CryptoBinary'
               minOccurs='0' maxOccurs='1'/>
           <element name='QINV' type='ds:CryptoBinary'
               minOccurs='0' maxOccurs='1'/>


Appendix B: DTD

   In cases of conflict, the schema in Appendix B above is to be

   <<Note: This was generated (partly automatically)_from the above
   schema and probably needs manual massaging as well as technical

   <?xml version="1.0" encoding="UTF-8"?>
   <!ELEMENT PlainSacredCredential (Payload*, UploadAuthenticator)>
   <!ELEMENT ProtectedCredential ((CipherData | ))>
   <!ATTLIST ProtectedCredential
        scheme ID #IMPLIED

Farrell & al                                                 [Page 22]

INTERNET-DRAFT                                               June 2001

   <!ELEMENT SacredCredential (KeyID, CredentialSelector?,
   LastModified, TimeToLive?, UploadValidator,
   EncryptedCredentialElements, Signature?)>
   <!ELEMENT SacredDownloadRequest (HashedName, Realm?, HashedCredSel?,
   <!ATTLIST SacredDownloadRequest
        protocol ID #IMPLIED
        UploadToFollow CDATA #IMPLIED
   <!ELEMENT SacredDownloadResponse (HashedName, HashedCredSel?,
   Verifier, ProtectedCredential, UploadChallenge?)>
   <!ATTLIST SacredDownloadResponse
        protocol ID #IMPLIED
   <!ELEMENT SacredPKCS15 (#PCDATA)>
   <!ELEMENT SacredUploadRequest (SequenceNumber, UploadChallenge,
   NewCredential, Signature)>
   <!ATTLIST SacredUploadRequest
        protocol ID #IMPLIED
   <!ELEMENT SacredUploadResponse (UploadAck)>
   <!ATTLIST SacredUploadResponse
        protocol ID #IMPLIED
   <!ELEMENT UploadAuthenticator (SignatureAuth | )>
   <!ATTLIST UploadAuthenticator
        scheme ID #REQUIRED
   <!ELEMENT CipherData (#PCDATA)>
   <!ELEMENT CredentialSelector (#PCDATA)>
   <!ELEMENT LastModified (#PCDATA)>
   <!ELEMENT TimeToLive (#PCDATA)>
   <!ELEMENT UploadValidator (KeyName | KeyValue | RetrievalMethod |
   X509Data | PGPData | SPKIData | MgmtData | )+>
   <!ATTLIST UploadValidator
        Id ID #IMPLIED
   <!ELEMENT EncryptedCredentialElements ((CipherData | ))>
   <!ATTLIST EncryptedCredentialElements
        scheme ID #IMPLIED
   <!ELEMENT HashedName (#PCDATA)>
   <!ELEMENT Realm (#PCDATA)>
   <!ELEMENT HashedCredSel (#PCDATA)>
   <!ELEMENT Verifier (#PCDATA)>
   <!ATTLIST Verifier
        Id ID #IMPLIED
   <!ELEMENT HashedName (#PCDATA)>
   <!ELEMENT HashedCredSel (#PCDATA)>
   <!ELEMENT Verifier (#PCDATA)>

Farrell & al                                                 [Page 23]

INTERNET-DRAFT                                               June 2001

   <!ATTLIST Verifier
        Id ID #IMPLIED
   <!ELEMENT ProtectedCredential (#PCDATA)>
   <!ATTLIST ProtectedCredential
        Id ID #IMPLIED
   <!ELEMENT UploadChallenge (#PCDATA)>
   <!ATTLIST UploadChallenge
        Id ID #IMPLIED
   <!ELEMENT SequenceNumber (#PCDATA)>
   <!ELEMENT UploadChallenge (#PCDATA)>
   <!ATTLIST UploadChallenge
        Id ID #IMPLIED
   <!ELEMENT NewCredential ((CipherData | ))>
   <!ATTLIST NewCredential
        scheme ID #IMPLIED
   <!ELEMENT UploadAck ((CipherData | ))>
   <!ATTLIST UploadAck
        scheme ID #IMPLIED
   <!ELEMENT SignatureAuth (PrivateExponent, P?, Q?, DP?, DQ?, QINV?)>
   <!ELEMENT PrivateExponent (#PCDATA)>

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

   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

   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]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/