INTERNET-DRAFT                                 Editor: Stephen Farrell
expires in six months                           Baltimore Technologies
                                                          January 2002


                  Securely Available Credentials Protocol
                  <draft-ietf-sacred-protocol-bss-01.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                                            January 2002


Table Of Contents


   Status of this Memo.............................................1
   Abstract........................................................1
   Table Of Contents...............................................2
   1. Introduction.................................................2
   2. The protocol.................................................3
   3. Message Formats..............................................6
   4. BEEP Profile for SACRED......................................8
   5. IANA Considerations.........................................11
   6. Security Considerations.....................................11
   References.....................................................13
   Acknowledgements...............................................13
   Editor's Address...............................................14
   Full Copyright Statement.......................................14
   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..............................20


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] for its exchange model 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.




Editor: Farrell                                               [Page 2]

INTERNET-DRAFT                                            January 2002


   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) from 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.

2. The protocol

   This section defines the account management and "run-time"
   operations for the SACRED protocol.

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


Editor: Farrell                                               [Page 3]

INTERNET-DRAFT                                            January 2002


2.1.4   Account 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.

2.2 "Run-time" operations

   These operations MUST be supported by all conformant
   implementations.

2.2.1   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.2.2   Credential Download

   The client sends a DownloadRequest message to the server. The server
   responds with a DownloadResponse message.

2.3 Session security

   Six SACRED operations are defined above. In this section we specify
   the requirements for security for each of the operations (where
   supported). 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].

   <<There were three authorization identity options discussed on the
   list but we didn't get a clear concensus. They were 1) as above, 2)
   clients should omit the field & allow server to do what it likes,
   allow client to specify an authorization id and say server MUST
   handle that (possibly barfing if != authentication id).>>



Editor: Farrell                                               [Page 4]

INTERNET-DRAFT                                            January 2002


   Note: "Tuned" is a piece of BEEP terminology that roughly means
   "have security turned on as part of the channel initialization".
   More properly we could refer to "tuning BEEP for authentication and
   privacy". Appendix C gives an example of how tuning works.

   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.

   Security required for each SACRED operation:

      Operation                 Security REQUIRED
      ---------                 -----------------
      Information request       NONE
      Create account            sTLS
      Remove account            SRP or cTLS
      Account password change   SRP or cTLS
      Credential upload         SRP or cTLS
      Credential download       SRP or cTLS

   Where there is a choice (i.e. either SRP or cTLS allowed), servers
   MUST support both options and clients MUST support at least one of
   the options.

   <<Open issue: MUST a server that only supports up/downloads support
   cTLS as well as SRP, or is SRP-alone sufficient for this case?>>

2.4 Session management

   <<The need for this entire section has been questioned. Should it be
   more BEEP-like, deleted, s/MUST/SHOULD/ on dropping the
   connection?>>

   Once the BEEP session is appropriately tuned for security, 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
   account password, but MUST re-authenticate each time it connects to
   the server.

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



Editor: Farrell                                               [Page 5]

INTERNET-DRAFT                                            January 2002


   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.

   It is an error to have more than one credential stored under the
   same account where both have the same credential selector string.

   <<Is an empty selector string allowed? (i.e. "") Probably good to
   allow that and for it to differ from a missing selector string
   (meaning "all") in download requests.>>

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.

   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.

   All of the response messages defined here MAY contain a Status
   string, containing a value intended for human consumption. In a BEEP
   "error" message the status string is the content of the element.

Editor: Farrell                                               [Page 6]

INTERNET-DRAFT                                            January 2002



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

   - CredentialSelector 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: the server SHOULD ensure this value is reasonably
     accurate.)
   - 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).
   - CredentialElements 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).

   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.

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.

Editor: Farrell                                               [Page 7]

INTERNET-DRAFT                                            January 2002



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 previous value for the credential's
   LastModified field and the new credential.

   Note: A server SHOULD ensure that the LastModified value in the new
   credential is reasonably accurate. If it isn't then the server
   SHOULD respond with an error message in which case, the server MUST
   NOT store the new credential.

   The PrevLastModified value in the request MUST be the same as the
   LastModified value in the stored version of the credential. If not,
   then the server MUST respond with an error and MUST NOT store the
   new credential.

   If the PrevLastModified value is omitted, then the request MUST
   relate to a credential not previously stored, i.e. in this case, the
   new credential MUST have a new, unique-for-this-account, selector
   string value.

4. 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,
        PWChangeRequest,
        DownloadRequest,
        UploadRequest,
        InfoResponse,

Editor: Farrell                                               [Page 8]

INTERNET-DRAFT                                            January 2002


        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.

   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 ...>]]>
        C:     </profile>
        C: </start>

        S: <profile uri='http://iana.org/beep/transient/sacred/bss'>

Editor: Farrell                                               [Page 9]

INTERNET-DRAFT                                            January 2002


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

   code  meaning

Editor: Farrell                                              [Page 10]

INTERNET-DRAFT                                            January 2002


   ====  =======
   555   Extension (ProcessInfo) used not supported
   556   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 4, and
   selects an appropriate standards-track URI, e.g.,

        http://iana.org/beep/sacred/bss

   <<New questions: [default answer, to be used if there's no list
   discussion.]
   1. should we apply for a port number? [yes]
   2. should we define a url scheme? [no] >>

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.
    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 the SRP strong password algorithm counters this
           to a great extent. Additionally, credential servers MAY

Editor: Farrell                                              [Page 11]

INTERNET-DRAFT                                            January 2002


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







Editor: Farrell                                              [Page 12]

INTERNET-DRAFT                                            January 2002


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

  Informative:

  [TRANS]     Rose, M., "A Transient Prefix for Identifying Profiles
               under Development by the Working Groups of the IETF",
               draft-mrose-beep-transientid-01, Sedpteber 2001, work-
               in-progress
  [XKMS]      Hallam-Baker, P. (ed), "XML Key Management
               Specification", http://www.w3.org/2001/XKMS/, work-in-
               progress
  [XBULK]     Hughes, M (ed), "XML Key Management Specification - Bulk
               Operation", http://www.w3.org/2001/XKMS/, work-in-
               progress

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

Editor: Farrell                                              [Page 13]

INTERNET-DRAFT                                            January 2002


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

Editor: Farrell                                              [Page 14]

INTERNET-DRAFT                                            January 2002


      "XMLSchema.dtd" [
       <!ATTLIST schema
       xmlns:sacred CDATA #FIXED "sacred-2002-02-01"
      >
       <!ENTITY sacred 'sacred-2002-02-01''>
       <!ENTITY % p ''>
       <!ENTITY % s ''>
      ] -->
   <schema targetNamespace="sacred-2002-02-01"
   xmlns="http://www.w3.org/2000/10/XMLSchema" xmlns:sacred="sacred-
   2002-02-01" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
     <!-- misc - copied from xbulk to avoid dependency -->
     <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"/>
     <!-- general account handling -->
     <!-- Information request -->
     <element name="InfoRequest"/>
     <element name="InfoResponse">
       <complexType>
         <sequence>
           <element name="Status" type="string" minOccurs="0"/>
           <element name="ServerId" type="string"/>
           <element name="N" type="ds:CryptoBinary"/>
           <element name="g" type="ds:CryptoBinary"/>
           <element name="HashAlg" type="uriReference"/>
           <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 name="salt" type="sacred:base64Binary"/>
           <element name="PasswordVerifier" type="ds:CryptoBinary"/>
           <element ref="sacred:ProcessInfo" minOccurs="0"/>
         </sequence>
       </complexType>
     </element>
     <!-- reomve account request -->
     <element name="RemoveAccountRequest">

Editor: Farrell                                              [Page 15]

INTERNET-DRAFT                                            January 2002


       <complexType>
         <sequence>
           <element ref="sacred:ProcessInfo" minOccurs="0"/>
         </sequence>
       </complexType>
     </element>
     <!-- password change request -->
     <element name="PWChangeRequest">
       <complexType>
         <sequence>
           <element name="salt" type="sacred:base64Binary"/>
           <element name="PasswordVerifier" type="ds:CryptoBinary"/>
           <element ref="sacred:ProcessInfo" minOccurs="0"/>
         </sequence>
       </complexType>
     </element>
     <!-- credential specific operations -->
     <!-- DownLoad Request -->
     <element name="DownloadRequest">
       <complexType>
         <sequence>
           <element name="CredSel" 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="Credential" type="sacred:CredentialType"/>
         </sequence>
       </complexType>
     </element>
     <!-- Upload request -->
     <element name="UploadRequest">
       <complexType>
         <sequence>
           <element name="PrevLastModified" type="string"
             minOccurs="0"/>
           <element name="NewCredential" type="sacred:CredentialType"/>
         </sequence>
       </complexType>
     </element>
     <!-- A new ds:KeyInfo thing -->
     <element name="SacredPKCS15" type="ds:CryptoBinary"/>
     <!-- credential -->
     <complexType name="CredentialType">
       <sequence>
         <element name="CredentialSelector" type="string"
           minOccurs="0"/>
         <element name="LastModified" type="timeInstant"/>

Editor: Farrell                                              [Page 16]

INTERNET-DRAFT                                            January 2002


         <element name="TimeToLive" type="string" minOccurs="0"/>
         <element ref="sacred:ProcessInfo" minOccurs="0"/>
         <element ref="sacred:ClientInfo" minOccurs="0"/>
         <element name="Payload" type="ds:KeyInfoType"
           minOccurs="0" maxOccurs="unbounded"/>
       </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.>>

   <?xml version="1.0" encoding="UTF-8"?>

   <!ENTITY % THING "Stuff" >

   <!ELEMENT ClientInfo (%THING;)+>
   <!ELEMENT ProcessInfo (%THING;)+>
   <!ELEMENT SacredPKCS15 (#PCDATA)>

   <!ELEMENT Credential (CredentialSelector?, LastModified,
   TimeToLive?, ProcessInfo?, ClientInfo?, Payload*)>
   <!ELEMENT CredentialSelector (#PCDATA)>
   <!ELEMENT LastModified (#PCDATA)>
   <!ELEMENT TimeToLive (#PCDATA)>
   <!ELEMENT Payload (%THING;)+>
   <!ATTLIST Payload
        Id ID #IMPLIED
   >

   <!ELEMENT CreateAccountRequest (UserId, salt, PasswordVerifier,
   ProcessInfo?)>
   <!ELEMENT UserId (#PCDATA)>
   <!ELEMENT salt (#PCDATA)>
   <!ELEMENT PasswordVerifier (#PCDATA)>

   <!ELEMENT DownloadRequest (CredSel?, ProcessInfo?)>
   <!ELEMENT CredSel (#PCDATA)>

   <!ELEMENT DownloadResponse (Status?, Credential)>
   <!ELEMENT Status (#PCDATA)>

   <!ELEMENT InfoRequest (#PCDATA)>



Editor: Farrell                                              [Page 17]

INTERNET-DRAFT                                            January 2002

   <!ELEMENT InfoResponse (Status?, ServerId, N, g, HashAlg,
   ProcessInfo?)>
   <!ELEMENT ServerId (#PCDATA)>
   <!ELEMENT N (#PCDATA)>
   <!ELEMENT g (#PCDATA)>
   <!ELEMENT HashAlg (#PCDATA)>

   <!ELEMENT PWChangeRequest (salt, PasswordVerifier, ProcessInfo?)>

   <!ELEMENT RemoveAccountRequest (ProcessInfo?)>

   <!ELEMENT UploadRequest (PrevLastModified?, NewCredential)>
   <!ELEMENT PrevLastModified (#PCDATA)>
   <!ELEMENT NewCredential (CredentialSelector?, LastModified,
   TimeToLive?, ProcessInfo?, ClientInfo?, Payload*)>

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


Editor: Farrell                                              [Page 18]

INTERNET-DRAFT                                            January 2002


       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
       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. If
   the WG concensus were to converge onto also supporting http (say),
   then this appendix will change, possibly even moving into the body
   of the document.>>

   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.


Editor: Farrell                                              [Page 19]

INTERNET-DRAFT                                            January 2002


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

   -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

   Major Open Issues:

   - Multiple substrates issue
   - SASL authorization identity issue
   - Simplicity: is there a way to use XML, provide schema and DTD (for
     information) but not inherit any generic XML complexity?

   Other Open Issues:

   - If a server only supports up/down-load, then is SRP alone
     sufficient or MUST the server also support cTLS? (The latter
     according to the current text.)
   - Meaning of empty string for credential selector?
   - Does section 2.4 need changes?
   - Should we apply for a port number? (probably)
   - Should we define a URI scheme? (probably not)
   - Should the DTD or schema be normative? I'd usually go for the
     schema, but in this case the DTD seems much simpler.



Editor: Farrell                                              [Page 20]