INTERNET-DRAFT Stephen Farrell
expires in six months Baltimore Technologies
Radia Perlman
Sun Microsystems
Charlie Kaufman
Iris Associates
October 2001
Securely Available Credentials Protocol
<draft-ietf-sacred-protocol-bss-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 an SRP-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. Message Formats..............................................5
4. BEEP Profile for Sacred......................................7
5. IANA Considerations.........................................10
6. Security Considerations.....................................10
References.....................................................11
Acknowledgements...............................................12
Authors' Addresses.............................................12
Full Copyright Statement.......................................12
Appendix A: XML Schema.........................................13
Appendix B: DTD................................................15
Appendix C: Changes & Open Issues..............................16
1. Introduction
<<Open issues/editorial notes are in brackets, like this.>>
We describe a protocol whereby a user can acquire cryptographic
credentials (e.g., private keys, PKCS#15 structures) from a
workstation which has locally trusted software installed, 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 security of the protocol is based on [SRP]. The protocol uses
[BEEP] as its transport layer and the [SASL] SRP mechanism [SASL-
SRP] to encapsulate the SRP exchanges. The payloads consist of a set
of XML messages defined here. The protocol sets out to meet the
requirements in [REQS].
We assume the only authentication information available to the user
is a username and 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 create or delete an account,
change her password and/or credentials and upload the new values to
the server. The protocol ensures that only someone that knew the old
Farrell & al [Page 2]
INTERNET-DRAFT June 2001
password is able to modify the credentials. The protocol does not
preclude configuring a server to disallow some operations (e.g.
credential upload) from some users.
2. The protocol
This section defines the operations for the sacred protocol.
2.1 Sacred operations
2.1.1 Information Request
This operation require no authentication.
The purpose of this operation is to provide to the client the values
required for account creation. The client sends an InfoRequest
message and the server responds with an InfoResponse message.
2.1.2 Create Account
This operation requires TLS server authentication.
The purpose of this operation is to setup a new account on the
server. A "new" account consists of the username and SRP password
verifier with no associated credentials. In order to associate a
credential with an account, the client MUST carry out the credential
upload operation, which requires SRP authentication.
The client sends a CreateAccountRequest and the server responds with
an error or acknowledgement message.
2.1.3 Remove Account
The client sends a RemoveAccountRequest message to the server. The
server MUST delete all information relating to the account and
respond with an error or acknowledgement message.
2.1.4 Password change
The client sends a PWChangeRequest message to the server. The server
changes the account's password verifier value and responds an error
or acknowledgement message.
<<In this version, the password can be changed independently of the
credential. If they're actually tied together (say the password is
also used for a 2nd encryption of the private key inside the
credential), then a client could synchronize changing the two by
doing two separate operations. However, if one of the operations
works, but the other doesn't then we've a problem. Possible answers
might be: (1) defined a change-pw-and-cred operation, (2) say that
such a client should try its own roll-back (by storing stuff until
the whole sequence of operations have succeeded) or (yuk!) (3)
Farrell & al [Page 3]
INTERNET-DRAFT June 2001
trying to have versioning and roll-back as part of the sacred
protocol.>>
2.1.5 Credential Upload
The client sends an UploadRequest message to the server. The server
responds with an error or acknowledgement message.
If a credential with the same credential selector field (a
"matching" credential) already exists for the account, then that
credential is replaced with the new credential from the
UploadRequest. If the new credential from the UploadRequest contains
no Payload field then the "matching" credential is deleted.
2.1.6 Credential Download
The client sends a DownloadRequest message to the server. The server
responds with a DownloadResponse message.
2.2 Session security
Six sacred operations are defined above. In this section we specify
the requirements for security for each of the operations. We first
define the options and then specify which options MUST be supported
for which operations.
- NONE means what it says - no authentication is required
- sTLS means that the BEEP session MUST be "tuned" for server-
authenticated TLS [TLS].
- cTLS means that the BEEP session MUST be "tuned" for mutually-
authenticated TLS.
- SRP means that the BEEP session MUST be "tuned" for SASL-SRP; MUST
use the SASL security layer with all three security services
(confidentiality, replay protection and integrity); MUST set the
authorization identity to the same value as the authentication
identity and MUST use the mandatory-to-implement algorithms from
[SASL-SRP].
<<"Tuned" is a piece of BEEP terminology that we should define here
(or reference a definition). It seems to mean "have security turned
on as part of the channel initialization or something like that.>>
The mandatory-to-implement TLS cipher-suite for sacred is:
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This MUST be used for both sTLS and
cTLS cases.
Where both SRP and cTLS security are supported for the same account,
the server MUST maintain some (secure) mapping between the SRP
authentication identity and the client certificate involved. How
this is done is out of scope.
<<Do we need to suggest a scheme, e.g. SRP id = CommonName as a
default mapping? Do clients need to know?>>
Farrell & al [Page 4]
INTERNET-DRAFT June 2001
Security required for each sacred operation:
Operation Security REQUIRED
--------- -----------------
Information request NONE
Create account sTLS
Remove account SRP or cTLS
Password change SRP or cTLS
Credential upload SRP or cTLS
Credential download SRP or cTLS
Where there is a choice (e.g. Remove account), servers MUST support
both options and clients MUST support at least one of the options.
2.3 Session management
Once the BEEP session is tuned, the client can issue one sacred
request. Once the response to this request has been sent the server
MUST drop the connection. If a client wishes to combine operations,
(e.g. download and then modify credentials), the client software MAY
temporarily store e.g. the password, but MUST re-authenticate each
time it connects to the server.
2.4 Handling multiple credentials for an account
When more than one credential is stored under a single account, the
client can select a single credential using the optional credential
selector string.
Servers SHOULD treat the first credential stored (time-wise) under
that user name as the default for the account.
It is an error to have more than one credential stored under the
same account where neither has a credential selector 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 credential selector string.
The upload protocol is not affected since the credential selector
string is an optional part of the credential in any case. In other
cases the credential selector string is an optional field in the
request.
3. Message Formats
This section describes the message formats used, which are based on
XML. Appendices A & B provide schema and DTD for these elements.
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.
Farrell & al [Page 5]
INTERNET-DRAFT June 2001
It is also intended that other sacred protocol instances (e.g. using
a different authentication scheme, credential format or transport
protocol) could re-use many of the definitions here.
3.1 Common fields
The type "ds:CryptoBinary" (inherited from [XMLDSIG]) is used for
almost 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. The exception to this is
the "salt" field, which is of type base64Binary instead. The reason
for this is that leading zeros are stripped from ds:CryptoBinary,
which is correct in most cases, but since the salt is a direct input
to a hash function, leading zeros are significant and so have to be
preserved.
All messages sent to the server MAY contain ProcessInfo values. This
field MAY be used by other specifications or for vendor extensions.
For example, a server might require clients to include a phone
number in this field. The information response message contains a
list of the types of ProcessInfo that the server supports. This
extensibility scheme is the same as that used in [XKMS] and [XBULK].
Where no specific response message is defined for an operation(e.g.
for PWChangeRequest) then the BEEP "ok" or "error" messages are used
to indicate success or failure.
3.2 Credential Format
A number of messages involve the Credential element. It has the
following fields (all optional fields may occur exactly zero or one
times unless otherwise stated):
- KeyID (optional) MAY contain a set of URIs by which the ds:KeyInfo
contained in the credential is known to XKMS services.
- CredentialSelector (optional) contains a string by which this
particular credential (for this account) can be identified.
- LastModified specifies the time at which this credential was last
changed. (Note: when a client includes this in an upload request,
the server MUST check that the value is reasonable.)
- TimeToLive (optional) is a hint which clients SHOULD honor, which
specifies the number of seconds for which the downloaded
credential is to be usable.
- ProcessInfo (optional) MAY contain any (typed) information that
the server is intended to process. If the server doesn't support
any of the ProcessInfo data, it MAY ignore that data.
- ClientInfo (optional) MAY contain any (typed) information that the
client is intended to process, but which the server MUST ignore.
If the client doesn't support any of the ClientInfo data, it MAY
ignore that data (e.g. if the ClientInfo is device specific).
Farrell & al [Page 6]
INTERNET-DRAFT June 2001
- CredentialElements contains either a ds:KeyInfo or some other form
of credential. Implementations MUST support the xbulk:pkcs-15 form
of ds:KeyInfo.
<<We need to say what's a "reasonable" LastModified value.>>
3.3 InfoRequest
There is no content to this message.
3.4 InfoResponse
Contains the SRP settings for the server and the list of supported
ProcessInfo types.
3.5 CreateAccountRequest
This message contains the account name (e.g. username), the salt and
the password verifier for the account.
3.6 RemoveAccountRequest
There is no content to this message.
3.7 PWChangeRequest
This message contains a new salt and password verifier for the
account.
3.8 DownloadRequest
This message MAY contain the credential selector string for the
credential.
3.9 DownloadResponse
This message contains the credential.
3.10 UploadRequest
The message contains the new credential.
4. BEEP Profile for Sacred
Future memos may define alternative versions of the BEEP profile for
sacred. 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.
The protocol described in this memo is realized as a [BEEP] profile.
Farrell & al [Page 7]
INTERNET-DRAFT June 2001
Profile Identification: http://iana.org/beep/transient/sacred/bss
This profile URI is consistent with [TRANS].
Messages Exchanged during Channel Creation:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
PWChangeRequest,
DownloadRequest,
UploadRequest,
InfoResponse,
DownloadResponse,
error,
ok
Messages starting one-to-one exchanges:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
PWChangeRequest,
DownloadRequest,
UploadRequest
Messages in positive replies:
ok,
InfoResponse,
DownloadResponse
Messages in negative replies: error
Messages in one-to-many changes: none
Message Syntax: c.f.,Section 3
Message Semantics: c.f., Section 2
Contact Information: c.f., the AuthorsÆ Addresses section of this
memo
4.1 Profile Initialization
There are two ways to perform privacy tuning on a BEEP session,
either:
- a transport security profile may be successfully started; or,
- a user authentication profile that supports transport security may
be successfully started.
Regardless, upon completion of the negotiation process, a tuning
reset occurs in which both BEEP peers issue a new greeting. Consult
Section 3 of [2] for an example of how a BEEP peer may choose to
issue different greetings based on whether privacy is in use.
Farrell & al [Page 8]
INTERNET-DRAFT June 2001
Any of the messages listed in section 4.2 below 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/sacred/bss'>
C: <![CDATA[<DownloadRequest ...>]]>
C: </profile>
C: </start>
S: <profile uri='http://xml.resource.org/profiles/sacred/bss'>
S: <![CDATA[<DownloadResponse ...>]]>
S: </profile>
Note that BEEP imposes both encoding and length limitations on the
messages that are piggybacked during channel initialization.
4.2 Profile Exchange
All messages are exchanged as "application/beep+xml" (c.f., Section
6.4 of [BEEP]):
Role MSG RPY ERR
---- --- --- ---
I InfoRequest InfoResponse error
I CreateAccountRequest ok error
I RemoveAccountRequest ok error
I PWChangeRequest ok error
I DownloadRequest DownloadResponse error
I UploadRequest ok error
4.3 Error handling
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 following BEEP error reply codes from [BEEP] are to be used:
code meaning
==== =======
421 service not available
450 requested action not taken (e.g., lock already in
use)
451 requested action aborted (e.g., local error in
processing)
454 temporary authentication failure
500 general syntax error (e.g., poorly-formed XML)
501 syntax error in parameters (e.g., non-valid XML)
504 parameter not implemented
530 authentication required
534 authentication mechanism insufficient (e.g., too
Farrell & al [Page 9]
INTERNET-DRAFT June 2001
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)
The following sacred-specific error reply codes can also be used:
<<This list is no doubt preliminary.>>
code meaning
==== =======
777 Extension (ProcessInfo) used not supported
778 Required extension (ProcessInfo) not present
5. 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/sacred/bss
6. Security Considerations
[REQS] calls for specifications to state how they address the
vulnerabilities listed below.
V1. A passive attacker can watch all packets on the network and
later carry out a dictionary attack.
- The use of SRP, cTLS or sTLS counters this vulnerability.
V2. An attacker can attempt to masquerade as a credential server
in an attempt to get a client to reveal information on line
that allows for a later dictionary attack.
- The use of SRP, cTLS or sTLS counters this vulnerability.
V3. An attacker can attempt to get a client to decrypt a chosen
"ciphertext" and get the client to make use of the resulting
plaintext - the attacker may then be able to carry out a
dictionary attack (e.g. if the plaintext resulting from
"decryption" of a random string is used as a DSA private
key).
- The use of SRP, cTLS or sTLS counters this vulnerability.
V4. An attacker could overwrite a repository entry so that when
a user subsequently uses what they think is a good
credential, they expose information about their password
(and hence the "real" credential).
- Server implementations SHOULD take measures to protect the
database. Client MAY use the ClientInfo field to store e.g.
a signature over the Credential, which they then verify
before using the private component.
Farrell & al [Page 10]
INTERNET-DRAFT June 2001
V5. An attacker can copy a credential server's repository and
carry out a dictionary attack.
- Server implementations SHOULD take measures to protect the
database.
V6. An attacker can attempt to masquerade as a client in an
attempt to get a server to reveal information that allows
for a later dictionary attack.
- The use of SRP or cTLS counters this.
V7. An attacker can persuade a server that a successful login
has occurred, even if it hasn't.
- Client authentication prevents this.
V8. (Upload) An attacker can overwrite someone else's
credentials on the server.
- Only if they know the password already (thanks to SRP and
cTLS).
V9. (When using password-based authentication) An attacker can
force a password change to a known (or "weak") password.
- Client authentication counters this.
V10. An attacker can attempt a man-in-the-middle attack for lots
of reasons...
- Mutual authentication plus the encryption of subsequent
messages prevents this.
V11. User enters password instead of name.
- The SASL-SRP scheme <<hopefully>> hashes the user id and
makes it very hard for an attacker to detect this happening.
V12. An attacker could attempt various denial-of-service attacks.
- No specific countermeasures against DoS are proposed.
<<Should analyse the protocol though.>>
If the CreateAccountRequest message were sent over a cleartext
channel (or otherwise exposed) then an attacker could mount a
dictionary attack and recover the password. This is why the server
authenticated TLS transport is REQUIRED for this operation.
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.
<<More to be added too no doubt.>>
References
[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.
Farrell & al [Page 11]
INTERNET-DRAFT June 2001
[REQS] Arsenault, A., Farrell, S., "Securely Available
Credentials - Requirements", RFC 3157.
[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.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222.
[SASL-SRP] Burdis, K.R. & Naffah, R., "Secure Remote Password SASL
Mechanism", draft-burdis-cat-srp-sasl-04, work-in-
progress <<expired, but authors will update "soon">>
[SRP] Wu, T., "The SRP Authentication and Key Exchange
System", RFC 2945.
[TLS] Dierks, T., "The TLS Protocol - Version 1.0", RFC 2246.
[TRANS] Rose, M., "A Transient Prefix for Identifying Profiles
under Development by the Working Groups of the IETF",
draft-mrose-beep-transientid-01, work-in-progress
[XKMS] Hallam-Baker, P. et al, "XML Key Management
Specification", http://www.w3.org/TR/XKMS, work-in-
progress
[XBULK] Farrell, S. et al, "XML Key Management Specification -
Bulk Operation", http://www.baltimore.com/devzone/x-
bulk/index.html, work-in-progress
[XMLDSIG] Eastlake, D., et al. "XML-Signature Syntax and
Processing", RFC 2075.
Acknowledgements
Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work
adapting an earlier draft to the use of SRP. Marshall Rose helped
out with the BEEP profile.
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
Full Copyright Statement
Farrell & al [Page 12]
INTERNET-DRAFT June 2001
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: XML Schema
<?xml version="1.0"?>
<!--DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
"XMLSchema.dtd" [
<!ATTLIST schema
xmlns:sacred CDATA #FIXED "sacred-2001-10-24"
>
<!ENTITY sacred 'sacred-2001-10-24''>
<!ENTITY % p ''>
<!ENTITY % s ''>
] -->
<schema targetNamespace="sacred-2001-10-24"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xbulk="http://www.xmltrustcenter.org/xkms/docs/x-bulk-2001-
07-04.xsd"
xmlns:sacred="sacred-2001-10-24"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<!-- general account handling -->
<!-- Information request -->
<element name="InfoRequest"/>
Farrell & al [Page 13]
INTERNET-DRAFT June 2001
<element name="InfoResponse">
<complexType>
<sequence>
<element name="ServerId" type="string"/>
<!-- SRP stuff -->
<element name="N" type="ds:CryptoBinary"/>
<element name="g" type="ds:CryptoBinary"/>
<element name="HashAlg" type="uriReference"/>
<element ref="xbulk:ProcessInfo" minOccurs="0" />
</sequence>
</complexType>
</element>
<!-- Create Account Request -->
<element name="CreateAccountRequest">
<complexType>
<sequence>
<element name="UserId" type="string"/>
<element name="salt" type="base64Binary"/>
<element name="PasswordVerifier" type="ds:CryptoBinary"/>
<element ref="xbulk:ProcessInfo" minOccurs="0" />
</sequence>
</complexType>
</element>
<!-- reomve account request -->
<element name="RemoveAccountRequest">
<complexType>
<sequence>
<element ref="xbulk:ProcessInfo" minOccurs="0" />
</sequence>
</complexType>
</element>
<!-- password change request -->
<element name="PWChangeRequest">
<complexType>
<sequence>
<element name="salt" type="base64Binary"/>
<element name="PasswordVerifier" type="ds:CryptoBinary"/>
<element ref="xbulk:ProcessInfo" minOccurs="0" />
</sequence>
</complexType>
</element>
<!-- credential specific operations -->
<!-- DownLoad Request -->
<element name="DownloadRequest">
<complexType>
<sequence>
Farrell & al [Page 14]
INTERNET-DRAFT June 2001
<element name="CredSel" type="string" minOccurs="0"/>
<element ref="xbulk:ProcessInfo" minOccurs="0" />
</sequence>
</complexType>
</element>
<!-- Download Response -->
<element name="DownloadResponse">
<complexType>
<sequence>
<element name="Credential" type="sacred:CredentialType"/>
</sequence>
</complexType>
</element>
<!-- Upload request -->
<element name="UploadRequest">
<complexType>
<sequence>
<element name="NewCredential"
type="sacred:CredentialType"/>
<element ref="xbulk:ProcessInfo" minOccurs="0" />
</sequence>
</complexType>
</element>
<!-- A new ds:KeyInfo thing -->
<element name="SacredPKCS15" type="ds:CryptoBinary"/>
<!-- credential -->
<complexType name="CredentialType">
<sequence>
<element name="KeyID" type="uriReference" minOccurs="0"/>
<element name="CredentialSelector"
type="string" minOccurs="0"/>
<element name="LastModified" type="timeInstant"/>
<element name="TimeToLive" type="string" minOccurs="0"/>
<element ref="xbulk:ProcessInfo" minOccurs="0"/>
<element ref="xbulk:ClientInfo" minOccurs="0"/>
<element name="Payload" type="ds:KeyInfoType"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
</complexType>
</schema>
Appendix B: DTD
<<This is semi-automatically generated from the schema above and is
probably therefore inaccurate.>>
Farrell & al [Page 15]
INTERNET-DRAFT June 2001
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT ClientInfo ()+>
<!ELEMENT ProcessInfo ()*>
<!ELEMENT CreateAccountRequest (UserId, salt, PasswordVerifier,
ProcessInfo?)>
<!ELEMENT DownloadRequest (CredSel?, ProcessInfo?)>
<!ELEMENT DownloadResponse (Credential)>
<!ELEMENT InfoRequest (#PCDATA)>
<!ELEMENT InfoResponse (ServerId, N, g, HashAlg, ProcessInfo?)>
<!ELEMENT PWChangeRequest (salt, PasswordVerifier, ProcessInfo?)>
<!ELEMENT RemoveAccountRequest (ProcessInfo?)>
<!ELEMENT SacredPKCS15 (#PCDATA)>
<!ELEMENT UploadRequest (NewCredential, ProcessInfo?)>
<!ELEMENT UserId (#PCDATA)>
<!ELEMENT salt (#PCDATA)>
<!ELEMENT PasswordVerifier (#PCDATA)>
<!ELEMENT CredSel (#PCDATA)>
<!ELEMENT Credential (KeyID?, CredentialSelector?, LastModified,
TimeToLive?, ProcessInfo?, ClientInfo?, Payload*)>
<!ELEMENT ServerId (#PCDATA)>
<!ELEMENT N (#PCDATA)>
<!ELEMENT g (#PCDATA)>
<!ELEMENT HashAlg (#PCDATA)>
<!ELEMENT NewCredential (KeyID?, CredentialSelector?, LastModified,
TimeToLive?, ProcessInfo?, ClientInfo?, Payload*)>
<!ELEMENT CredentialSelector (#PCDATA)>
<!ELEMENT LastModified (#PCDATA)>
<!ELEMENT TimeToLive (#PCDATA)>
<!ELEMENT Payload (SacredPKCS15 )+>
<!ATTLIST Payload
Id ID #IMPLIED
>
Appendix C: Changes & Open Issues
-00: This version is adapted from draft-ietf-sacred-protocol-beep-
pdm-00.txt, the main changes are:
- PDM -> SRP &/or TLS
- Payload security -> SASL or TLS
- Dropped username hashing
- Dropped away-from-home
Open Issues:
- Should the protocol support administrative operations? In
particular the ability for an administrator to authenticate and
Farrell & al [Page 16]
INTERNET-DRAFT June 2001
then create accounts, upload credentials etc. which was part of
the PDM draft?
- Should we tie password changes with credential changes somehow?
(See the note in section 2.1.4)
- Need to define "tuned" (section 2.2)
- We probably need to determine a mapping from SASL-SRP id to cTLS
certificate (section 2.2)
- Need to define "reasonable" for LastModified (section 3.2)
- Need to check correctness of BEEP profile (section 4, various
bits)
- Need to figure whether SASP-SRP will support hashed userids
(section 6)
- Need to check whether we're creating some bad DoS vulnerabilities
(section 6)
- Need to add more security considerations as they arise (section
6).
- Probably need to fix DTD (Appendix B).
Farrell & al [Page 17]
