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
<draft-ietf-sacred-protocol-beep-pdm-00.txt>
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.
<<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
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.
<<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
name?>>
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
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.
<SacredDownloadQuery protocol="&sacred">
<HashedKeyID> =asedsd= </HashedKeyID>
<HashedCredSelector> =asdss= </HashedCredSelector>
<Verifier Id="&sacred#pdm">
=asdfasfs=
</Verifier>
</SacredQuery>
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">
=sfdsdfs=
</Verifier>
<ProtectedCredential Id="&sacred#aes">
=asdsdsds=
</ProtectedCredential>
</SacredResult>
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
<ProtectedCredential>.
Decryption (using K) of <ProtectedCredential> gives a
<SacredCrendential> element (Y).
<SacredCredential>
<KeyID> Alice </KeyID>
<CredentialSelector>email cred</CredentialSelector>
<LastModified> November 17th 1965 </LastModified>
<TimeToLive> 10000 </TimeToLive>
<UploadValidator scheme="&sacred#rsa-signing">
...
</UploadValidator>
Farrell & al [Page 10]
INTERNET-DRAFT June 2001
<EncryptedCredentialElements method="&sacred#aes>
<CipherData> =asdasds= </CipherData>
</EncryptedCredentialElements>
<ds:Signature> ... </ds:Signature>
</SacredCredential>
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>.
<PlainSacredCredential>
<Payload format="&sacred#pkcs-15">
=asdasds=
</Payload>
<UploadAuthenticator scheme="&sacred#rsa-signing">
...
</UploadAuthenticator>
</PlainSacredCredential>
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:
"sacred-2001-06-26"
<<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
apply:
<<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
mode
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
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
<<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
"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
<<Need to check that no errors help with on-line password guessing
and probably more information to help with server-server
resilience.>>
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:
<<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,
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: <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.,
http://iana.org/beep/pdm
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.
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
<<TBD.>>
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
<?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 ''>
] -->
<schema
targetNamespace="sacred-2001-06-26"
xmlns="http://www.w3.org/2000/10/XMLSchema"
xmlns:sacred="sacred-2001-06-26"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<!-- Message 1 -->
<element name="SacredDownloadRequest">
Farrell & al [Page 19]
INTERNET-DRAFT June 2001
<complexType>
<sequence>
<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"/>
</sequence>
<attribute name="protocol" type="ID" use="optional"/>
<attribute name="UploadToFollow"
type="boolean" use="optional"/>
</complexType>
</element>
<!-- Message 2 -->
<element name="SacredDownloadResponse">
<complexType>
<sequence>
<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"
type="sacred:TypedCryptoBinary"/>
<element name="UploadChallenge"
type="sacred:TypedCryptoBinary"
minOccurs="0" maxOccurs="1"/>
</sequence>
<attribute name="protocol" type="ID" use="optional"/>
</complexType>
</element>
<!-- Message 3 -->
<element name="SacredUploadRequest">
<complexType>
<sequence>
<element name="SequenceNumber" type="string"/>
<element name="UploadChallenge"
type="sacred:TypedCryptoBinary"/>
<element name="NewCredential" type="sacred:CipherDataType"/>
<element name="UploadVerifier" type="ds:Signature"/>
</sequence>
<attribute name="protocol" type="ID" use="optional"/>
</complexType>
</element>
<!-- Message 4 -->
<element name="SacredUploadResponse">
<complexType>
<sequence>
<element name="UploadAck" type="sacred:CipherDataType" />
</sequence>
Farrell & al [Page 20]
INTERNET-DRAFT June 2001
<attribute name="protocol" type="ID" use="optional"/>
</complexType>
</element>
<!-- A ds:CryptoBinary with a type -->
<!-- used where variants of sacred protocols are likely -->
<!-- to want replacability -->
<complexType name="TypedCryptoBinary">
<simpleContent>
<extension base="ds:CryptoBinary">
<attribute name="Id" type="ID" use="optional"/>
</extension>
</simpleContent>
</complexType>
<!-- 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">
<sequence>
<choice maxOccurs="1">
<element name="CipherData" type="ds:CryptoBinary"/>
<!-- Leaving room for XML encryption standard formats. -->
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
<attribute name="scheme" type="ID" use="optional"/>
</complexType>
<!-- Deciphered form of credential -->
<element name="SacredCredential">
<complexType>
<sequence>
<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"
type="sacred:CipherDataType"/>
<element name="Signature" type="ds:SignatureType"
minOccurs="0" maxOccurs="1"/>
</sequence>
</complexType>
</element>
<!-- Inner format of deciphered credential -->
<element name="PlainSacredCredential">
Farrell & al [Page 21]
INTERNET-DRAFT June 2001
<complexType>
<sequence>
<element name="Payload" type="ds:KeyInfoType"
minOccurs="0" maxOccurs="unbounded"/>
<element name="UploadAuthenticator">
<complexType>
<choice>
<element name="SignatureAuth"
type="sacred:RSAPrivateKeyType"/>
<any namespace="##other" processContents="lax"/>
</choice>
<attribute name="scheme" type="ID" use="required"/>
</complexType>
</element>
</sequence>
</complexType>
</element>
<complexType name="RSAPrivateKeyType">
<sequence>
<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'/>
</sequence>
</complexType>
</schema>
Appendix B: DTD
In cases of conflict, the schema in Appendix B above is to be
followed.
<<Note: This was generated (partly automatically)_from the above
schema and probably needs manual massaging as well as technical
work.>>
<?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?,
Verifier)>
<!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 KeyID (#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)>
<!ELEMENT P (#PCDATA)>
<!ELEMENT Q (#PCDATA)>
<!ELEMENT DP (#PCDATA)>
<!ELEMENT DQ (#PCDATA)>
<!ELEMENT QINV (#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
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]
