Security Considerations - nonce explanation
siethower opened this issue · comments
Comment from Toerless to section 10
2791 10.1. Denial of Service (DoS) Attack on Pledge
2793 Disrupting the pledge behavior by a DoS attack may prevent the
2794 bootstrapping of the pledge to a new domain.
2796 A DoS attack with a faked registrar-agent may block the bootstrapping
2797 of the pledge due to state creation on the pledge (the pledge may
2798 produce a voucher-request, and refuse to produce another one). One
2799 mitigation may be that the pledge does does not limited the number of
2800 voucher requests it creates until at least one has finished, or a
2801 single onboarding state may expire after a certain time.
The way i remember, the nonce is really only meant to protect against replay
attack from e.g. a prior owner: Owner generates voucher, then sells box,
new owner takes ownership with new voucher, then sneaky prior owner re-owns
pledge (after some partial reset) with prior voucher and then gains access
to some not-fully reset information about the second owner on the pledge.
The way to protect against this is IMHO to simply not issue new nonce values for
every voucher request thats is triggered, but only to generate a new nonce
after the pledge is presented with a successful voucher for the prior
nonce. and remember the prior nonce value as "do-not-reuse". For example
by having a persistent (e.g.: TPM based) RNG for the nonce. Thats just
one more persistent number to remember.
Maybe write something like that.
Proposal to change the original text to the following:
"A DoS attack with a faked registrar-agent may block the bootstrapping of the pledge due to state creation on the pledge (the pledge may produce a voucher-request, and refuse to produce another one).
One mitigation may be that the pledge does not limited the number of voucher-requests it creates until at least one has finished. An alternative may be that the onboarding state may expire after a certain time, if no further interaction has happened. "
Proposal to add further info based on Toerless' comment as:
"In addition, the pledge may assume that repeated trigger voucher requests are the result of a communication error with the registrar-agent. In that case the pledge MAY simply resent the pledge-voucher request previously sent. Note that in case of resending, a contained nonce and also the contained agent-signed-data in the pledge-voucher-request would consequently be reused."
This may need further discussion as we should not have a deadlock through resending pledge-voucher-requests even if contacted from a different registrar-agent.
small finding:
- "due to state creation on the pledge" may be better use "due to changing state on the pledge"
- "repeated trigger voucher requests" may be better use "repeated triggering for PVR"
considered proposal and improvements in the latest commit. Left open for Toerless to review
First, it seems we should have a sentence stating why we even need to re-specify things here over rfc8995:
Because in PRM, the pledge responds to requests from real or illicit registrar-agents, pledges are more subject to DoS attacks from registrar-agents in PRM than they are from illicit registrars in RFC8995 where pledges do initiate the connections.
Secondly, the current text:
2799 One mitigation may be that the pledge does does not limited the number of
2800 voucher requests it creates until at least one has finished, or a
2801 single onboarding state may expire after a certain time.
Is not very practical. It would imply that the pledge would have to remember as many nonces as it receives fake requests. This is what i wanted to avoid. RFC8995 says that every request needs a new nonce, but that only makes sense when the pledge is initiator (IMHO). Because then it is at control.
Aka: recommendation would be to only generate new nonces at a frequency that an rfc8995 plede would also create new nonces (requests). And re-use the same nonce for all received prm requrests in the time window. And add a statement that a PRM pledge SHOULD derive its nonce from a PRG, ideally one from a TPM, so that it would not re-use the same nonce with very high likelyhood, even across reboots.
Discuss in BRSKI call:
Michael: need to throttle generation of replies, not because of nonce, but because its expensive to sign the message (from pledge).
otherwise reuse of nonce for some period of time, to avoid having to remember too many nonce is fine.
Added explanation in latest submit
may be closed