INTERNET-DRAFT                                 Editor: Stephen Farrell 
expires in six months                           Baltimore Technologies 
                                                        December 2002 
    
                  Securely Available Credentials Protocol 
                  <draft-ietf-sacred-protocol-bss-05.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.....................18 
   Appendix C: Provision SACRED using other Protocols.............20 
   Appendix D: Changes & Open Issues..............................20 

 
editor: Farrell                                               [Page 1] 
INTERNET-DRAFT                                           December 2002 


    
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                                           December 2002 


2. The protocol 
    
   This section defines the account management and "run-time" 
   operations for the SACRED protocol. 
    
   It also describes the message formats used, which are 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                                           December 2002 


   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, or to delete one or more credentials 
   associated with the account. 
    
   The client sends an UploadRequest message to the server which can 
   contain zero or one Credential. If the UploadRequest contains no 
   Credential and the UploadRequest contains a "Delete="yes"" 

 
editor: Farrell                                               [Page 4] 
INTERNET-DRAFT                                           December 2002 


   attribute, then the all the credentials associated with that account 
   are deleted. 
    
   If a credential with the same credential selector field as in the 
   UploadRequest, (a "matching" credential), already exists for the 
   account, then that credential is replaced with the new credential 
   from the UploadRequest. Otherwise a "new" credential is associated 
   with that account.  
    
   If the new credential from the UploadRequest contains no PayLoad 
   field and the new credential has a "Delete="yes"" attribute, then 
   the (one and only) "matching" credential is deleted. 
    
   The processing of the "Delete" attribute MUST be strict รป that is, 
   this attribute MUST be ignored unless it is set on a data structure 
   (either UploadRequest or Credential) which contains no useful value, 
   and the value of the attribute MUST be precisely "yes", any other 
   string value MUST be ignored. 
    
   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 however. (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.  
    






 
editor: Farrell                                               [Page 5] 
INTERNET-DRAFT                                           December 2002 


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). 
    
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 
    
   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. 
    
   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.). 
 
editor: Farrell                                               [Page 6] 
INTERNET-DRAFT                                           December 2002 


    
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. 
   - 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. 
 
editor: Farrell                                               [Page 7] 
INTERNET-DRAFT                                           December 2002 


   - 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, 
        InfoResponse, 
        DownloadResponse, 
        error, 
        ok 
    
   Messages starting one-to-one exchanges:  
        InfoRequest,  
        CreateAccountRequest, 
        RemoveAccountRequest, 
        ModifyAccountRequest, 
        DownloadRequest, 
        UploadRequest 
    
   Messages in positive replies:  
        ok,  
        InfoResponse, 
        DownloadResponse 
    
   Messages in negative replies: error 
    
   Messages in one-to-many changes: none 
    
   Message Syntax: c.f.,Section 3 
 
editor: Farrell                                               [Page 8] 
INTERNET-DRAFT                                           December 2002 


    
   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. 

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 
 
editor: Farrell                                               [Page 9] 
INTERNET-DRAFT                                           December 2002 


   Role         MSG                   RPY                     ERR 
   ----         ---                   ---                     --- 
   I            ModifyAccountRequest  ok                      error 
   I            DownloadRequest       DownloadResponse        error 
   I            UploadRequest         ok                      error 
    
3.3 Error handling 
    
   The "error" message from Section 2.3.1.5 of [BEEP] is used to convey 
   error information. Typically, after flagging an error, a peer will 
   initiate a graceful release of the BEEP session. 
    
   The following BEEP error reply codes from [BEEP] are to be used: 
    
   code  Meaning 
   ====  ======= 
   421   service not available 
   450   requested action not taken (e.g., lock already in 
          use) 
   451   requested action aborted (e.g., local error in 
          processing) 
   454   temporary authentication failure 
   500   general syntax error (e.g., poorly-formed XML) 
   501   syntax error in parameters (e.g., non-valid XML) 
   504   parameter not implemented 
   530   authentication required 
   534   authentication mechanism insufficient (e.g., too 
          weak, sequence exhausted, etc.) 
   535   authentication failure 
   537   action not authorized for user 
   538   authentication mechanism requires encryption 
   550   requested action not taken (e.g., no requested 
          profiles are acceptable) 
   553   parameter invalid 
   554   transaction failed (e.g., policy violation) 
    
   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.) 

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. 
    

 
editor: Farrell                                              [Page 10] 
INTERNET-DRAFT                                           December 2002 


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. 
           - 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 
 
editor: Farrell                                              [Page 11] 
INTERNET-DRAFT                                           December 2002 


           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].  
    
   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. 
 
editor: Farrell                                              [Page 12] 
INTERNET-DRAFT                                           December 2002 


    
   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 
       [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/ 
    
 
editor: Farrell                                              [Page 13] 
INTERNET-DRAFT                                           December 2002 


Acknowledgements 
    
   Radia Perlman (radia.perlman@sun.com) and Charlie Kaufman 
   (ckaufman@iris.com) co-authored earlier versions of this document. 
   Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work 
   adapting an earlier draft to the use of SRP (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   
   kind, provided that the above copyright notice and this paragraph   
   are included on all such copies and derivative works.  In addition,   
   the ASN.1 module presented in Appendix B may be used in whole or in   
   part without inclusion of the copyright notice.  However, this   
   document itself may not be modified in any way, such as by removing   
   the copyright notice or references to the Internet Society or other   
   Internet organizations, except as needed for the purpose of   
   developing Internet standards in which case the procedures for   
   copyrights defined in the Internet Standards process shall be   
 
editor: Farrell                                              [Page 14] 
INTERNET-DRAFT                                           December 2002 


   followed, or as required to translate it into languages other than   
   English. 
    
   The limited permissions granted above are perpetual and will not be 
   revoked by the Internet Society or its successors or assigns.  This 
   document and the information contained herein is provided on an "AS 
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 
   WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
    
Appendix A: XML Schema 
    
   <?xml version="1.0" 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>  
           </complexType>  
          </element>  
          <any namespace="##other"/>  
         </choice>  
        </complexType>  
        <element name="AuthInfo" type="sacred:AuthInfoType"/>  
        <!-- authentication mechanism parameters -->  
        <complexType name="AuthParamsType">  
         <choice maxOccurs="unbounded">  
 
editor: Farrell                                              [Page 15] 
INTERNET-DRAFT                                           December 2002 


          <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>  
        <!-- password change request -->  
        <element name="ModifyAccountRequest">  
         <complexType>  
          <sequence>  
           <element ref="sacred:AuthInfo"/>  
           <element ref="sacred:ProcessInfo" minOccurs="0"/>  
          </sequence>  
         </complexType>  
        </element>  
 
editor: Farrell                                              [Page 16] 
INTERNET-DRAFT                                           December 2002 


        <!-- "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"  
            minOccurs="0" maxOccurs="1" />  
          </sequence>  
          <attribute name="Delete" type="string" use="optional"/>  
         </complexType>  
        </element>  
        <!-- 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>  
         <attribute name="Delete" type="string" use="optional"/>  
        </complexType>  
    
   </schema>  
    




 
editor: Farrell                                              [Page 17] 
INTERNET-DRAFT                                           December 2002 


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> 
   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 
   I: MSG 0 1 . 52 158 
   I: Content-Type: application/beep+xml 
   I:  
   I: <start number='1' serverName="sacred.example.org"> 
   I:    <profile uri='http://iana.org/beep/TLS'> 
   I:        <![CDATA[<ready />]]>]]&gt;<![CDATA[ 
   I:    </profile> 
   I: </start> 
   I: END 
   L: RPY 0 1 . 233 121 
   L: Content-Type: application/beep+xml 
   L: 
   L: <profile uri='http://iana.org/beep/TLS'> 
   L:     <![CDATA[<proceed />]]>]]&gt;<![CDATA[ 
   L: </profile> 
   L: END 
    
   ... successful transport security negotiation ... 
    
   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 
 
editor: Farrell                                              [Page 18] 
INTERNET-DRAFT                                           December 2002 


   I: MSG 0 1 . 52 143 
   I: Content-Type: application/beep+xml  
   I:  
   I: <start number='1'>  
   I:    <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'>  
   I:        &lt;blob /> 
   I:    </profile>  
   I: </start>  
   I: END  
   L: RPY 0 1 . 186 339 
   L: Content-Type: application/beep+xml  
   L:  
   L: <profile uri='http://iana.org/beep/SASL/DIGEST-MD5'>  
   L:     <![CDATA[<blob>...</blob>]]>  
   L: </profile>  
   L: END  
   I: MSG 1 0 . 0 355 
   I: Content-Type: application/beep+xml  
   I:  
   I: <blob> 
   I: &lt;?xml version="1.0" encoding="UTF-8"?&gt; 
   I: &lt;sacred:DownloadRequest 
   I:   xmlns:sacred="urn:sacred-2002-12-19" 
   I:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   I:   xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"&gt; 
   I:   &lt;CredentialSelector&gt; 
   I:          magnus-credentials&lt;/CredentialSelector&gt; 
   I: &lt;/sacred:DownloadRequest&gt; 
   I: </blob> 
   I: END  
   L: RPY 1 0 . 0 125 
   L: Content-Type: application/beep+xml  
   L:  
   L: <blob status='complete'> 
   L: &lt;?xml version="1.0" encoding="UTF-8"?&gt; 
   L: &lt;sacred:DownloadResponse 
   L:   xmlns:sacred="urn:sacred-2002-12-19" 
   L:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
   L:   xsi:schemaLocation="urn:sacred-2002-12-19 sacred.xsd"&gt; 
   L:   &lt;Status>Success&lt;/Status&gt; 
   L:   &lt;Credential&gt; 
   L:     &lt;CredentialSelector> 
   L:          magnus-credential&lt;/CredentialSelector&gt; 
   L:     &lt;LastModified>2002-11-22T00:00:08Z&lt;/LastModified&gt; 
   L:     &lt;Payload&gt; 
   L:         &lt;sacred:SacredPKCS15 
   L:           xmlns:sacred="urn:sacred-2002-12-19">GpM7 
   L:         &lt;/sacred:SacredPKCS15&gt; 
   L:     &lt;/Payload&gt; 
   L:   &lt;/Credential&gt; 
   L: &lt;/sacred:DownloadResponse&gt; 
   L: </blob>  
   L: END 
 
editor: Farrell                                              [Page 19] 
INTERNET-DRAFT                                           December 2002 


    
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.>> 
    
   Open Issues:          
        - More IESG I-D nits checks no doubt 
   -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 
        - 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. 

 
editor: Farrell                                              [Page 20] 
INTERNET-DRAFT                                           December 2002 


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