INTERNET-DRAFT Editor: Stephen Farrell
expires in six months Baltimore Technologies
February 2002
Securely Available Credentials Protocol
<draft-ietf-sacred-protocol-bss-02.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).
Table Of Contents
Status of this Memo.............................................1
Abstract........................................................1
Table Of Contents...............................................1
1. Introduction.................................................2
2. The protocol.................................................3
3. BEEP Profile for SACRED......................................7
4. IANA Considerations.........................................10
5. Security Considerations.....................................10
References.....................................................12
Acknowledgements...............................................13
Editor's Address...............................................13
Full Copyright Statement.......................................13
Appendix A: XML Schema.........................................14
Appendix B: DTD................................................17
Appendix C: An Example of Tuning with BEEP.....................18
Appendix D: Provision SACRED using other Protocols.............19
Appendix E: Changes & Open Issues..............................19
Editor: Farrell [Page 1]
INTERNET-DRAFT February 2002
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 protocol uses [BEEP] for its exchange model with payloads
consisting of the XML messages defined in this specification. The
protocol sets out to meet the requirements in [REQS]. In particular,
security requirements in [REQS] are met by mandating support for TLS
[TLS] and/or SRP [SASL-SRP].
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 account password and/or credentials and upload the new
values to the server. The protocol ensures that only someone that
knew the old account password is able to modify the credentials as
stored on the credential server. The protocol does not preclude
configuring a server to disallow some operations (e.g. credential
upload) for some users. The account management operations as a whole
are OPTIONAL to implement for both credential servers and clients.
Note that there are potentially two "passwords" involved when using
this protocol - the first used to authenticate the user to the
credential server, and the second to decrypt (parts of) the
credential following a download operation. Where the context
requires it, we refer to the former as the account password and the
latter as the credential password.
Editor: Farrell [Page 2]
INTERNET-DRAFT February 2002
2. The protocol
This section defines the account management and "run-time"
operations for the SACRED protocol.
It also 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.
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.
2.1 Account management operations
These operations MAY be implemented, that is, they are OPTIONAL.
2.1.1 Information Request
This operation REQUIRES 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 (which has no content).
The server responds with an InfoResponse message which contains the
authentication mechanism parameters for the server and the list of
supported ProcessInfo types.
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. The information required for a "new" account will depend on
the SASL mechanism used. For [SRP], it consists simply of the
username and SRP password verifier.
The client sends a CreateAccountRequest which contains the account
name (e.g. username). It also contains the elements required to
create an account for a particular authentication mechanism. The
actual information is defined according to the authentication
mechanism. For SASL-SRP this consists of the salt and password
verifier.
The server responds with an error or acknowledgement message.
Editor: Farrell [Page 3]
INTERNET-DRAFT February 2002
2.1.3 Remove Account
This operation REQUIRES one of SRP or TLS mutual authentication.
The purpose of this operation is to delete the entire account.
The client sends a RemoveAccountRequest message (which has no
content) to the server.
The server MUST delete all information relating to the account and
respond with an error or acknowledgement message.
2.1.4 Modify Account
This operation REQUIRES one of SRP or TLS mutual authentication.
The purpose of this operation is to allow the client to change the
information required for authentication. The information required
will depend on the authentication method used. For [SRP] it will
consist of a salt and a password verifier value. Once the account
information has been changed, the server will respond with an error
or acknowledgement message.
The client sends a ModifyAccountRequest message which cntains the
elements required to change the authentication information for the
account, for a particular authentication mechanism. The actual
information is defined according to the authentication mechanism.
For SASL-SRP this consists of the salt and password verifier.
The server responds with an error or acknowledgement message.
2.2 "Run-time" operations
These operations MUST be supported by all conformant
implementations.
2.2.1 Credential Upload
This operation REQUIRES one of SRP or TLS mutual authentication.
The purpose of this operation is to allow the client to deposit a
credential with the server, or to delete one or more credentials
associated with the account.
The client sends an UploadRequest message to the server which can
contain zero or one Credential. If the UploadRequest contains no
Credential then the all the credentials associated with that account
are deleted.
If a credential with the same credential selector field as in the
UploadRequest, (a "matching" credential), already exists for the
account, then that credential is replaced with the new credential
Editor: Farrell [Page 4]
INTERNET-DRAFT February 2002
from the UploadRequest. Otherwise a "new" credential is associated
with that account.
If the new credential from the UploadRequest contains no PayLoad
field then the (one and only) "matching" credential is deleted.
If no "matching" credential exists, the server returns an error.
If any change is made to the stored credentials associated with the
account then the server MUST update the LastModified value (returned
in DownloadResponse messages) to the current time (at the server).
The LastModified value can also be of use in detecting conflicts.
For example, download to platform A, download to platform B, update
from B, update from A. The server could detect a conflict on the
second upload.
The server responds with an error or acknowledgement message.
2.2.2 Credential Download
This operation REQUIRES one of SRP or TLS mutual authentication.
The purpose of this operation is to allow a client to get one or
more credentials from a server (the purpose of the entire protocol
really!).
The client sends a DownloadRequest message to the server which MAY
contain a credential selector string for the credential. No, or an
enmpty, credential selector means the request is for all credentials
associated with the account.
The server responds with a DownloadResponse or an error message. A
DownloadResponse contains one or more credential payloads plus the
LastModified time which represents the time (at the server) when the
last change was made to the set of credentials associated with the
account (e.g. via an UploadRequest).
2.3 Miscellaneous
2.3.1 Session security
Six SACRED operations are defined above. In this section we specify
the requirements for security for each of the operations (where
supported).
Operation Security REQUIRED
--------- -----------------
Information request NONE
Create account Server authentication,
Privacy, Integrity
Remove account Mutual authentication,
Privacy, Integrity
Editor: Farrell [Page 5]
INTERNET-DRAFT February 2002
Modify account Mutual authentication,
Privacy, Integrity
Credential upload Mutual authentication,
Privacy, Integrity
Credential download Mutual authentication,
Privacy, Integrity
The security requirements can be met by several mechanisms. This
document REQUIRES credential servers to support TLS and SASL-SRP.
Clients MUST support SASL-SRP or TLS.
The mandatory-to-implement TLS cipher suite for SACRED is
TLS_RSA_WITH_3DES-EDE_CBC_SHA.
For SASL-SRP, all three security services (privacy, replay
protection, and integrity) MUST be used.
2.3.2 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.
There is no concept of a "default credential" - all credentials MUST
have an associated selector unique for that account. The selector
is REQUIRED for upload requests and OPTIONAL for download requests.
If the selector is omitted in a download request it MUST be
interpreted as a request for all the stored credentials.
An empty selector string value (i.e. "") in a credential download
request, is to be interpreted as if the selector string were
omitted, i.e. a download request containing this is a request for
all credentials.
It is an error to have more than one credential stored under the
same account where both have the same credential selector string.
2.3.3 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
Editor: Farrell [Page 6]
INTERNET-DRAFT February 2002
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 UploadRequest) then the transport will indicate success or
failure.
All of the response messages defined here MAY contain a Status
string, containing a value intended for human consumption.
2.3.4 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):
- CredentialSelector contains a string by which this particular
credential (for this account) can be identified.
- PayLoad contains either a ds:KeyInfo or some other form of
credential. Implementations MUST support the pkcs#15 form of
ds:KeyInfo defined below (the SacredPKCS15 element).
- 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).
3. BEEP Profile for SACRED
The protocol described in this memo is realized as a [BEEP] profile.
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, the latter
specifies which profile it is starting.
Profile Identification: http://iana.org/beep/transient/sacred/bss
This profile URI is consistent with [TRANS].
Messages Exchanged during Channel Creation:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
ModifyAccountRequest,
DownloadRequest,
Editor: Farrell [Page 7]
INTERNET-DRAFT February 2002
UploadRequest,
InfoResponse,
DownloadResponse,
error,
ok
Messages starting one-to-one exchanges:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
ModifyAccountRequest,
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 editor's address section of this memo
3.1 Profile Initialization
Because all but one of the operations of the SACRED profile have
security requirements (cf., Section 2.3.1), before starting the
SACRED profile, the BEEP session will likely be tuned using either
http://iana.org/beep/TLS
or
http://iana.org/SASL/SRP
(Appendix C gives an example of tuning a BEEP session using SRP).
Regardless, upon completion of the negotiation process, a tuning
reset occurs in which both BEEP peers issue a new greeting. Consult
Section 3 of [BEEP] for an example of how a BEEP peer may choose to
issue different greetings based on whether privacy is in use.
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://iana.org/beep/transient/sacred/bss'>
C: <![CDATA[<DownloadRequest ...>]]>
Editor: Farrell [Page 8]
INTERNET-DRAFT February 2002
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/transient/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.
3.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 ModifyAccountRequest ok error
I DownloadRequest DownloadResponse error
I UploadRequest ok error
3.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
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)
Editor: Farrell [Page 9]
INTERNET-DRAFT February 2002
The following SACRED-specific error reply codes can also be used:
code meaning
==== =======
555 Extension (ProcessInfo) used not supported
556 Required extension (ProcessInfo) not present
4. IANA Considerations
If the IANA approves this memo for standards-track publication, then
the IANA registers the BEEP profile specified in Section 4, and
selects an appropriate standards-track URI, e.g.,
http://iana.org/beep/sacred/bss
<<Q: should we apply for a port number? [yes]>>
5. 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 or TLS 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 server or mutual authentication 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 server or mutual authentication 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. Clients MAY use the ClientInfo field to store e.g.
a signature over the Credential, which they then verify
before using the private component.
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
Editor: Farrell [Page 10]
INTERNET-DRAFT February 2002
for a later dictionary attack.
- The use of the SRP strong password algorithm counters this
to a great extent. Additionally, credential servers MAY
choose to provide mechanisms that protect against online
dictionary attacks against user account passwords, either by
repeated access attempts to a single user account (varying
the password) or by attempting to access many user accounts
using the same password.
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 account password already (thanks to
mutual authentication).
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 allows clients and server to use a
hash of the user id, which would make it very hard for an
attacker to detect this happening. However, using this
technique damages interoperability since all clients dealing
with the credential in question MUST know in advance that
the extra hashing step is to be used. If a client uses this
technique, then it SHOULD use the SHA-1 algorithm and base64
encode the output. Servers MUST be able to handle usernames
which are formed in this manner (essentially servers MUST be
able to support random-looking 28 byte usernames).
V12. An attacker could attempt various denial-of-service attacks.
- No specific countermeasures against DoS are proposed.
If the CreateAccountRequest message were sent over a cleartext
channel (or otherwise exposed) then an attacker could mount a
dictionary attack and recover the account 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 account password can also upload new credentials, assuming
the user is authorized to modify the credentials, because someone
who knows the user's account password is assumed to be the user.
However, if someone steals the server database and is unsuccessful
at obtaining the user's account password through a dictionary
attack, they will be unable to upload new credentials.
Credential servers SHOULD incorporate measures that act to counter
denial of service attacks. In particular, they SHOULD drop inactive
Editor: Farrell [Page 11]
INTERNET-DRAFT February 2002
connections and minimize the use of resources by un-authenticated
connections. A number of recommendations are listed at [DDOS].
<<Anyone got a nicer/better reference?>>
References
Normative:
[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", 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-06,
January 2002, work-in-progress
[SRP] Wu, T., "The SRP Authentication and Key Exchange
System", RFC 2945.
[TLS] Dierks, T., "The TLS Protocol - Version 1.0", RFC
2246.
[XMLDSIG] Eastlake, D., et al. "XML-Signature Syntax and
Processing", RFC 3075
Informative:
[DDOS] "Recommendations for the Protection against
Distributed Denial-of-Service Attacks in the
Internet",
http://www.iwar.org.uk/comsec/resources/dos/ddos_en.
htm
[TRANS] Rose, M., "A Transient Prefix for Identifying
Profiles under Development by the Working Groups of
the IETF", draft-mrose-beep-transientid-01,
September 2001, work-in-progress
[XKMS] Hallam-Baker, P. (ed), "XML Key Management
Specification",
http://www.w3.org/2001/XKMS/Drafts/XKMS/, work-in-
progress
[XBULK] Hughes, M (ed), "XML Key Management Specification -
Bulk Operation",
http://www.w3.org/2001/XKMS/Drafts/xkms-req.html,
work-in-progress
Editor: Farrell [Page 12]
INTERNET-DRAFT February 2002
Acknowledgements
Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman
(ckaufman@iris.com) co-authored earlier versions of this document.
Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work
adapting an earlier draft to the use of SRP. Marshall Rose
(mrose@dbc.mtview.ca.us) helped out, in particular, with the BEEP
profile. The following people were actively involved in the mailing
list discussions leading to this draft:
David Chizmadia (vze2729k@verizon.net),
Dave Crocker (dcrocker@brandenburg.com),
Lawrence Greenfield (leg+@andrew.cmu.edu),
Dale Gustafson (dale.gustafson@bpsi.net),
Mike Just (Mike.Just@entrust.com),
John Linn (jlinn@rsasecurity.com),
Neal McBurnett (neal@bcn.boulder.co.us),
Keith Moore (moore@cs.utk.edu),
Bob Morgan (rlmorgan@washington.edu),
Eamon O'Tuathail (eamon.otuathail@clipcode.com),
Magnus Nystrom (magnus@rsasecurity.com),
Gareth Richards (grichards@rsasecurity.com)
Of course, any and all errors remain the editor's responsibility.
Editor's Address
Stephen Farrell,
Baltimore Technologies,
39 Parkgate Street,
Dublin 8,
IRELAND
Phone: +353-1-881-6000
Email: stephen.farrell@baltimore.ie
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
Editor: Farrell [Page 13]
INTERNET-DRAFT February 2002
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-2002-02-22"
>
<!ENTITY sacred 'sacred-2002-02-22'>
<!ENTITY % p ''>
<!ENTITY % s ''>
] -->
<schema
targetNamespace="sacred-2002-02-22"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:sacred="sacred-2002-02-22"
xmlns="http://www.w3.org/2000/10/XMLSchema">
<!-- extensibility holes -->
<complexType name="ProcessInfoType">
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ProcessInfo" type="sacred:ProcessInfoType"/>
<complexType name="ClientInfoType">
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</complexType>
<element name="ClientInfo" type="sacred:ClientInfoType"/>
<!-- Where to put authenentication information -->
<complexType name="AuthInfoType">
<choice>
<element name="SRPAuthInfo">
<complexType>
<sequence>
<element name="salt" type="sacred:base64Binary"/>
<element name="PasswordVerifier"type="ds:CryptoBinary"/>
</sequence>
</complexType>
</element>
Editor: Farrell [Page 14]
INTERNET-DRAFT February 2002
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</choice>
</complexType>
<element name="AuthInfo" type="sacred:AuthInfoType"/>
<!-- authentication mechanism parameters -->
<complexType name="AuthParamsType">
<choice>
<element name="SRPAuthParams">
<complexType>
<sequence>
<element name="N" type="ds:CryptoBinary"/>
<element name="g" type="ds:CryptoBinary"/>
<element name="HashAlg" type="uriReference"/>
</sequence>
</complexType>
</element>
<sequence maxOccurs="unbounded">
<any namespace="##other"/>
</sequence>
</choice>
</complexType>
<element name="AuthParams" type="sacred:AuthParamsType"/>
<!-- Protocol messsages -->
<!-- "account handling" operations -->
<!-- Information request -->
<element name="InfoRequest"/>
<element name="InfoResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="ServerId" type="string"/>
<element ref="sacred:AuthParams"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
<!-- SRP stuff -->
</sequence>
</complexType>
</element>
<!-- Create Account Request -->
<element name="CreateAccountRequest">
<complexType>
<sequence>
<element name="UserId" type="string"/>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- reomve account request -->
<element name="RemoveAccountRequest">
<complexType>
<sequence>
Editor: Farrell [Page 15]
INTERNET-DRAFT February 2002
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- password change request -->
<element name="ModifyAccountRequest">
<complexType>
<sequence>
<element ref="sacred:AuthInfo"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- "run-time" operations -->
<!-- DownLoad Request -->
<element name="DownloadRequest">
<complexType>
<sequence>
<element name="CredentialSelector" type="string"
minOccurs="0"/>
<element ref="sacred:ProcessInfo" minOccurs="0"/>
</sequence>
</complexType>
</element>
<!-- Download Response -->
<element name="DownloadResponse">
<complexType>
<sequence>
<element name="Status" type="string" minOccurs="0"/>
<element name="LastModified" type="dateTime"/>
<element name="Credential" type="sacred:CredentialType"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>
<!-- Upload request -->
<element name="UploadRequest">
<complexType>
<sequence>
<element name="Credential" type="sacred:CredentialType"
minOccurs="0" maxOccurs="1" />
</sequence>
</complexType>
</element>
<!-- Credential related structures -->
<!-- A new ds:KeyInfo thing -->
<element name="SacredPKCS15" type="ds:CryptoBinary"/>
<!-- credential -->
<complexType name="CredentialType">
<sequence>
<element name="CredentialSelector" type="string"/>
<element name="Payload" type="ds:KeyInfoType"/>
<element name="TimeToLive" type="string" minOccurs="0"/>
Editor: Farrell [Page 16]
INTERNET-DRAFT February 2002
<element ref="sacred:ProcessInfo" minOccurs="0"/>
<element ref="sacred:ClientInfo" minOccurs="0"/>
</sequence>
</complexType>
<!-- if base64Binary isn't in your schema editor then add this -->
<simpleType name="base64Binary">
<restriction base="string"/>
</simpleType>
</schema>
Appendix B: DTD
<<This is semi-automatically generated from the schema above and is
probably therefore inaccurate.
<< Stuff like <!ELEMENT ClientInfo ()+> is wrong, I know. Will copy
some trick from xmldsig to fix in next rev.>>
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT AuthInfo (SRPAuthInfo | ()+)>
<!ELEMENT SRPAuthInfo (salt, PasswordVerifier)>
<!ELEMENT salt (#PCDATA)>
<!ELEMENT PasswordVerifier (#PCDATA)>
<!ELEMENT AuthParams (SRPAuthParams | ()+)>
<!ELEMENT SRPAuthParams (N, g, HashAlg)>
<!ELEMENT N (#PCDATA)>
<!ELEMENT g (#PCDATA)>
<!ELEMENT HashAlg (#PCDATA)>
<!ELEMENT ClientInfo ()+>
<!ELEMENT ProcessInfo ()+>
<!ELEMENT CreateAccountRequest (UserId, AuthInfo, ProcessInfo?)>
<!ELEMENT DownloadRequest (CredentialSelector?, ProcessInfo?)>
<!ELEMENT DownloadResponse (Status?, LastModified, Credential+)>
<!ELEMENT InfoRequest (#PCDATA)>
<!ELEMENT InfoResponse (Status?, ServerId, AuthParams,
ProcessInfo?)>
<!ELEMENT ModifyAccountRequest (AuthInfo, ProcessInfo?)>
<!ELEMENT RemoveAccountRequest (ProcessInfo?)>
<!ELEMENT UploadRequest (Credential?)>
<!ELEMENT SacredPKCS15 (#PCDATA)>
<!ELEMENT UserId (#PCDATA)>
<!ELEMENT Status (#PCDATA)>
<!ELEMENT ServerId (#PCDATA)>
<!ELEMENT LastModified (#PCDATA)>
<!ELEMENT Credential (CredentialSelector, Payload, TimeToLive?,
ProcessInfo?, ClientInfo?)>
<!ELEMENT CredentialSelector (#PCDATA)>
Editor: Farrell [Page 17]
INTERNET-DRAFT February 2002
<!ELEMENT TimeToLive (#PCDATA)>
<!ELEMENT Payload ()+>
<!ATTLIST Payload
Id ID #IMPLIED
>
Appendix C: An Example of Tuning with BEEP
Here is what tuning BEEP for authentication and privacy looks like
using SASL and SRP:
L: <wait for incoming connection>
I: <open connection>
L: RPY 0 0 . 0 170
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/TLS' />
L: <profile uri='http://iana.org/beep/SASL/SRP-SHA-160' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
I: MSG 0 1 . 52 184
I: Content-Type: application/beep+xml
I:
I: <start number='1'>
I: <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
I: <![CDATA[<blob>...</blob>]]>
I: </profile>
I: </start>
I: END
L: RPY 0 1 . 170 783
L: Content-Type: application/beep+xml
L:
L: <profile uri='http://iana.org/beep/SASL/SRP-SHA-160'>
L: <![CDATA[<blob>...</blob>]]>
L: </profile>
L: END
I: MSG 1 0 . 0 559
I: Content-Type: application/beep+xml
I:
I: <blob>...</blob>
I: END
L: RPY 1 0 . 0 429
L: Content-Type: application/beep+xml
L:
L: <blob>...</blob>
L: END
Editor: Farrell [Page 18]
INTERNET-DRAFT February 2002
I: MSG 1 1 . 559 82
I: Content-Type: application/beep+xml
I:
I: <blob>...</blob>
I: END
L: RPY 1 2 . 429 66
L: Content-Type: application/beep+xml
L:
L: <blob status='complete' />
L: END
... successful transport security negotiation ...
L: RPY 0 0 . 0 127
L: Content-Type: application/beep+xml
L:
L: <greeting>
L: <profile uri='http://iana.org/beep/transient/sacred/bss' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-Type: application/beep+xml
I:
I: <greeting />
I: END
Appendix D: Provision SACRED using other Protocols
<<This appendix represents the "no other substrates" position.>>
SACRED may be implemented in a non-BEEP environment, providing that
before any SACRED PDUs are sent, the application protocol must be
protected according to the security mandates provided in Section
2.3.
For example, if SACRED is provisioned as the payload of an
application protocol that supports SASL and TLS, then the
appropriate SASL and/or TLS negotiation must successfully occur
before exchanging Sacred PDUs.
Alternatively, if the application protocol doesn't support SASL,
then one or more PDUs are defined to facilitate a SASL negotiation,
and the appropriate negotiation must occur before exchanging Sacred
PDUs.
Appendix E: Changes & Open Issues
<<Note to RFC editor. Please remove this appendix and its TOC entry
prior to RFC publication.>>
Open Issues:
Editor: Farrell [Page 19]
INTERNET-DRAFT February 2002
- Multiple substrates issue
- SASL authorization identity issue
- Should we apply for a port number? (probably)
- Should the DTD or schema be normative? I'd usually go for the
schema, but in this case the DTD seems much simpler.
- Fix DTD extensibility scheme
- Should we specify a max value where "unbounded" is in the schema
or "+"/"*" in the DTD?
-02:
- Changes as per mailing list discussion:
- deleted (previous) section 2.4: session mgt & added sec.
cons about DoS
- Applied changes from the following threads:
- "BEEP adjustments"
- "MultipleCredentials"
- "SRP adjustments"
- "LastModified"
- Other changes:
- clarified how UploadRequest can delete one or more
credential payloads
- merged sections 2 and 3 since its much clearer that way
- changed Credential structure about a bit due to moving
LastModified
-01: Changes as per mailing list discussion:
- Change from authors to editor + acks
- Included resolved comments from list:
- password -> account pwd or cred pwd as appropriate
- account mgt separated and optional
- added example beep tuning
- selector: no default, omit in d/l means all
- changed LastModified scheme as per list comments
- Excluded administrative operations (was an open issue)
- Demoted hashed(username) concept to a note under security
considerations (see V11).
- Dropped idea of specifying a mapping between SRP id and cTLS
certificate.
- Dropped xkms & xbulk as normative references, but copied some
stuff from them.
-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
Editor: Farrell [Page 20]
