Securely Available Credentials Protocol
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (30)
DIGEST-MD5 is used only inside a TLS-authenticated tunnel rather than standalone, because many user-chosen passwords are vulnerable to dictionary attacks and using DIGEST-MD5 without transport protection would allow an eavesdropper to capture material for offline attack.
SACRED XML elements are designed to be compatible with XKMS and XMLDSIG so that a SACRED implementation can easily also support XKMS, enabling reuse across credential management protocols.
The LastModified field is managed by the server (overwriting any client-supplied value) to enable conflict detection across concurrent updates from multiple platforms; clients are strongly recommended to base UploadRequests on recently downloaded credentials.
Two distinct passwords exist: an account password for authenticating to the credential server, and a credential password for decrypting the downloaded credential. This separation limits the blast radius if one is compromised.
SACRED may be implemented over non-BEEP transports provided the transport meets the security mandates in Section 2.3.1 (TLS and/or DIGEST-MD5 with appropriate authentication) before any SACRED PDUs are exchanged.
The SASL authorization identity is implementation-specific in SACRED; if used, it is not a substitute for the credential selector field but may affect authorization for access to credentials.
All credentials MUST have an associated selector unique for that account. The selector is REQUIRED for upload requests and OPTIONAL for download requests; an omitted or empty selector in a download request MUST be interpreted as a request for all stored credentials.
Credential servers MUST support TLS and DIGEST-MD5. Clients MUST support DIGEST-MD5 and TLS with server authentication.
If any change is made to stored credentials, the server MUST update the corresponding LastModified value to the current time at the server. The LastModified value in an UploadRequest MUST be the value most recently received in a corresponding DownloadResponse for that credential.
If the LastModified value in a DeleteRequest does not match the server's stored value for that credential, the server MUST NOT delete the credentials.
Implementations MUST support the PKCS #15 form of ds:KeyInfo defined in the spec (the SacredPKCS15 element) as the credential payload format.
On RemoveAccountRequest, the server MUST delete all information relating to the account and respond with an error or acknowledgement message.
Run-time operations (credential upload, download, delete) MUST be supported by all conformant implementations; account management operations are OPTIONAL.
SACRED clients SHOULD verify the TLS server per RFC 2818 Section 3.1, SHOULD include the optional BEEP serverName field in their start message, and SHOULD ensure the BEEP serverName is consistent with the TLS server checks.
The InfoResponse MUST contain at least one Realm specified, and clients MUST be able to select one from the list of Realms.
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.
The SACRED protocol SHOULD be run over port 1118. The GSSAPI service name for this protocol SHALL be 'sacred'.
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 — the DIGEST-MD5 security services (confidentiality, integrity) are not used.
Six SACRED operations are defined: Information Request (no auth), Create Account (server auth + confidentiality + integrity), Remove/Modify Account and Credential Upload/Download/Delete (all require mutual auth + confidentiality + integrity).
The Credential element contains: CredentialSelector (string identifier), Payload (ds:KeyInfo or SacredPKCS15), LastModified (server timestamp), TimeToLive (optional hint in seconds), ProcessInfo (optional server-directed data), and ClientInfo (optional client-directed data that the server MUST ignore).
The ProcessInfo field MAY be included in all messages sent to the server for extensibility or vendor extensions; the InfoResponse lists the ProcessInfo types the server supports, modeled after XKMS and XBULK extensibility.
IANA registered the BEEP profile URI 'http://iana.org/beep/sacred'. The protocol SHOULD run on port 1118. The GSSAPI service name is 'sacred'.
SACRED-specific BEEP error reply codes are defined: 555 (extension not supported), 556 (required extension not present), 557 (StaleCredential — bad LastModified value in UploadRequest). These supplement standard BEEP error codes.
A MITM attack using the SACRED account password with DIGEST-MD5 is thwarted because the DIGEST-MD5 client hash includes a client-selected 'digest-uri-value' of 'sacred/<serverName>', which would not match what a MITM server presents.
Credential servers SHOULD incorporate DoS countermeasures, including dropping inactive connections and minimizing resource use by unauthenticated connections. No specific protocol-level countermeasures against DoS are proposed.
If the server database is stolen, an attacker can launch a dictionary attack to recover account passwords and thus decrypt credentials. Server implementations SHOULD protect the database. Clients MAY use ClientInfo to store a signature over the Credential for local verification before use.
The protocol is designed to give no information to support a dictionary attack whether by eavesdropping (countered by TLS/DIGEST-MD5) or by server/client impersonation (countered by mutual authentication). DIGEST-MD5 is only used inside a TLS-authenticated pipe to prevent offline dictionary attacks from captured traffic.
BEEP session tuning follows a defined sequence: (1) peers exchange greetings; (2) TLS channel started and negotiated; (3) new greeting issued post-TLS tuning reset; (4) DIGEST-MD5 SASL channel started within the TLS pipe; (5) SACRED profile channel opened after authentication completes.
All SACRED messages are encoded as XML using the namespace 'urn:sacred-2002-12-19'. The SacredPKCS15 element carries the credential as a base64Binary value inside a ds:KeyInfo structure. The CredentialType includes CredentialSelector (string), LastModified (dateTime), and optional Payload, TimeToLive, ProcessInfo, and ClientInfo fields.
SACRED messages are transported over BEEP as 'application/beep+xml'. The BEEP profile URI is 'http://iana.org/beep/sacred'. Messages may be piggybacked during channel initialization subject to BEEP encoding and length limitations.