INTERNET-DRAFT Editor: Stephen Farrell expires in six months Baltimore Technologies September 2002 Securely Available Credentials Protocol Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes a protocol 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.................................................2 3. BEEP Profile for SACRED......................................8 4. IANA Considerations.........................................10 5. Security Considerations.....................................11 References.....................................................12 Acknowledgements...............................................13 Editor's Address...............................................14 Full Copyright Statement.......................................14 Appendix A: XML Schema.........................................14 Appendix B: An Example of Tuning with BEEP.....................17 Appendix C: Provision SACRED using other Protocols.............19 Appendix D: Changes & Open Issues..............................19 Editor: Farrell [Page 1] INTERNET-DRAFT September 2002 1. Introduction We describe a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS#15 structures) from 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. This memo also specifies a BEEP [BEEP] profile of the protocol. The protocol sets out to meet the requirements in [REQS]. In particular, security requirements in [REQS] are met by mandating support for TLS [TLS] and/or SASL-MD5 [SASL-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. 2. The protocol This section defines the account management and "run-time" operations for the SACRED protocol. It also describes the message formats used, which are based on XML. 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 Editor: Farrell [Page 2] INTERNET-DRAFT September 2002 an implementation of this protocol can easily also support XKMS, and vice versa. It is also intended that other SACRED protocol instances (e.g. using a different authentication scheme, credential format or transport protocol) could re-use many of the definitions here. 2.1 Account management operations These operations MAY be implemented, that is, they are OPTIONAL. 2.1.1 Information Request This operation REQUIRES no authentication. The purpose of this operation is to provide to the client the values required for account creation. The client sends an InfoRequest message (which has no content). The server responds with an InfoResponse message which contains the authentication mechanism parameters for the server and the list of supported ProcessInfo types. For SASL-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. 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 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 SASL-MD5 this consists of the password verifier (the hashed username, password and realm) and the chosen realm. 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. Editor: Farrell [Page 3] INTERNET-DRAFT September 2002 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 [SASL-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. The server responds with an error or acknowledgement message. 2.2 "Run-time" operations These operations MUST be supported by all conformant implementations. 2.2.1 Credential Upload This operation REQUIRES 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"" 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. Editor: Farrell [Page 4] INTERNET-DRAFT September 2002 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. 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). In the case of the upload of a new credential the client SHOULD include its best idea of the LastModified value in the credential. The server MUST replace this 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. 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 September 2002 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 SASL-MD5. Clients MUST support SASL-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 SASL-MD5 for the client, SASL-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 SASL-MD5 cryptographic 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. Editor: Farrell [Page 6] INTERNET-DRAFT September 2002 It is an error to have more than one credential stored under the same account where both have the same credential selector string. 2.3.3 Common fields The type "ds:CryptoBinary" (inherited from [XMLDSIG]) is used for almost all binary values. The value in such elements MUST be the base64 encoding of the binary value in network byte order. See [XMLDSIG] for further details and example. The exception to this is the "salt" field, which is of type base64Binary instead. The reason for this is that leading zeros are stripped from ds:CryptoBinary, which is correct in most cases, but since the salt is a direct input to a hash function, leading zeros are significant and so have to be preserved. All messages sent to the server MAY contain ProcessInfo values. This field MAY be used by other specifications or for vendor extensions. For example, a server might require clients to include a phone number in this field. The information response message contains a list of the types of ProcessInfo that the server supports. This extensibility scheme like 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. - 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). Editor: Farrell [Page 7] INTERNET-DRAFT September 2002 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 Message Semantics: c.f., Section 2 Contact Information: c.f., the editor's address section of this memo Editor: Farrell [Page 8] INTERNET-DRAFT September 2002 3.1 Profile Initialization Because all but one of the operations of the SACRED profile have security requirements (cf., Section 2.3.1), before starting the SACRED profile, the BEEP session will likely be tuned using either http://iana.org/beep/TLS or http://iana.org/SASL/SASL-MD5 (Appendix B gives an example of tuning a BEEP session using SASL- MD5). 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: C: C: ]]> C: C: S: S: ]]> S: Note that BEEP imposes both encoding and length limitations on the messages that are piggybacked during channel initialization. 3.2 Profile Exchange All messages are exchanged as "application/beep+xml" (c.f., Section 6.4 of [BEEP]): Role MSG RPY ERR ---- --- --- --- I InfoRequest InfoResponse error I CreateAccountRequest ok error I RemoveAccountRequest ok error I ModifyAccountRequest ok error I DownloadRequest DownloadResponse error I UploadRequest ok error Editor: Farrell [Page 9] INTERNET-DRAFT September 2002 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.) 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 <>. The GSSAPI service name (required when using SASL) for this protocol SHALL be "sacred". Editor: Farrell [Page 10] INTERNET-DRAFT September 2002 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 SASL-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 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). Editor: Farrell [Page 11] INTERNET-DRAFT September 2002 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 SASL-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]. References Normative: [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080. [PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax Standard," RSA Laboratories, June 2000. [REQS] Arsenault, A., Farrell, S., "Securely Available Credentials - Requirements", RFC 3157. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222. [SASL-MD5] "Using Digest Authentication as a SASL Mechanism", Leach, P., Newman, C., RFC 2831. [TLS] Dierks, T., "The TLS Protocol - Version 1.0", RFC 2246. Editor: Farrell [Page 12] INTERNET-DRAFT September 2002 [XMLDSIG] Eastlake, D., et al. "XML-Signature Syntax and Processing", RFC 3075. Informative: [DDOS] "Recommendations for the Protection against Distributed Denial-of-Service Attacks in the Internet", http://www.iwar.org.uk/comsec/resources/dos/ddos_en. htm [TRANS] Rose, M., "A Transient Prefix for Identifying Profiles under Development by the Working Groups of the IETF", 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), Eamon O'Tuathail (eamon.otuathail@clipcode.com), Magnus Nystrom (magnus@rsasecurity.com), Gareth Richards (grichards@rsasecurity.com) Of course, any and all errors remain the editor's responsibility. Editor: Farrell [Page 13] INTERNET-DRAFT September 2002 Editor's Address Stephen Farrell, Baltimore Technologies, 39 Parkgate Street, Dublin 8, IRELAND Phone: +353-1-881-6000 Email: stephen.farrell@baltimore.ie Full Copyright Statement Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 module presented in Appendix B may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Appendix A: XML Schema Editor: Farrell [Page 15] INTERNET-DRAFT September 2002 Editor: Farrell [Page 16] INTERNET-DRAFT September 2002 Appendix B: An Example of Tuning with BEEP Here is what tuning BEEP for authentication and privacy looks like using SASL and SASL-MD5: L: I: L: RPY 0 0 . 0 170 L: Content-Type: application/beep+xml L: L: L: L: L: L: END I: RPY 0 0 . 0 52 Editor: Farrell [Page 17] INTERNET-DRAFT September 2002 I: Content-Type: application/beep+xml I: I: I: END I: MSG 0 1 . 52 184 I: Content-Type: application/beep+xml I: I: I: I: ...]]> I: I: I: END L: RPY 0 1 . 170 783 L: Content-Type: application/beep+xml L: L: L: ...]]> L: L: END I: MSG 1 0 . 0 559 I: Content-Type: application/beep+xml I: I: ... I: END L: RPY 1 0 . 0 429 L: Content-Type: application/beep+xml L: L: ... L: END I: MSG 1 1 . 559 82 I: Content-Type: application/beep+xml I: I: ... I: END L: RPY 1 2 . 429 66 L: Content-Type: application/beep+xml L: L: L: END ... successful transport security negotiation ... L: RPY 0 0 . 0 127 L: Content-Type: application/beep+xml L: L: L: L: L: END I: RPY 0 0 . 0 52 I: Content-Type: application/beep+xml I: Editor: Farrell [Page 18] INTERNET-DRAFT September 2002 I: I: 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 <> Open Issues: -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 SASL-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:-) Editor: Farrell [Page 19] INTERNET-DRAFT September 2002 -02: - Changes as per mailing list discussion: - deleted (previous) section 2.4: session mgt & added sec. cons about DoS - Applied changes from the following threads: - "BEEP adjustments" - "MultipleCredentials" - "SRP adjustments" - "LastModified" - Other changes: - clarified how UploadRequest can delete one or more credential payloads - merged sections 2 and 3 since its much clearer that way - changed Credential structure about a bit due to moving LastModified -01: Changes as per mailing list discussion: - Change from authors to editor + acks - Included resolved comments from list: - password -> account pwd or cred pwd as appropriate - account mgt separated and optional - added example beep tuning - selector: no default, omit in d/l means all - changed LastModified scheme as per list comments - Excluded administrative operations (was an open issue) - Demoted hashed(username) concept to a note under security considerations (see V11). - Dropped idea of specifying a mapping between SRP id and cTLS certificate. - Dropped xkms & xbulk as normative references, but copied some stuff from them. -00: This version is adapted from draft-ietf-SACRED-protocol-beep- pdm-00.txt, the main changes are: - PDM -> SRP &/or TLS - Payload security -> SASL or TLS - Dropped username hashing - Dropped away-from-home Editor: Farrell [Page 20]