RFC 3760
Securely Available Credentials (SACRED) - Credential Server Framework
🎀 RFC 3760: Securely Available Credentials (SACRED), Credential Server Framework 🎀
- RFC number: 3760
- Authors: D. Gustafson (Future Foundation), M. Just (Treasury Board of Canada), M. Nystrom (RSA Security) 💅
- Category: Informational 🧚
- Date: April 2004 🌸
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🦋
This is the Network Working Group's framework for a credential server, the SACRED one. It's a whole vibe for moving your keys and certs between devices, so it's giving roaming-user energy 🌈
Status of This Memo
okay so this memo is for information only, like it's giving FYI for the internet community 💖 It is not a standard of any kind, and it can be distributed as much as you want ✨
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. 🫶
Abstract
okay bestie, the number of devices connecting to the internet keeps climbing, and there are more and more types of them too 😭 That means credential mobility is becoming a real issue for IETF standardization 💜 This doc answers the requirements on protocols for secure credential exchange that are listed in [RFC3157], and it does that by laying out an abstract protocol framework 🦋
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Functional Overview. . . . . . . . . . . . . . . . . . . . . . 2
2.1. Definitions. . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Credentials. . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Network Architecture . . . . . . . . . . . . . . . . . . 5
3. Protocol Framework . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Credential Upload. . . . . . . . . . . . . . . . . . . . 8
3.2. Credential Download. . . . . . . . . . . . . . . . . . . 10
3.3. Credential Removal . . . . . . . . . . . . . . . . . . . 11
3.4. Credential Management. . . . . . . . . . . . . . . . . . 12
4. Protocol Considerations. . . . . . . . . . . . . . . . . . . . 12
4.1. Secure Credential Formats. . . . . . . . . . . . . . . . 12
4.2. Authentication Methods . . . . . . . . . . . . . . . . . 13
4.3. Transport Protocol Suites. . . . . . . . . . . . . . . . 16
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 17
5.1. Communications Security. . . . . . . . . . . . . . . . . 17
5.2. Systems Security . . . . . . . . . . . . . . . . . . . . 18
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Normative References . . . . . . . . . . . . . . . . . . 20
6.2. Informative References . . . . . . . . . . . . . . . . . 20
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21
8. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 221. Introduction ✨
okay so digital credentials like private keys and their certificates are what keep a bunch of Internet protocols running, think S/MIME, IPSec, and TLS 🔐 A lot of end users want to use the same credentials across different end-user devices 📱💻 On a "typical" desktop, you already have plenty of tools to import and export these credentials, but ngl that's not very practical 🙈 Also, on some devices, especially wireless and other more constrained ones, the tools you'd need just don't exist 💀
So this document puts forward a general framework for secure credential exchange 🌸 It's a high-level outline meant to guide the development of one or more SACRED (securely available credentials) credential exchange protocols 💖
2. Functional Overview 🦋
the requirements for SACRED are fully described in [RFC3157] 📜 These requirements assume that two very different network architectures will be built to support credential exchange for roaming users:
a) Client/Server Credential Exchange 🫶 b) Peer-to-Peer Credential Exchange 🧚
This document describes the framework for one or more client/server credential exchange protocols, so the peer-to-peer one is not the focus here 👑
In every case, adequate user authentication methods will be used so credentials are not divulged to unauthorized parties 🔒 Also, adequate server authentication methods will be used to make sure each client's authentication information (see Section 2.1) is not compromised, and so that roaming users are interacting with the intended, authorized credential servers 🫣
2.1. Definitions 💜
this section gives definitions for a few terms and phrases that show up all over this document 📖
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in [RFC2119]. 🧠
- client authentication information: the info the client presents to a server to authenticate itself 🪪 This can include a password token, a registration string that may have been received out-of-band (and possibly used for initially registering a roaming user), or data signed with a signature key that belongs to the client (e.g., as part of TLS [RFC2246] client authentication) 🔑
- credentials: cryptographic objects and related data used to support secure communications over the Internet ✨ Credentials may consist of public/private key pairs, symmetric keys, X.509 public key certificates, attribute certificates, and/or application data 📦 Several standardized formats for representing credentials exist, e.g., [PKCS12], [PKCS15] (see "secured credentials" below) 📚
- passkey: a symmetric key derived from a password 🗝️
- password: a string of characters that only a client knows, used for authenticating to a server and/or securing credentials 🤫 A user may be required to remember more than one password 🙃
- password token: a value derived from a password using a one-way function, which a client can use to authenticate to a server 🪙 For example, a password token may be derived from a password using a one-way hash function 🔐
- secured credentials: a set of one or more credentials that have been cryptographically secured, e.g., encrypted/MACed with a passkey 🥹 Secured credentials may be protected with more than one layer of encryption. For example, the credential is secured with a passkey that corresponds to a user's password, and also with a key that only the server knows (the credential's stored form) 🧁 During network transfer, the passkey-protected credential may get an additional encryption layer using a symmetric key chosen by the Credential Server (the transmitted form) 🚀
- strong password protocol: a protocol that authenticates clients to servers securely (see, e.g., [SPEKE] for a more detailed definition) 💪 The client only needs to memorize a small secret (a password) and carries no other secret information, and the server carries a verifier (password token) that lets it authenticate the client 🫡 A shared secret is negotiated between client and server and is used to protect data exchanged afterward 🌟
Note the difference between an "account password" and a "credential password." 👀 An account password (and its corresponding password token) is used to authenticate to a Credential Server and to negotiate a key that gives session-level encryption between client and server 🎟️
A credential password is used to derive a passkey, and that passkey provides persistent encryption and authentication for a stored credential 🗄️ Applicable secured credential standards documents (e.g., [PKCS15]) describe the technical details of specific password-based encryption (pbe) techniques used to protect credentials from unauthorized use 🛡️
Even though the same password value can be used for both services, it's likely that different, algorithm-specific passkeys would be generated from that password (i.e., because of different salt values, etc.) 🧂
And although it may be more convenient for a user to remember just a single password, differing security policies (e.g., password rules) between the credential server and the credential issuers may mean a user ends up having to remember multiple passwords 😩🎀
2.2. Credentials 🌷
this document is all about the secure exchange and online management of credentials in a roaming or mobile environment 🌍 Credentials MAY be usable with any end-user device that can connect to the Internet, such as:
- desktop or laptop PC 💻
- mobile phone 📱
- personal digital assistant (PDA) 🪩
- etc. 💅
The end-user system may, optionally, store its credential information on special hardware devices that give enhanced portability and protection for user credentials 🔐
Since a credential usually holds sensitive information that only the credential holder should know, credentials MUST NOT be sent in the clear during network transmission 🚫 and they SHOULD NOT be in the clear when stored on an end-user device, like a diskette or hard drive 🥺 That's why a secured credential is defined 🫶 Throughout this document we assume that, at least from the protocol's point of view, a secured credential is an opaque data object (at least partially privacy- and integrity-protected) that a network-connected device can use 🧩 Once it's downloaded, clients must be able to recover their credentials from this opaque format 🔓
At a minimum, every supported credential format SHOULD provide privacy and integrity protection for private keys, secret keys, and any other data objects that must be protected from disclosure or modification ⚠️ Usually these security capabilities are part of the basic credential format, so the credential (e.g., a data file) stays protected when it's on hard drives, flexible diskettes, and so on 💾
During network transmission, the secured credential gets a second (outer) encryption layer 🎁 That outer layer uses a session-level encryption key that was derived during the mutual authentication process ✨ Effectively, secured credentials travel through an "encrypted tunnel," which adds another layer of privacy protection for the credentials (and any other information exchanged) 🚇💖
2.3. Network Architecture 🏗️✨
okay so this part is literally the blueprint of how everything fits together, bestie 💅 there's a little diagram that shows the pieces of the SACRED client/server framework, and it's giving very "who talks to who" energy 🦋
+--------+ +------------+
| Client +-----------| Credential |
+--------+ 1 | Server |
\ +-----+------+
\ |
\ | 2
\ |
\ 3 +-----+------+
-----------| Credential |
| Store(s) |
+------------+So there are a few main characters 👑
Client 🎀 - the entity that wants to grab its credentials back from a credential server.
Credential Server 🔐 - the server that downloads secure credentials to the client and uploads them from the client. This one is the bouncer 🫶 It has to authenticate the client so the secured credentials only go to an appropriate end user. And the credential server gets authenticated to the client too, so the client's auth info doesn't get compromised and the user can actually trust the credentials they get back. Mutual vibes, fr fr 🥰
Credential Store 🗄️ - the repository where secured credentials live. Access control features might exist here, but ngl those usually aren't enough by themselves to keep credentials safe 🙈 The credential server can split credentials across multiple credential stores for redundancy, or for extra protection on user credentials. Main character redundancy 💜
Now the protocols, which are the actual conversations happening 🗣️
Protocol 1 🦋 - the protocol used to authenticate the client and credential server, and to download and upload user credentials from a credential server.
Protocol 2 🌸 - the protocol the Credential Server uses to store and retrieve user credentials (LDAP, LDAP/SSL, or other).
Protocol 3 ⭐ - the protocol the client uses to store and retrieve user credentials from the credential store (LDAP, LDAP/SSL, or other).
This framework is only describing the high level design for protocol 1 ✨ Protocols 2 and 3 are closely related but out of scope for this document 🙃 They could be built on standard stuff like LDAP or secure LDAP, or other standard or proprietary protocols. Also, any administrator-credential server protocols are assumed to be server vendor specific and aren't part of SACRED standardization efforts at this time 💀
Clients are not precluded from exchanging credentials directly with a credential store (or any other server of its choosing) 🧚 Totally allowed! But mutual authentication with roaming users, plus a consistent level of protection for credential data both while it's stored on network servers and while it's in transit, is provided by SACRED protocols exchanged with the credential server 🔥 Depending on how the credential server is designed, user credentials may flow through the credential server to the credential store, or go directly between the client and the credential store. It's giving flexibility 🌈
Also, users may upload their credentials to several credential servers for enhanced availability 💖 Coordination (automatic replication) of user information or credential data among several credential servers is currently beyond the scope of this document 🙈
- Protocol Framework 🧚♀️✨
This section gives a high level description of the client/server protocols that can be used to exchange and manage SACRED credentials. Let's gooo 🚀
The client/server credential exchange protocol is based on three basic and abstract operations: "GET", "PUT", and "DELETE" 💅 The secured credential exchange plays out like this:
connect 📞 - the client starts a connection to a credential server so it can securely exchange credentials.
mutual authentication/key negotiation 🤝 - using a strong password protocol (or equivalent), the client authenticates to the server, the server authenticates to the client, and a session level encryption key gets negotiated. The exact details of the mutual authentication exchange depend on which authentication method is used. Either way, the end result is that the client is authenticated to the server and the server is authenticated to the client, and they've established a strong, shared secret between them 😭
client request(s) 💌 - the SACRED client issues one or more high level credential exchange requests (e.g., GET, PUT, or DELETE).
server response(s) 📬 - the SACRED credential server responds to each request, either performing the operation successfully or indicating an appropriate error.
close 🌙 - the client says it has no more requests for the server right now. The security context between client and server is no longer needed. Close is a logical, session management operation, not a network thing 💜
disconnect 👋 - the parties disconnect the transport level connection between client and server. Note that "connect" and "disconnect" are logical, transport-layer dependent operations that wrap around the protocol exchange between the two communicating processes 🦋
Each high-level credential exchange operation is made up of a series of request-response pairs 🍓 The client always initiates each request, and the server processes it before sending back an appropriate response. Each request MUST complete (the server reports success or failure) before the client issues the next request. The server SHOULD be willing to service at least one upload or download request following successful mutual authentication, but either party can terminate the logical connection at any time 🫶
In the following sections, secured credentials and related values are written using this notation 📝
SC-x 🔒 is the secured credential file. It includes a format identifier field and credential data. The credential data is an opaque, encrypted data object (e.g., PKCS#15 or PKCS#12 file). The format identifier is needed so the credential data can be parsed correctly 🧠
Name-x 🏷️ is an account-defined selector or locator (a user friendly name) used to indicate a specific secured credential. The name of each credential stored under a given user account MUST be unique, e.g., there may be one credential called "financial" and another called "healthcare", etc. At a minimum, credential names MUST be unique across a given account/user name. When no name is supplied for a GET operation, all credentials stored for the given username will be returned 🌸
ID-x 🔖 is a distinct credential version indicator that MAY be used to request a conditional GET/PUT/DELETE operation. This credential-ID value SHOULD contain the server's "last-modified" date and time (e.g., the time that this particular credential version was stored on the server), and MAY contain additional information such as a sequence number or a (complete or partial) credential fingerprint that is used to make sure the credential-ID is unique from other credential versions stored under the same user account and credential name ⭐
All named credentials may be accessed by authenticating under a single username 🔑 If a user needs or prefers to use more than one distinct authentication password (and/or authentication method) to protect access to several secured credentials, they SHOULD register those credentials under distinct user/account names, one for each different authentication method used 💜
3.1. Credential Upload 📤
The purpose of a credential upload operation is to let a client register new credentials, or replace currently stored ones (e.g., credentials that may have been updated by the client using appropriate key management software) 🎀
The framework for the credential upload, as implemented using the PUT operation, goes like this:
- The client and server establish a mutually authenticated session and negotiate a shared secret 🤝
- The client then issues a PUT message that contains the upload credential and related data fields 📮
- The server responds to the PUT, indicating either that the credential was successfully stored on the server or that an error occurred ✅
The client's PUT request MAY contain an optional identifier (credential-ID) field. If it's present, the new credential will only be stored if a credential with the same name and credential-ID is currently stored on the server (e.g., a logical REPLACE operation is performed). The server MUST return an error if a client attempts to replace a credential that does not exist on the server 🙅♀️
The credential server's response to a PUT request MUST contain a credential version identifier (credential-ID) for the newly stored credential. Clients MAY use this to optimize subsequent download operations and avoid credential version mismatches 🧩
3.1.1. Credential Upload Protocol Sequence 🎬
The following is an example of a "credential upload" protocol sequence 👀
client server
------- -------
< connect > -->
<--- mutual authentication --->
< PUT SC-1, Name-1, [ID-1] > -->
<-- < Name-1, new-ID-1 >
< PUT SC-2, Name-2, [ID-2] > -->
<-- < Name-2, new-ID-2 >
...
< close > -->
<-- OK (+ disconnect)new-ID-x is the credential-ID of the newly stored credential 🌈
3.2. Credential Download 📥
Roaming clients can download their credentials at any time after they've been uploaded to the server 🧚
The framework for a credential download, as implemented using the GET operation, goes like this:
- The client SHOULD authenticate the server 🔐
- The user MUST be authenticated (by the server) 🙋♀️
- A GET request for the credential download is issued 💌
- The response contains the credential and format identifier 🎁
The specific user credential being requested may be identified by name in the message sent to the credential server. If successful, the response MUST contain the requested credential data element (format ID and data) as defined above ✨
If the user issues a GET request with a NULL credential name field, the server SHOULD return all credentials stored under the current user account 🫧
Optionally, the client MAY include a credential-ID to indicate a conditional download request. In this case, the server will return the requested credential if and only if the ID of the credential currently stored on the server does NOT match the ID specified 🙌
The server should return either the requested credential or a distinct response indicating that the conditional download was not performed (e.g., the client already has a copy of this exact credential) 💖
3.2.1. Credential Download Protocol Sequence ✨
Okay, here's a little example of a "credential download" protocol sequence 💖
client server
------- --------
< connect > -->
<--- mutual authentication -->
< GET Name-1, [ID-1] > -->
<-- < SC-1, ID-1' >
< GET Name-2, [ID-2] > -->
<-- < GET response >
...
< close > -->
<-- OK (+ disconnect)Notice how the second request comes back with no credential 👀 Because the ID-2 the client sent matched the identifier for the Name-2 credential, the server has nothing new to send. Main character behavior 💅
3.3. Credential Removal 🗑️
Here's the framework for credential removal, the way it works with the DELETE operation:
- First, the credential server MUST be authenticated (by the client) using a method-dependent protocol sequence. Server check first 🔐
- Then the user MUST be authenticated (by the server) using a method-dependent protocol sequence. 🫶
- After that, the user sends a DELETE request message containing the credential name, so the server knows which credential to remove. 💀
- Optionally, the client may include a credential-ID in the DELETE request. If it does, the credential only gets deleted when the request ID matches the ID of the credential currently stored on the server. The client might do this to make sure someone who wants to delete their stored credential doesn't accidentally delete a different version of it 🙈
3.3.1. Credential Removal Protocol Sequence 🎀
Here's an example of a "credential removal" protocol sequence:
client server
------- --------
< connect > -->
<-------- mutual authentication -------->
< DEL Name-1, [ID1] > -->
<-- < Name-1 deleted >
< DEL Name-2, [ID2] > -->
<-- < Name-2 deleted >
...
< close > -->
<-- OK (+ disconnect)3.4. Credential Management 📋
Quick reminder: those three operations from above (GET, PUT, DELETE) can be used to handle the basic credential management stuff:
- add a new credential on the server,
- update (replace) an existing credential, and
- delete an existing credential.
These basic ops might also help guide the design of fancier features like user registration (add account), user deregistration (remove account), change account password, or list all credentials. The possibilities are giving 🌈
Also, heads up 🚨: if a credential with the same name already exists on the server, uploading a NULL credential is logically the same thing as removing the one that was stored before.
4. Protocol Considerations 🧩
4.1. Secure Credential Formats 🔐
So a credential made on one device can be downloaded and used on literally any other device, we need a single "mandatory to implement" credential format that every conforming client implementation must support 🫶
There are at least two well-defined credential formats out there right now: [PKCS12] and [PKCS15].
Other optional formats may be supported too if needed. For example, extra formats could be defined for specific (compatible) client devices.
Every credential format MUST provide adequate privacy protection for user credentials when they're stored on flexible diskettes, hard disks, etc. Non-negotiable 🔒
Throughout this doc, the credential is treated as an opaque (encrypted) data object, so the credential format doesn't change the basic credential exchange protocol. 🧁
4.2. Authentication Methods 🛡️
Authentication is so important 😭 It makes sure credentials only get accepted from and delivered to the authorized end user. If an unsecured credential gets delivered to some other party, it may be way easier to compromise. If a credential gets accepted from an unauthorized party, the user might be tricked into using a credential that an attacker swapped in (e.g., an attacker might replace a newer credential with an older credential belonging to the same user). Yikes 💀
Ideally, the list of authentication methods should be open ended, so new methods can be added as needs are identified and as they become available. For all credentials, the user authentication method and data is set when a user is first registered with the credential server, and the authorized user may update it from time to time after that.
To protect user credentials from unauthorized disclosure or modification in a roaming environment, all SACRED authentication methods MUST provide protection for user credentials in network environments where attackers might try to exploit potential security vulnerabilities. Check out SACRED Requirements [RFC3157], Section 3.1, Vulnerabilities 👀
At a minimum, each SACRED authentication method SHOULD ensure that:
- The server authenticates the client ✅
- The client authenticates the server ✅
- The client and server securely negotiate (or derive) a cryptographically strong, secret key (e.g., a session key). 🔑
- The exchange of one or more user credentials is protected using this session key. 🔒
It's expected that all SACRED client/server protocols will provide each of these basic security functions. Some existing authentication protocols that might be used for this include:
- Strong password protocols
- TLS
Sections 4.2.1 and 4.2.2 give some guidance on when to use these methods, based on the generic security capabilities they provide and the security elements (passwords, key pairs, user certificates, CA certificates) that must be available to the SACRED client. 📚
4.2.1. Strong Password Protocols 🔑
Strong password protocols such as those described in [RFC2945], [BM92], [BM94], and [SPEKE] MAY be used to provide mutual authentication and privacy for SACRED protocols.
All strong password protocols require that user-specific values (i.e., a passtoken and related values) be configured within the server. Only a party who knows the password can calculate the verifier value. It must be securely delivered to the server at a time when the client sets up a relationship with the server. At connect time, messages go back and forth between the two parties, and complementary algorithms compute a shared common value known only to the legitimate user and the server. Both parties then derive a strong (symmetric) key that may be used to secure communications between them.
4.2.2. TLS Authentication 🌊
TLS authentication may either be mutual between the client and server, or unilateral, where only the server is authenticated to the client. These options are covered in the next two subsections.
In both cases, TLS can be used to authenticate the server whenever the TLS client has been pre-configured with the necessary certificates needed to validate the server's certificate chain (including revocation status checking).
TLS Server Authentication (sTLS)
TLS gives you a basic secure session capability (sometimes called server-side TLS), where the client authenticates the server and a pair of session level encryption keys is securely exchanged between client and server. After server authentication and security context setup, all client requests and server responses are integrity and privacy protected. 🔐
Protocol designers and implementors should know that the flexibility of certificate-based TLS server authentication creates security risks that need to be mitigated. Specifically, they need to make sure the user is connected to the intended credential server (secure site), and no other. The TLS v1.0 standard [RFC2246] lays out the basis for managing this risk in section F.3 (see also Section 5.2 in this document):
"Implementations and users must be careful when deciding which certificates and certificate authorities are acceptable; a dishonest certificate authority can do tremendous damage." 😱
Note also that a faulty implementation of (increasingly complex) TLS server certificate chain processing, by the SACRED client, could lead to similar compromise, allowing successful credential server masquerade or man-in-the-middle attacks. Scary stuff 🙈
An engineering approach that gives an enhanced or augmented server authentication method may be warranted for SACRED protocol designs. It's also important to understand that simply layering independently developed security protocols (e.g., using BEEP or similar layering techniques) produces a complex, multilayer security protocol. That might be easily defeated by a combination-specific attack that exposes and exploits known weaknesses of the individual protocol(s).
When necessary, and after a TLS session has been set up between the two parties, the credential server can request that the client provide her user id and password information to authenticate the remote user. Ideally, client and server can cooperate to do an authentication operation that lets the server authenticate the client (and perhaps vice-versa) in a "zero knowledge manner". In those cases, the client doesn't need to have a security credential. 🧠
TLS with Client Authentication (cTLS)
TLS provides an optional, secure session capability (sometimes called client-side TLS), where the TLS server can request client authentication by verifying the client's digital signature.
To use cTLS for mutual authentication, the client must also be configured with at least one security credential that is acceptable to the TLS server for remote client authentication purposes.
4.2.3. Other Authentication Methods ✨
Other authentication methods that provide the necessary security capabilities MAY also be suitable for use with SACRED credential exchange protocols.
4.3. Transport Protocol Suites 🚚
It's intended that one or more underlying protocol stacks may carry the SACRED credential exchange protocols. It's recognized from the start that using several underlying protocol suites, although not ideal from an interoperability standpoint, may well be required to cover the wide variety of needs anticipated.
The SACRED list members have discussed several protocol suites on their technical merits, each with distinct benefits and protocol design/implementation costs. Among these protocols are:
- TCP
- BEEP
- HTTP
All protocol suites listed here depend on TCP to provide a reliable, end-to-end transport layer protocol. Each of these building block approaches handles the remaining application layer issues in a different way (basic session management, session level security, presentation/formatting, application functionality). 💜
4.3.1. TCP ✨
okay so the first option is basically: skip the fancy layers and build a custom SACRED credential exchange messaging protocol that plugs straight into a TCP connection/socket 🧦 the big glow-up here is that you get exactly the functionality you need and nothing extra, no bloat 💅 and most server and client dev environments already ship the socket-level API you'd need, so it's lowkey easy to get going 🫶
4.3.2. BEEP
this one builds on the Blocks Extensible Exchange Protocol (BEEP) from [RFC3080] 🦋 BEEP is a general purpose, peer-to-peer message exchange thing that works over several transports, as long as someone has defined the transport layer mappings for TCP, TLS, and friends. see also [RFC3081] for the TCP mapping 💜
and the best part? BEEP already gives you the user authentication, session security, and session management stuff that SACRED credential exchange operations need, so you're not reinventing the wheel 🎀 iconic behavior
4.3.3. HTTP
this approach builds on the Hypertext Transport Protocol (HTTP) from [RFC1945] and [RFC2616] 🌸 HTTP gives you general purpose typing and negotiation of data representation, which means you can build systems independently of the data objects being transferred. it's giving flexible 🧚 plus HTTP support is everywhere: server and client platforms, and portable devices for roaming environments too (laptops, PDAs, mobile phones, all of it) 📱
HTTP runs over TCP and can optionally use TLS for authenticated, session level security 🔐 whenever TLS is supported, either or both of the TLS authentication options, sTLS or cTLS, may be used. you get to pick ✨
5. Security Considerations ✨
okay this part is SERIOUS bestie 😭 these are the general observations and precautions to keep in mind for any framework that supports credential mobility. when you design or implement a protocol for this framework, you need to recognize these security considerations, and you should also go check out the security considerations in the SACRED Requirements document [RFC3157] 🔥 no skipping this one
5.1. Communications Security
a SACRED PDU carries information about client or server authentication, or about communicating credentials 🧾 that stuff is exposed to the traditional security concerns listed below, so pay attention 👀
5.1.1. Confidentiality
the password or password verifier should be protected when it's sent from the client to the credential server 🔒 the value that gets sent should be resistant to a dictionary attack, no exceptions 💀
same deal for the entity credentials: they must be confidentiality protected when they go from the client to the server, and the other way around too 💜 and that communicated value should also resist a dictionary attack 🙅♀️
5.1.2. Integrity
communication integrity between the client and the credential server is required 🛡️ this way, the operations a client intended can't be altered (like turning an update into a deletion of credentials), and clients can't be maliciously handed "old" credentials (say, an attacker replaying an earlier credential download) 😤 integrity is non-negotiable, periodt
5.1.3. Entity Authentication
proper authentication of the client and the server is required to get communication confidentiality and integrity 🫶
the server must properly authenticate the client, so credentials don't get mistakenly revealed to an attacker 🚫 and the client must make sure it has properly identified the credential server, so it doesn't reveal its password to an attacker 😱 these goals can be met implicitly with a strong password-based protocol, or explicitly. if the server gets identified explicitly, the user or client has to make sure the user password is conveyed to a trusted server. one way to do that is installing the appropriate trusted key(s) in the client 🔑
5.1.4. Non-repudiation
there are no requirements on the SACRED protocol itself to support non-repudiation 🙈 the context where the credentials are being used might have those requirements though, so keep that in mind ✨
5.2. Systems Security
systems security is all about protecting the protocol endpoints (the client and server) and the information the server stores to support the SACRED protocol 🏰 main character energy for the server side
5.2.1. Client Security
as with most security protocols, secure use of the client often depends partly on the user behaving securely 🥺 for a password-based SACRED protocol, users should be educated, or made to follow policy, to choose passwords with a reasonable amount of entropy 🧠 users should also be made aware of how important it is to protect their account password's confidentiality 🔐
the client interface should also be designed to stop "shoulder surfing," where an attacker watches the password being typed 👀 this is usually handled by not echoing the exact characters of the password as they're entered 🫣
the interface should also nudge users to enter their password into the right field, so the protections can be properly enforced 💅 for example, a user should be guided not to type their password into the "username" field, because it'd likely be echoed to the screen there and might not be encrypted when sent to the server 😭 this can be handled by automatically filling in the user name, or offering a few user name choices in the right on-screen dialog field 🎀
5.2.2. Client Security, TLS Server Authentication
when TLS is used as the SACRED transport protocol, the client interface should let the user verify they're connected to the intended credential server 🔍 for example, client software should visually display identifying parts of the TLS server's X.509 certificate, like the server's name, the certificate fingerprint, and so on 📜
users should be guided to check this info regularly, so trusted credential servers are easy to recognize ✨ and they should also be made aware of how important it is to verify their credential server's identity before starting any credential exchange operations 🚨
A SACRED client SHOULD only be configured with those SACRED trust anchors that are to be used by the client. Re-use of trust anchors from other applications, e.g., Internet browsers is NOT RECOMMENDED. 💀 translation: don't borrow trust anchors from your browser, bestie
5.2.3. Server Security
password verifiers and user credentials must get a high level of protection at the credential server 🏰 on top of salting and super-encrypting each one (to resist offline dictionary attacks), a system should make sure the credential server keys are protected with sufficient procedural and physical access controls 🔒
the login to the credential server should be resistant to replay attacks 🛑
online attempts to access a particular user account should be controlled, or at least monitored 👀 control might mean adding a time delay after a number of unsuccessful logins to a particular account, or locking the account altogether 🔐 another option is to log the unsuccessful attempts and produce an administrative notice once a threshold of failed credential access attempts is reached 🚩
5.2.4. Denial of Service
like most protocols, Denial of Service (DoS) issues need to be considered too 🌩️ for SACRED, most DoS issues are the underlying transport protocol's problem, but some concerns can still be mitigated 🛡️
a user might get denied service if their account gets locked after too many failed logins, so protecting against online attacks (as described above) has to be considered 😬 proper user authentication should also ensure an attacker can't maliciously overwrite a user's credentials 🙅♀️ and credential servers should be wary of repeated logins to a particular account (which can also point to a possible security breach, as described above), or of abnormal volumes of requests across a number of accounts (which might mean a DoS attack) 🚨
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3157] Arsenault, A. and S. Farrell, "Securely Available
Credentials - Requirements", RFC 3157, August 2001.6.2. Informative References
[BM92] Bellovin, S. and M. Merritt, "Encrypted Key Exchange:
Password-based protocols secure against dictionary
attacks", Proceedings of the IEEE Symposium on Research in
Security and Privacy, May 1992.
[BM94] Bellovin, S. and M. Merritt, "Augmented Encrypted Key
Exchange: a Password-Based Protocol Secure Against
Dictionary Attacks and Password File Compromise, ATT Labs
Technical Report, 1994.
[PKCS12] "PKCS 12 v1.0: Personal Information Exchange Syntax", RSA
Laboratories, June 24, 1999.
[PKCS15] "PKCS #15 v1.1: Cryptographic Token Information Syntax
Standard", RSA Laboratories, June 2000.
[RFC1945] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol-- HTTP/1.0", RFC 1945, May 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frysyk, H., Masinter,
L., Leach, M. and T. Berners-Lee, "Hypertext Transfer
Protocol - HTTP/1.1", RFC 2616, June 1999.
[RFC2945] Wu, T., "The SRP Authentication and Key Exchange System",
RFC 2945, September 2000.
[RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core",
RFC 3080, March 2001.
[RFC3081] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[SPEKE] Jablon, D., "Strong Password-Only Authenticated Key
Exchange", September 1996.7. Authors' Addresses 🎀
Dale Gustafson Future Foundation Inc.
EMail: degustafson@comcast.net
Mike Just Treasury Board of Canada, Secretariat
EMail: Just.Mike@tbs-sct.gc.ca
Magnus Nystrom RSA Security Inc.
EMail: magnus@rsasecurity.com
8. Full Copyright Statement 💜
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
This document and the information contained herein 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, 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.
Intellectual Property ✨
okay bestie, so the IETF is not taking a side on whether any patents or other IP rights that might cover the tech in this doc are valid, or how far they reach 🙈 It also isn't saying whether licenses for that stuff are available or not, and it hasn't gone digging for any rights itself. If you want the rules on rights for RFC docs, go check BCP 78 and BCP 79 💅
if you need copies of IPR disclosures sent to the IETF Secretariat, any license assurances, or the results of anyone trying to get a general license or permission for implementers or users, you can find them in the IETF online IPR repository at http://www.ietf.org/ipr 🗂️✨
and the IETF is literally inviting anyone to speak up 📣 If you know about copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard, tell them! Send it to ietf-ipr@ietf.org 💌 the IETF really wants to hear it 🫶
Acknowledgement 🎀
funding for the RFC Editor function is currently provided by the Internet Society 🌈🍓 and honestly, that's so important, because somebody has to keep all these RFCs organized and published for everyone 👑💖
📦 where this page comes from
- ietf: rfc3760 2004-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms