Add requirements for random value entropy

[randomstuff]

Several standards and other references have requirements about entropy of random values.

NIST sp800-63n:

Random values are extensively used in authentication processes, such as nonces and authentication secrets. Unless otherwise specified, random values that reference this section SHALL be generated by an approved random bit generator [RBG]4 that provides at least the minimum security strength specified in the latest revision of [SP800-131A] (112 bits as of the date of this publication).

NIST sp800-63c about Federated user ID (eg. OpenID Connect "sub" claims):

The PPI SHALL contain no identifying information about the subscriber (e.g., username, email address, employee number, etc.). The PPI SHALL be difficult to guess by a party having access to information about the subscriber, having at least 112 bits of entropy as stated in [SP800-131A]. PPIs can be generated randomly and assigned to subscribers by the IdP or could be derived from other subscriber information if the derivation is done in an irreversible, unguessable manner (e.g., using a keyed hash function with a secret key as discussed in [SP800-131A]).

OAuth 2.1 draft:

The probability of an attacker guessing generated tokens (and other credentials not intended for handling by end users) MUST be less than or equal to 2^(-128) and SHOULD be less than or equal to 2^(-160).

This would apply to challenge_verifier, OIDC nonce, generated client_secret, etc.

FAPI 2.0:

Credentials not intended for handling by end-users (e.g., access tokens, refresh tokens, authorization codes, etc.) shall be created with at least 128 bits of entropy such that an attacker correctly guessing the value is computationally infeasible. Cf. Section 10.10 of [RFC6749].

Percival's Cryptographic Right Answers (2009):

Random IDs: Use 256-bit random numbers.

Ptacek's Cryptographic Right Answers (2015):

Random IDs (Was: Use 256-bit random numbers): Remains: use 256-bit random numbers.

Latacora's Cryptographic Right Answers (2018):

Latacora, 2018: Use 256-bit random numbers.

Latacora's Cryptographic Right Answer: Post Quantum Edition (2024):

Use 256-bit random numbers. Be careful with the source though, use /dev/urandom.

DPoP:

[jti] uniqueness can be accomplished by encoding (base64url or any other suitable encoding) at least 96 bits of pseudorandom data or by using a version 4 Universally Unique Identifier (UUID) string according to [RFC4122]. The jti can be used by the server for replay detection and prevention; see Section 11.1.

Possible options:

• Add requirement in V6.3 Random Values
• Add requirement in V51 OAuth and OIDC
• Add requirement in V3 Session Management

[tghosth]

What would be the proposed change in 6.3? @randomstuff

[randomstuff]

(Added: « Add requirement in V3 Session Management »)

[randomstuff]

6.3.X Verify that randomly generated credentials (or identifiers which are intended to be hard-to guess (?)) not intended for handling by end-users have at least 128 bits of entropy. When applicable, they should have at least 256 bits of entropy.

This could apply to things like:

• Oauth client_secret
• OAuth PKCE code_verifier
• OAuth DPoP nonces
• OIDC nonce
• JWT jti (?)
• Randomly generated HMAC secrets (for example when used with JWT)
• Reference tokens (such as in cookies) when applicable

Question: Would this need to be made explicit? (eg. requirement in the OAuth chapter)

Question: What about when the credentials are not random but derived from something? Could this requirement apply as well?

---

Additional question: When using HMAC, there are additional recommendations with respect to the key entropy (you can tecnically use "123" as key but you should not …). So we need to have some guidance about that in appendix? We currently have this:

6.2.9 [ADDED] All cryptographic primitives MUST utilize a minimum of 128-bits of security, with exceptions only made for equipment or applications approaching end of life, where the requirement is at least 112-bits of security for all cryptography.

which is about cryptographic primitives but not necessarily about cryptographic material inputs (keys/secrets).

ping @danielcuthbert