Draft: draft-ietf-core-stateless

Commentary: the automated key management reference was made in error . RFC4107 is about systems like IKEv2 , TLS , etc . where a key has to be agreed upon between two ( or more nodes ) . The key needed for the encrypted state token never leaves the sender , so it can be a randomly generated key , provided that the nonce is never repeated . This text fixed the considerations for this section .
Transporting the state needed by a client to process a response as
serialized state information in the token has several significant and
non-obvious security and privacy implications that need to be
mitigated; see serialized-state for recommendations.  In addition to
the format requirements outlined there, implementations need to
ensure that they are not vulnerable to maliciously crafted, delayed,
or replayed tokens.
It is generally expected that the use of encryption, integrity
protection, and replay protection for serialized state is
appropriate.  In the absence of integrity and reply protection, an
on-path attacker or rogue server/intermediary could return a state
(either one modified in a reply, or an unsolicited one) that could
alter the internal state of the client.  It is this reason that at
least the use of integrity protection on the token is always
recommended.
It maybe that in some very specific case, as a result of a careful
and detailed analysis of any potential attacks, that there may be
cases where such cryptographic protections do not add value.  The
authors of this document have not found such a use case as yet.
RFC3610 with a 64-bit tag is RECOMMENDED, combined with a sequence
number and a replay window.  Where encryption is not needed, RFC6234,
combined with a sequence number and a replay window, may be used.
When using an encryption mode that depends on a nonce, such as AES-
CCM, repeated use of the same nonce under the same key causes the
cipher to fail catastrophically.  If a nonce is ever used for more
than one encryption operation with the same key, then the same key
stream gets used to encrypt both plaintexts and the confidentiality
guarantees are voided.  Devices with low-quality entropy sources --
as is typical with constrained devices, which incidentally happen to
be a natural candidate for the stateless mechanism described in this
document -- need to carefully pick a nonce generation mechanism that
provides the above uniqueness guarantee.  Additionally, since it can
be difficult to use AES-CCM securely when using statically configured
keys, implementations should use RFC4107.
Transporting the state needed by a client to process a response as
serialized state information in the token has several significant and
non-obvious security and privacy implications that need to be
mitigated; see serialized-state for recommendations.
In addition to the format requirements outlined there,
implementations need to ensure that they are not vulnerable to
maliciously crafted, delayed, or replayed tokens.
It is generally expected that the use of encryption, integrity
protection, and replay protection for serialized state is
appropriate.
In the absence of integrity and reply protection, an on-path attacker
or rogue server/intermediary could return a state (either one
modified in a reply, or an unsolicited one) that could alter the
internal state of the client.
It is this reason that at least the use of integrity protection on
the token is always recommended.
It maybe that in some very specific case, as a result of a careful
and detailed analysis of any potential attacks, that there may be
cases where such cryptographic protections do not add value.  The
authors of this document have not found such a use case as yet, but
this is a local decision.
It should further be emphasized that the encrypted state is created
by the sending node, and decrypted by the same node when receiving a
response.  The key is not shared with any other system.  Therefore
the choice of encryption scheme and the generation of the key for
this system is purely a local matter.
When encryption is used, the use of RFC3610 with a 64-bit tag is
recommended, combined with a sequence number and a replay window.
This choice is informed by available hardware acceleration of on many
constrained systems.  If a different algorithm is available
accelerated on the sender, with similar strength, then it SHOULD be
preferred.  Where privacy of the state is not required, and
encryption is not needed, RFC6234, combined with a sequence number
and a replay window, may be used.
For use cases where requests are being relayed from another node, the
request rate may be estimated by the total link capacity allocated
for that kind of traffic.  An alternate view would consider how many
IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate
for this use.
When using an encryption mode that depends on a nonce, such as AES-
CCM, repeated use of the same nonce under the same key causes the
cipher to fail catastrophically.
If a nonce is ever used for more than one encryption operation with
the same key, then the same key stream gets used to encrypt both
plaintexts and the confidentiality guarantees are voided.  Devices
with low-quality entropy sources -- as is typical with constrained
devices, which incidentally happen to be a natural candidate for the
stateless mechanism described in this document -- need to carefully
pick a nonce generation mechanism that provides the above uniqueness
guarantee.
RFC8613 appendix B.1.1 ("Sender Sequence Number") provides a model
for how to maintain non-repeating nonces without causing excessive
wear of flash.