Max, in the process of writing up the security considerations for freshness of voucher requests, which is here, and attached below.
https://github.com/anima-wg/anima-bootstrap/commit/17724acb3a1810c09f113eb652cb66e274f9c640#diff-ea76ed1df307bcbcc86a5d34c5547032 It occurs to me that the problem outlined in the last paragraph, that the MASA winds up with a voucher issued that was never successfully used, could be solved if: a) the Voucher Status in section 3.5 was a signed artifact! b) that it contained some freshness present in the voucher. c) that a voucher that was not confirmed to have been used prior to expiring would be marked as such. I think that this *could* be added as an extension in the future. If we were going to say something today, it would be that successful Status Telemetry SHOULD be relayed by the Registrar to the MASA, (?even if the Registrar does not understand the contents?) 6.1. Freshness in Voucher Requests + + A concern has been raised that the voucher request produced by the + Pledge should contain some content (a nonce) from the Registrar and/ + or MASA in order for those actors to verify that the voucher request + is fresh. + + There are a number of operational problems with getting a nonce from + the MASA to the pledge. It is somewhat easier to collect a random + value from the Registrar, but as the Registrar is not yet at this + point validated, such a Registrar nonce has little value. There are + privacy and logistical challenges to the process, so if such a thing + were to be considered, it would have to provide some clear value. + This section examines the impacts of not having a fresh voucher + request from the pledge. + + Consider the case where a MITM is between the Pledge and the + legitimate Registrar. This fake Registrar will obtain from the + Pledge a signed voucher request. The pledge will have accepted the + fake Registrar as legitimate up to this point as the EST connection + will still be at the provisional state. + + The fake Registrar (Ra) can communicate the signed voucher request to + a collaborator, perhaps located in another network, and communicate + with a some Registrar (Rb) to obtain a voucher signed by the MASA. + Assuming that the MASA accepts the voucher request (either because + this is the legitimate Registrar according to supply chain + information, or because the MASA is in audit-log only mode), then a + voucher linking the pledge to the Registrar Rb. + + Such a voucher, when passed back to the Pledge, would link the pledge + to Registrar Rb, and would permit the Pledge to attempt to end the + provisional state. The pledge will then attempt to validate the + pinned-domain-certificate linked to in the voucher. That certificate + will point at Registrar Rb. But the pledge will have a provisional + TLS/EST connection to the MITM Registrar Ra. The pledge will fail + the process, close the provisional connection unsuccessfully, and + restart. + + The conclusion is that lack of MASA provided freshness does cause a + pledge to join the wrong network. + + There is an additional concern when the MASA is in audit-log only + mode. When the unfortunate pledge above does connect to directly to + a legitimate Registrar, that Registrar will discover that a voucher + was previously issued. If the legimate Registrar is actually Rb, + then all is well. Otherwise, there is a fault as the Registrar has + to consider whether or not to accept a previously owned device. This + may involve consulting a human. If a large number of devices are + attacked in such a way, a human might just accept all the devices in + a batch mode, permitting an actually compromise device through. -- Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
