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]