[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 RFC 3767

INTERNET-DRAFT                                 Editor: Stephen Farrell
Expires in six months                           Baltimore Technologies
                                                            April 2003

                   Securely Available Credentials Protocol
                   <draft-ietf-sacred-protocol-bss-07.txt>

Status of this Memo

    This document is an Internet-Draft and is subject to all provisions
    of Section 10 of [RFC2026].
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups. Note that
    other groups may also distribute working documents as Internet-
    Drafts. Internet-Drafts are draft documents valid for a maximum of
    six months and may be updated, replaced, or obsoleted by other
    documents at any time. It is inappropriate to use Internet- Drafts
    as reference material or to cite them other than as "work in
    progress."

    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html.

Abstract

    This document describes a protocol for the secure up- and down-load
    of cryptographic 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......................................8
    4. IANA Considerations.........................................11
    5. Security Considerations.....................................11
    References.....................................................13
    Acknowledgements...............................................14
    Editor's Address...............................................14
    Full Copyright Statement.......................................14
    Appendix A: XML Schema.........................................15
    Appendix B: An Example of Tuning with BEEP.....................19
    Appendix C: Provision SACRED using other Protocols.............22
    Appendix D: Changes & Open Issues..............................22


Editor: Farrell                                               [Page 1]

INTERNET-DRAFT                                              April 2003



1. Introduction

    We describe a protocol whereby a user can acquire cryptographic
    credentials (e.g., private keys, PKCS #15 [PKCS15] structures) from
    a credential server, using a workstation that 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's payloads are described in XML. BEEP [BEEP] is
    required for message transport and security (confidentiality,
    authentication, etc.). The protocol sets out to meet the
    requirements in [REQS]. In particular, security requirements in
    [REQS] are met by mandating support (via BEEP) for TLS [TLS] and/or
    DIGEST-MD5 [DIGEST-MD5].

    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.

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
    this document are to be interpreted as described in [RFC2119].







Editor: Farrell                                               [Page 2]

INTERNET-DRAFT                                              April 2003


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 described in
    XML [XMLSCHEMA]. Appendix A provides an XML schema 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 does NOT REQUIRE 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. For DIGEST-MD5 this consists of the
    list of realms (each as an XML element named "Realm") which the
    server supports. There MUST be at least one realm specified. Clients
    MUST be able to select one from a list of Realms and MUST be able to
    disregard any other information present (allowed for extensibility).

2.1.2   Create Account

    This operation REQUIRES 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 [SASL] mechanism used.

    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 DIGEST-MD5 this consists of the password verifier
    (the hashed username, password and realm) and the chosen realm.

Editor: Farrell                                               [Page 3]

INTERNET-DRAFT                                              April 2003


    Although more than one set of such data is allowed by the data
    structures defined in the appendix, clients SHOULD only include one
    here.

    The server responds with an error or acknowledgement message.

2.1.3   Remove Account

    This operation REQUIRES 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 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.

    The client sends a ModifyAccountRequest message which contains 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 [DIGEST-MD5] it will consist of a realm and password verifier
    value.

    Once the account information has been changed, the server will
    respond 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 mutual authentication.

    The purpose of this operation is to allow the client to deposit a
    credential with the server.

    The client sends an UploadRequest message to the server which MUST
    contain one Credential.

    If a credential with the same credential selector field as in the
    UploadRequest, (a "matching" credential), already exists for the

Editor: Farrell                                               [Page 4]

INTERNET-DRAFT                                              April 2003


    account, then that credential is replaced with the new credential
    from the UploadRequest. Otherwise a "new" credential is associated
    with that account.

    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 corresponding LastModified
    value (returned in DownloadResponse messages) to the current time
    (at the server).

    The LastModified value in the UploadRequest MUST be the value which
    was most recently received in a corresponding DownloadResponse for
    that credential. This means the clients are strongly RECOMMENDED to
    only produce an UploadRequest based on recently downloaded
    credentials, since otherwise the LastModified value may be out of
    date.

    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. In this case the server MUST respond with a BEEP
    error (which SHOULD be StaleCredential).

    The server replaces the provided LastModified value with the current
    time at the server before storing the credential. (Note that this
    means that it would be unwise for a client to include the
    LastModified field in a ClientInfo digital signature which is
    calculated over the CredentialType.)

    The server responds with an error or acknowledgement message.

2.2.2   Credential Download

    This operation REQUIRES 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 including
    the LastModified time which represents the time (at the server) when
    the last change was made to each credential associated with the
    account (e.g. subsequent to an UploadRequest).




Editor: Farrell                                               [Page 5]

INTERNET-DRAFT                                              April 2003


2.2.3   Credential Delete

    This operation REQUIRES mutual authentication.

    The purpose of this operation is to allow the client to delete one
    or all credentials associated with the account.

    The client sends an DeleteRequest message to the server which can
    contain either a CredentialSelector or an All element.

    If the DeleteRequest contains an All element then all of the
    credentials associated with that account are deleted.

    If the DeleteRequest contains a CredentialSelector then the request
    MAY include a LastModified value.  If the LastModified value is
    present in the DeleteRequest then it MUST be the value which was
    most recently received in a corresponding DownloadResponse for that
    credential. If the value does not match then the server MUST NOT
    delete the credentials.

    If no "matching" credential exists, the server returns an error.

    The server responds to this request with an error or acknowledgement
    message.

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
         Modify account            Mutual authentication,
                                   Privacy, Integrity
         Credential upload         Mutual authentication,
                                   Privacy, Integrity
         Credential download       Mutual authentication,
                                   Privacy, Integrity
         Credential delete         Mutual authentication,
                                   Privacy, Integrity

    The security requirements can be met by several mechanisms. This
    document REQUIRES credential servers to support TLS and DIGEST-MD5.
    Clients MUST support DIGEST-MD5 and TLS with server authentication.


Editor: Farrell                                               [Page 6]

INTERNET-DRAFT                                              April 2003


    The mandatory-to-implement TLS cipher suite for SACRED is
    TLS_RSA_WITH_3DES-EDE_CBC_SHA.

    When performing mutual authentication using DIGEST-MD5 for the
    client, DIGEST-MD5 MUST only be used "within" a TLS server-
    authenticated "pipe", and MUST only be used only for client
    authentication. That is, we do not use the DIGEST-MD5 security
    services (confidentiality, integrity etc.).

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

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

Editor: Farrell                                               [Page 7]

INTERNET-DRAFT                                              April 2003


    - 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).
    - LastModified is a string containing the time (at the server) at
      which this credential was last modified.
    - 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,
         UploadRequest,
         DeleteRequest,
         InfoResponse,
         DownloadResponse,
         error,
         ok

    Messages starting one-to-one exchanges:
         InfoRequest,
         CreateAccountRequest,
         RemoveAccountRequest,
         ModifyAccountRequest,
         DownloadRequest,
         UploadRequest,
         DeleteRequest


Editor: Farrell                                               [Page 8]

INTERNET-DRAFT                                              April 2003


    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/beep/TLS followed by
           http://iana.org/SASL/DIGEST-MD5

    Appendix B gives an example of tuning a BEEP session using DIGEST-
    MD5 (i.e. it shows how to turn on BEEP security).

    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 3.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'>
         S:   <![CDATA[<DownloadResponse ...>]]>
         S: </profile>

    Note that BEEP imposes both encoding and length limitations on the
    messages that are piggybacked during channel initialization.


Editor: Farrell                                               [Page 9]

INTERNET-DRAFT                                              April 2003


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
    I            DeleteRequest         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)

    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
    557   StaleCredential (A bad LastModified value was
          contained in an UploadRequest.)

Editor: Farrell                                              [Page 10]

INTERNET-DRAFT                                              April 2003



3.4 SASL authorization identity

    The use of the SASL authorization identity in this protocol is
    implementation-specific.  If used, the authorization identity is not
    a substitute for the credential selector field, but may be used to
    affect authorization for access to credentials.

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

    The sacred protocol SHOULD be run over port <<TBD>>.

    The GSSAPI service name (required when using SASL) for this protocol
    SHALL be "sacred".

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 DIGEST-MD5 and/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.

Editor: Farrell                                              [Page 11]

INTERNET-DRAFT                                              April 2003


            - 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 mutual authentication requirements of this protocol
            counter 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.
            - Since the DIGEST-MD5 mechanism is only used after TLS
            tuning, the user's name is also protected.
     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
    connections and minimize the use of resources by un-authenticated
    connections. A number of recommendations are listed at [DDOS].



Editor: Farrell                                              [Page 12]

INTERNET-DRAFT                                              April 2003


    Various operations in the SACRED protocol depend upon server
    authentication being provided by server authenticated TLS. SACRED
    clients SHOULD take care that the correct server is at the far end
    of the TLS "pipe" by performing the checks which are listed in
    section 3.1 of RFC2818 [RFC2818]. Clients SHOULD also include the
    optional BEEP serverName field in their "start" message and SHOULD
    then ensure that the BEEP serverName is consistent with the checks
    on the TLS server described in RFC2818. Failure to carry out these
    checks could allow a spoof server access a user's credential.

    If the SACRED account password were to be used in some other, less
    secure protocol using DIGEST-MD5, then it might appear to be the
    case that a man-in-the-middle (MITM) attack could be mounted.
    However, this is not the case since the DIGEST-MD5 client hash
    includes a client-selected "digest-uri-value" which in SACRED's case
    will be  "sacred/<serverName>". In a MITM attack, those values will
    be something else. A MITM attack as described is therefore thwarted
    because digest-uri-value wouldn't match what the SACRED server is
    expecting.

References

    Normative:

        [BEEP]     Rose, M., "The Blocks Extensible Exchange Protocol
                   Core", RFC 3080.
        [DIGEST-MD5]    "Using Digest Authentication as a SASL
                   Mechanism", Leach, P., Newman, C., RFC 2831.
        [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.
        [TLS]      Dierks, T., "The TLS Protocol - Version 1.0", RFC
                   2246.
        [XMLDSIG]  Eastlake, D., et al. "XML-Signature Syntax and
                   Processing", RFC 3075.
        [XMLSCHEMA] "XML Schema Part 1: Structures", D. Beech, M.
                   Maloney, N. Mendelsohn, and H. Thompson. W3C
                   Recommendation, May 2001.  Available at
                   http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/
    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

Editor: Farrell                                              [Page 13]

INTERNET-DRAFT                                              April 2003


        [RFC2818]  Rescorla, E., "HTTP over TLS", RFC 2818.
        [TRANS]    Rose, M., "A Transient Prefix for Identifying
                   Profiles under Development by the Working Groups of
                   the IETF", RFC 3349.
        [XKMS]     Hallam-Baker, P. (ed), "XML Key Management
                   Specification", http://www.w3.org/TR/xkms2/
        [XBULK]    Hughes, M (ed), "XML Key Management Specification -
                   Bulk Operation", http://www.w3.org/TR/xkms2-xbulk/

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 (though SRP was
    subsequently dropped, much of the framework survives). Marshall Rose
    (mrose@dbc.mtview.ca.us) helped out a lot, in particular, with the
    BEEP profile. And 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),
         Magnus Nystrom (magnus@rsasecurity.com),
         Eamon O'Tuathail (eamon.otuathail@clipcode.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

Editor: Farrell                                              [Page 14]

INTERNET-DRAFT                                              April 2003


    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" encoding="UTF-8"?>
       <schema
         targetNamespace="urn:sacred-2002-12-19"
         xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
         xmlns:sacred="urn:sacred-2002-12-19"
         xmlns="http://www.w3.org/2001/XMLSchema">
         <import namespace="http://www.w3.org/2000/09/xmldsig#"
                 schemaLocation="../W3C/xmldsig-core-schema.xsd"/>
         <!-- 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 maxOccurs="unbounded">
           <element name="DigestMD5AuthInfo">
            <complexType>
             <sequence>
              <element name="PasswordVerifier" type="base64Binary"/>
              <element name="Realm" type="string" />
             </sequence>

Editor: Farrell                                              [Page 15]

INTERNET-DRAFT                                              April 2003


            </complexType>
           </element>
           <any namespace="##other"/>
          </choice>
         </complexType>
         <element name="AuthInfo" type="sacred:AuthInfoType"/>
         <!-- authentication mechanism parameters -->
         <complexType name="AuthParamsType">
          <choice maxOccurs="unbounded">
           <element name=" DigestMD5AuthParams">
            <complexType>
             <sequence>
              <element name="Realm" type="string"
                minOccurs="1" maxOccurs="unbounded"/>
             </sequence>
            </complexType>
           </element>
           <any namespace="##other"/>
          </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"/>
           </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>
            <element ref="sacred:ProcessInfo" minOccurs="0"/>
           </sequence>
          </complexType>
         </element>

Editor: Farrell                                              [Page 16]

INTERNET-DRAFT                                              April 2003


         <!-- 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="Credential" type="sacred:CredentialType"
             maxOccurs="unbounded"/>
           </sequence>
          </complexType>
         </element>
         <!-- Upload request -->
         <element name="UploadRequest">
          <complexType>
           <sequence>
            <element name="Credential" type="sacred:CredentialType"/>
           </sequence>
          </complexType>
         </element>
         <element name="DeleteRequest">
           <complexType>
             <sequence>
               <choice>
                 <sequence>
                   <element name="CredentialSelector" type="string"/>
                   <element name="LastModified" type="dateTime"
                         minOccurs="0"/>
                 </sequence>
                 <element name="All"/>
               </choice>
               <element ref="sacred:ProcessInfo" minOccurs="0"/>
             </sequence>
           </complexType>
         </element>

Editor: Farrell                                              [Page 17]

INTERNET-DRAFT                                              April 2003


         <!-- Credential related structures -->
         <!-- A new ds:KeyInfo thing -->
         <element name="SacredPKCS15" type="base64Binary"/>
         <!-- credential -->
         <complexType name="CredentialType">
          <sequence>
           <element name="CredentialSelector" type="string"/>
           <element name="LastModified" type="dateTime"/>
           <element name="Payload" type="ds:KeyInfoType" minOccurs="0"/>
           <element name="TimeToLive" type="string" minOccurs="0"/>
           <element ref="sacred:ProcessInfo" minOccurs="0"/>
           <element ref="sacred:ClientInfo" minOccurs="0"/>
          </sequence>
         </complexType>

    </schema>






































Editor: Farrell                                              [Page 18]

INTERNET-DRAFT                                              April 2003


Appendix B: An Example of Tuning with BEEP

    Here is what tuning BEEP for authentication and privacy looks like
    using TLS and SASL's DIGEST-MD5:

    L: <wait for incoming connection>
    I: <open connection>

    ... each peer sends a greeting indicating the services that
        it offers ...

    L: RPY 0 0 . 0 233
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' />
    L:    <profile uri='http://iana.org/beep/TLS' />
    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


    ... the initiator starts a channel for TLS and piggybacks a request
        to start the TLS negotiation ...

    I: MSG 0 1 . 52 149
    I: Content-Type: application/beep+xml
    I:
    I: <start number='1' serverName="sacred.example.org">
    I:    <profile uri='http://iana.org/beep/TLS'>
    I:        &lt;ready />
    I:    </profile>
    I: </start>
    I: END

    ... the listener creates the channel and piggybacks its readiness to
        start TLS ...

    L: RPY 0 1 . 233 112
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri='http://iana.org/beep/TLS'>
    L:     &lt;proceed />
    L: </profile>
    L: END

    ... upon receiving the reply, the initiator starts up TLS ...


Editor: Farrell                                              [Page 19]

INTERNET-DRAFT                                              April 2003



    ... successful transport security negotiation ...


    ... a new greeting is sent (cf., Section 9 of RFC 3080), note that
        the listener no longer advertises TLS (we're already running
        it)

    L: RPY 0 0 . 0 186
    L: Content-Type: application/beep+xml
    L:
    L: <greeting>
    L:    <profile uri='http://iana.org/beep/SASL/DIGEST-MD5' />
    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


    ... the initiator starts a channel for DIGEST-MD5 and piggybacks
        initialization information for the mecdhanism ...

    I: MSG 0 1 . 52 178
    I: Content-Type: application/beep+xml
    I:
    I: <start number='1'>
    I:    <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'>
    I:        &lt;blob> ... &lt;/blob>
    I:    </profile>
    I: </start>
    I: END

    ... the listener creates the channel and piggybacks a challenge ...

    L: RPY 0 1 . 186 137
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'>
    L:     &lt;blob> ... &lt;/blob>
    L: </profile>
    L: END

    ... the initiator sends a response to the challenge ...

    I: MSG 1 0 . 0 58
    I: Content-Type: application/beep+xml
    I:
    I: <blob> ... </blob>
    I: END

Editor: Farrell                                              [Page 20]

INTERNET-DRAFT                                              April 2003



    ... the listener accepts the challenge and tells the initiator
        that it is now authenticated ...

    L: RPY 1 0 . 0 66
    L: Content-Type: application/beep+xml
    L:
    L: <blob status='complete' />
    L: END


    ... the initiator starts a channel for SACRED and piggybacks its
        initial SACRED request ...

    I: MSG 0 2 . 230 520
    I: Content-Type: application/beep+xml
    I:
    I: <start number='3'>
    I:    <profile uri='http://iana.org/beep/transient/sacred/bss' />
    I:        &lt;?xml version="1.0" encoding="UTF-8"?>
    I:        &lt;sacred:DownloadRequest
    I:          xmlns:sacred="urn:sacred-2002-11-20"
    I:          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    I:          xsi:schemaLocation="urn:sacred-2002-11-20 sacred.xsd">
    I:          &lt;CredentialSelector>
    I:                      magnus-credentials&lt;/CredentialSelector>
    I:        &lt;/sacred:DownloadRequest>
    I: </start>
    I: END

    ... the listener creates the channel and piggybacks the response to
    the
        initial SACRED request

    L: RPY 0 2 . 323 805
    L: Content-Type: application/beep+xml
    L:
    L: <profile uri='http://iana.org/beep/transient/sacred/bss' />
    L:     &lt;?xml version="1.0" encoding="UTF-8"?>
    L:     &lt;sacred:DownloadResponse
    L:       xmlns:sacred="urn:sacred-2002-11-20"
    L:       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    L:       xsi:schemaLocation="urn:sacred-2002-11-20 sacred.xsd">
    L:       &lt;Status>Success&lt;/Status>
    L:       &lt;Credential>
    L:         &lt;CredentialSelector>
    L:              magnus-credential&lt;/CredentialSelector>
    L:         &lt;LastModified>2002-11-22T00:00:08Z&lt;/LastModified>
    L:         &lt;Payload>
    L:             &lt;sacred:SacredPKCS15
    L:               xmlns:sacred="urn:sacred-2002-11-20">GpM7
    L:             &lt;/sacred:SacredPKCS15>
    L:         &lt;/Payload>

Editor: Farrell                                              [Page 21]

INTERNET-DRAFT                                              April 2003


    L:       &lt;/Credential>
    L:     &lt;/sacred:DownloadResponse>
    L: </profile>
    L: END


Appendix C: Provision SACRED using other Protocols

    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 D: Changes & Open Issues

    <<Note to RFC editor. Please remove this appendix and its TOC entry
    prior to RFC publication.>>

    -07 (WG Last-Call Issues):
         - Added explicit credential delete message
    -06:
         - Updated appendix B with Marshall's latest text (but including
           the serverName attribute in the initiator's first start
           message, as in -05)
         - Otherwise no change
    -05:
         - Credential payload element -> minOccurs="0"
         - Added security considerations for the compound authentication
           "issue"
         - Gratefully added rlbob SASL authorization id text
         - Extended Appendix B with Magnus' samples
         - Applied changes in "More editorials" mail
         - Clarified that we're using BEEP for security and what
           "tuning" means
         - Replaced schema with equivalent that "compiles"
    -04:
         - Replaced SASL-MD5 with DIGEST-MD5 everywhere
         - Updated appendix B and other BEEP issues according to
           Marshall Rose's Oct 6th recommendations
         - Applied all but three "editorial corrections" raised on list,
           see
         - Added a recommendation to download prior to modify


Editor: Farrell                                              [Page 22]

INTERNET-DRAFT                                              April 2003


         - Fixed AuthXXXType extensibility as suggested by Gareth
           Richards
    -03:
         - Should the DTD or schema be normative? I'd usually go for the
           schema, but in this case the DTD seems much simpler.
           - Deleted DTD
         - Should we apply for a port number? (probably)
           - Mailed IANA and added IANA considerations section.
         - Multiple substrates issue
           - Decided at Minneapolis (Spring 2002) not to change.
         - Should we specify a max value where "unbounded" is in the
           schema or "+"/"*" in the DTD?
           - Nope.
         - Remove SASL-SRP and replace with something else
           - Done - changed to DIGEST-MD5 (rfc 2831).
         - SASL authorization identity issue
           - Waited some time for text that didn't arrive and so leaving
              current text as is.
         - Changed away from having a request with an empty sequence
           representing an implicit delete to where an explicit deletion
           request indicator (an XML attribute) is required
         - Added a service name: "The GSSAPI service name (required when
           using SASL) for this protocol SHALL be "SACRED"." (Note: I
           don't understand this and don't want to, but do let me know
           if its wrong:-)
    -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.

Editor: Farrell                                              [Page 23]

INTERNET-DRAFT                                              April 2003


         - 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 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/