RFC 3767
Securely Available Credentials Protocol
📄 RFC 3767: Securely Available Credentials Protocol 🎀
okay bestie, the title block tells us everything we need to know first 💅 This is an RFC, number 3767, called Securely Available Credentials Protocol. It was written by S. Farrell, Ed. from Trinity College Dublin, it's on the Standards Track 🌈, and it's dated June 2004. The title block doesn't have an Obsoletes or Updates line, so it doesn't list anything it replaces or amends.
Status of this Memo ⭐
this doc is an Internet standards track protocol for the whole Internet community, and it's asking everyone for discussion and suggestions for improvements 🫶. if you want to know the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. distribution of this memo is unlimited 🦋.
Copyright Notice 🌸
Copyright (C) The Internet Society (2004).
Abstract ✨
so this doc describes a protocol where a user can grab their cryptographic credentials (like private keys or PKCS #15 structures) from a credential server 🔐. the cute part is that the user can do this from a workstation that has locally trusted software installed, but that workstation has no user-specific configuration 💖. the protocol's payloads are described in XML 🧚. this memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol 🍓. the security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP) 🔥. iconic security energy, no notes 👑.
Table Of Contents 🌈
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The Protocol. . . . . . . . . . . . . . . . . . . . . . . . . 3
3. BEEP Profile for SACRED. . . . . . . . . . . . . . . . . . . . 9
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 13
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
Appendix A: XML Schema . . . . . . . . . . . . . . . . . . . . . . 17
Appendix B: An Example of Tuning with BEEP . . . . . . . . . . . . 20
Appendix C: Provision SACRED using other Protocols . . . . . . . . 23
Editor's Address . . . . . . . . . . . . . . . . . . . . . . . . . 24
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 251. Introduction ✨
okay so digital credentials, like private keys and their certificates, are what keep a bunch of Internet protocols running, like S/MIME, IPSec, and TLS 🔑. in lots of places, people want to use the same credentials across different devices, and that's so relatable 🥹. on a "typical" desktop, the user already has plenty of tools for importing and exporting these credentials 🛠️. but honestly, that's not very practical 🙄. plus, some devices (especially wireless and other more constrained ones) just don't have the tools at all 💀.
this doc describes a protocol for the secure exchange of these credentials 🔐. it's a realization of the abstract protocol framework described in [RFC3760] 🧚.
now the tea: a lot of user-chosen passwords are vulnerable to dictionary attacks 😭. so the SACRED protocol is built to give no information that an attacker could use to launch a dictionary attack 🛡️. that holds whether the attacker is eavesdropping or pretending to be the client or the server 👀.
the protocol also lets a user create or delete an account, change her account password and/or credentials, and upload the new values to the server 💅. the protocol makes sure that only someone who knew the old account password can modify the credentials stored on the credential server 🔒. the protocol doesn't rule out configuring a server to disallow some operations (for example, credential upload) for some users 🙅♀️. the account management operations, as a whole, are optional implementations for both credential servers and clients 🌷.
note that there are potentially two "passwords" involved here 🫣. the first one authenticates the user to the credential server. the second one decrypts (parts of) the credential after a download 🗝️. when the context needs it, we call the first one the account password and the second one the credential password 💜.
using a protocol like this is somewhat less secure than using a smart card 🪪. still, it can be used until smart cards and smart card readers are everywhere on workstations ✨. it can also stay useful after smart cards are everywhere, as a backup plan when a user's smart card is lost or malfunctioning 🙏.
the protocol sets out to meet the requirements in [REQS] 📋. cryptographic credentials may take the form of private keys or PKCS #15 [PKCS15] structures 🌈. a profile based on BEEP [BEEP] is specified for message transport and security (integrity, authentication, and confidentiality) 🚚. in that case, the security requirements are met by mandating support, via BEEP, for TLS [TLS] and/or DIGEST-MD5 [DIGEST-MD5] 🔐.
we assume the only authentication information the user has is a username and 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] 📖.
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 here is to define SACRED elements that are compatible with the elements used in [XKMS] and [XMLDSIG]. that means an implementation of this protocol can easily support XKMS too, and vice versa 🦋. it's also intended that other SACRED protocol instances (for example, ones 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 give the client the values it needs for account creation 💅.
the client sends an InfoRequest message, which has no content 📨.
the server responds with an InfoResponse message. it contains the authentication mechanism parameters for the server and the list of supported ProcessInfo types. for DIGEST-MD5, this is the list of realms the server supports, each one as an XML element named "Realm" 🏰. 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 (this is allowed for extensibility) 🧩.
2.1.2. Create Account 🍓
This operation REQUIRES server authentication 🔐.
the purpose of this operation is to set up a new account on the server 🌱. the info needed for a "new" account depends on the SASL [SASL] mechanism used 🧠.
the client sends a CreateAccountRequest, which contains the account name (for example, a username) 📝. it also contains the elements required to create an account for a particular authentication mechanism. the actual info is defined by that mechanism. for DIGEST-MD5, this is the password verifier (the hashed username, password and realm) plus the chosen realm 🫶. the data structures in the appendix allow more than one set of such data, but 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 then respond with an error or acknowledgement message 🫡.
2.1.4. Modify Account ✏️
This operation REQUIRES mutual authentication 🤝.
the purpose of this operation is to let the client change the information required for authentication. which info is needed depends 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 info is defined by that mechanism. for [DIGEST-MD5], it consists of a realm and a password verifier value 🌷.
once the account information has changed, 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 let the client 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 account, that credential is replaced with the new one from the UploadRequest 🔁. otherwise, a "new" credential is associated with that account 🆕. if a new credential is being uploaded, the client SHOULD include (in LastModified) its local concept of the time, if it has one, or an indicator that it has no clock ⏰. the actual value of LastModified can be anything (but the element has to be present), since the server overwrites it in any case 🫠.
if any change is made to the stored credentials for the account, 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 that was most recently received in a corresponding DownloadResponse for that credential 🎯. this means clients are strongly RECOMMENDED to only produce an UploadRequest based on recently downloaded credentials, because otherwise the LastModified value may be out of date 😬.
the LastModified value can also help detect 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 that 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 it would be unwise for a client to include the LastModified field in a ClientInfo digital signature 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 let a client get one or more credentials from a server. honestly, that's the whole point of the entire protocol 😭🫶!
the client sends a DownloadRequest message to the server, which MAY contain a credential selector string for the credential. no credential selector, or an empty one, 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. that time is when the last change was made to each credential associated with the account (for example, after an UploadRequest) 🕒✨.
2.2.3. Credential Delete 🗑️✨
This operation REQUIRES mutual authentication 🔐 Okay so the vibe here is that the client gets to delete one credential or all of them from an account 💅
The client sends a DeleteRequest message to the server. It can contain either a CredentialSelector or an All element.
If the DeleteRequest has an All element, then every single credential on that account gets deleted. All of them 💀
If the DeleteRequest has a CredentialSelector instead, the request MAY include a LastModified value. If LastModified is there, then it MUST be the value that was most recently received in a corresponding DownloadResponse for that credential. If the value doesn't 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 spell out the security requirements for each of them (where supported).
Operation Security REQUIRED
--------- -----------------
Information request NONE
Create account Server authentication,
Confidentiality, Integrity
Remove account Mutual authentication,
Confidentiality, Integrity
Modify account Mutual authentication,
Confidentiality, Integrity
Credential upload Mutual authentication,
Confidentiality, Integrity
Credential download Mutual authentication,
Confidentiality, Integrity
Credential delete Mutual authentication,
Confidentiality, IntegrityThe security requirements can be met by several mechanisms, which is so flexible 🦋 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. Implementations SHOULD also support TLS_RSA_WITH_AES_128_CBC_SHA [TLSAES]. 💜
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 for client authentication. That is, we do not use the DIGEST-MD5 security services (confidentiality, integrity etc.). Not the vibe, so it stays in its lane 🙈
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:KeyInfoor some other form of credential. Implementations MUST support the PKCS #15 form ofds:KeyInfodefined below (theSacredPKCS15element). 👑 - LastModified is a string containing the time (at the server) at which this credential was last modified.
- TimeToLive (optional) is a hint clients SHOULD honor, which specifies the number of seconds 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. Very polite group chat energy 🫶
Profile Identification: http://iana.org/beep/sacred
Messages Exchanged during Channel Creation:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
ModifyAccountRequest,
DownloadRequest,
UploadRequest,
DeleteRequest,
InfoResponse,
DownloadResponse,
error,
okMessages starting one-to-one exchanges:
InfoRequest,
CreateAccountRequest,
RemoveAccountRequest,
ModifyAccountRequest,
DownloadRequest,
UploadRequest,
DeleteRequestMessages in positive replies:
ok,
InfoResponse,
DownloadResponseMessages 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/TLSor
http://iana.org/beep/TLS followed by
http://iana.org/SASL/DIGEST-MD5Appendix 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 confidentiality 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/sacred'>
C: <![CDATA[<DownloadRequest ...>]]>
C: </profile>
C: </start>
S: <profile uri='http://iana.org/beep/sacred'>
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
I ModifyAccountRequest ok error
I DownloadRequest DownloadResponse error
I UploadRequest ok error
I DeleteRequest Ok error3.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 💅
4. IANA Considerations ✨
The IANA has registered the BEEP profile specified in Section 4.
http://iana.org/beep/sacredThe sacred protocol SHOULD be run over port 1118 🔌
The GSSAPI service name (required when using SASL) for this protocol SHALL be "sacred" 🌈
5. Security Considerations ✨
okay bestie, this section is the big one 😭🔥 the authors literally list out every vulnerability they're worried about, and then say how (or if) it gets handled. it's giving threat model realness 💅 [REQS] is the requirements doc, and it asks specs to say how they deal with the stuff listed below.
V1 💀: a passive attacker can watch every packet on the network and then run a dictionary attack later.
- the use of DIGEST-MD5 and/or TLS counters this one 🛡️
V2: an attacker pretends to be a credential server so the client spills info online that lets them dictionary attack later 🙈
- server or mutual authentication counters this vibe 💜
V3: an attacker tries to get a client to decrypt a chosen "ciphertext" and then use the plaintext. the attacker might then be able to run a dictionary attack. (example: if the plaintext from "decrypting" a random string gets used as a DSA private key, yikes 😭)
- server or mutual authentication counters this too ✨
V4: an attacker overwrites a repository entry, so when a user thinks they're using a good credential, they actually expose info about their password (and therefore 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 copies a credential server's repository and runs a dictionary attack 😤
- server implementations SHOULD take measures to protect the database 🔒
V6: an attacker pretends to be a client so the server reveals info that allows a later dictionary attack 👀
- the mutual authentication requirements of this protocol counter this to a great extent ✨. also, 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 convinces a server that a successful login happened, even though it didn't 😳
- client authentication prevents this 👑
V8 (Upload): an attacker overwrites someone else's credentials on the server 💅
- only if they already know the account password (thanks to mutual authentication) 🔐
V9 (when using password-based authentication): an attacker forces a password change to a known (or "weak") password 😬
- client authentication counters this 🫶
V10: an attacker tries a man-in-the-middle attack for lots of reasons... 🙃
- mutual authentication and 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 🌧️
ngl this is the part where the spec says "we know about this, here's what helps, and sometimes we don't have a fix" 💔
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 that dictionary attack works, the attacker can decrypt the user's credentials. An attacker who 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 fails to get the user's account password through a dictionary attack, they will be unable to upload new credentials 🥹
Credential servers SHOULD incorporate measures that 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 on 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 listed in section 3.1 of RFC 2818 [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 RFC 2818. Failing to do these checks could let a spoof server access a user's credential 😱🫣
If the SACRED account password were used in some other, less secure protocol, using DIGEST-MD5, then it might look like a man-in-the-middle (MITM) attack could be mounted. However, that's 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. So a MITM attack like this is thwarted, because digest-uri-value wouldn't match what the SACRED server is expecting 🧚✨
6. References 📚
6.1. Normative References
[BEEP] Rose, M., "The Blocks Extensible Exchange Protocol
Core", RFC 3080, March 2001.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as
a SASL Mechanism", RFC 2831, May 2000.
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard," RSA Laboratories, June 2000.
[REQS] Arsenault, A. and S. Farrell, "Securely Available
Credentials - Requirements", RFC 3157, August 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SASL] Myers, J., "Simple Authentication and Security Layer
(SASL)", RFC 2222, October 1997.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol - Version
1.0", RFC 2246, January 1999.
[TLSAES] Chown, P., "Advanced Encryption Standard (AES)
Ciphersuites for Transport Layer Security (TLS)", RFC
3268, June 2002.
[XMLDSIG] Eastlake, 3rd, D., Reagle, J. and D. Solo, "(Extensible
Mark-Up Language) XML-Signature Syntax and Processing",
RFC 3275, March 2002.
[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/6.2. Informative References
[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, May 2000.
[RFC3760] Gustafson, D., Just, M. and M. Nystrom, "Securely
Available Credentials - Credential Server Framework,"
RFC 3760, April 2004.
[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 (charliek@microsoft.com) co-authored earlier versions of this document 👑. Michael Zolotarev (mzolotar@tpg.com.au) did much of the initial work, adapting an earlier version to the use of SRP (though SRP was subsequently dropped, but much of the framework survived ✨). Marshall Rose (mrose@dbc.mtview.ca.us) helped out a lot, especially with the BEEP profile 🦋. And the following people were actively involved in the mailing list discussions leading to this document:
David Chizmadia,
Dave Crocker (dcrocker@brandenburg.com),
Lawrence Greenfield (leg+@andrew.cmu.edu),
Dale Gustafson (degustafson@comcast.net),
Mike Just (just.mike@tbs-sct.gc.ca),
John Linn (jlinn@rsasecurity.com),
Neal McBurnett (neal@bcn.boulder.co.us),
Keith Moore (moore@cs.utk.edu),
RL "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 🙃💖
Appendix A: XML Schema ✨
okay bestie, this is the schema bit 🎀 it's basically the blueprint for every SACRED message, with little "extensibility holes" where you can drop in your own stuff 🧚 the ##other wildcards are giving main character energy 💅
<?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=
"http://www.w3.org/TR/xmldsig-core/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">
<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>
<!-- remove 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>
<!-- "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>
<!-- 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>Appendix B: An Example of Tuning with BEEP 🦋
this one's a full walkthrough of tuning BEEP for authentication and confidentiality, using TLS plus SASL's DIGEST-MD5 🔥 read it like a little chat transcript: L is the listener, I is the initiator, and you can watch the whole handshake play out step by step 😭
Here is what tuning BEEP for authentication and confidentiality
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/sacred' />
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: <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: <proceed />
L: </profile>
L: END
... upon receiving the reply, the initiator starts up TLS ...
... 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/sacred' />
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 mechanism ...
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: <blob> ... </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: <blob> ... </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
... 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/sacred' />
I: <?xml version="1.0" encoding="UTF-8"?>
I: <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">
I: <CredentialSelector>
I: magnus-credentials</CredentialSelector>
I: </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/sacred' />
L: <?xml version="1.0" encoding="UTF-8"?>
L: <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">
L: <Status>Success</Status>
L: <Credential>
L: <CredentialSelector>
L: magnus-credential</CredentialSelector>
L: <LastModified>2002-11-22T00:00:08Z</LastModified>
L: <Payload>
L: <sacred:SacredPKCS15
L: xmlns:sacred="urn:sacred-2002-12-19">GpM7
L: </sacred:SacredPKCS15>
L: </Payload>
L: </Credential>
L: </sacred:DownloadResponse>
L: </profile>
L: ENDAppendix C: Provision SACRED using other Protocols 🌈
so SACRED doesn't have to live inside BEEP 🎀 it can run in a non-BEEP environment too, as long as the application protocol gets protected first, following the security stuff in Section 2.3 💖 no skipping that part, it's not optional 🙈
if your app protocol already does SASL and TLS, then the SASL and/or TLS negotiation has to finish successfully before any Sacred PDUs get exchanged 🫶 and if the app protocol doesn't do SASL at all? then it needs one or more PDUs defined to set up a SASL negotiation, and that negotiation has to happen before the Sacred PDUs start flying ✨
Editor's Address 💜
Stephen Farrell,
Distributed Systems Group,
Computer Science Department,
Trinity College Dublin,
IRELAND
Phone: +353-1-608-3070
EMail: stephen.farrell@cs.tcd.ieFull Copyright Statement 💖
Okay so, the legal bit, bestie 💅 Copyright is held by The Internet Society (2004). This document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights 🎀
The document and the info in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED 😭 That includes, but isn't limited to, any warranty that using the info here won't infringe any rights, and any implied warranties of merchantability or fitness for a particular purpose. Not giving any guarantees, periodt 💀
Intellectual Property 🦋
The IETF takes no position on whether any Intellectual Property Rights or other rights that might be claimed to cover the implementation or use of the technology in this document are valid or in scope, or on whether any license under those rights might or might not be available. It also doesn't say it has made any independent effort to find any of those rights 🙈 If you want the procedures for rights in RFC documents, check BCP 78 and BCP 79 🧚
Copies of IPR disclosures sent to the IETF Secretariat are available, along with any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use the proprietary rights. You can find all of that in the IETF online IPR repository at http://www.ietf.org/ipr 🌈
The IETF invites anyone interested to tell it about any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜
Acknowledgement 🌸
Funding for the RFC Editor function is currently provided by the Internet Society 🫶✨
📦 where this page comes from
- ietf: rfc3767 2004-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms