Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

[Michael Richardson <[e-mail]>]

Benjamin Kaduk <[e-mail]> wrote:
    doc> although it results in additional network traffic.  The relying MASA
    doc> implementation MAY leverage internal state to associate this request
    doc> with the original, and by now already validated, voucher-request so
    doc> as to avoid an extra crypto validation.
    >>
    >> > It seems that doing so would turn the voucher-request into a bearer
    >> > token for retrieving audit-log information (if the MASA accepts
    >> > unauthenticated clients).
    >>
    >> That's what's intended.

    > I can see why that functionality is needed, but it seems likely to
    > introduce some privacy and/or security considerations to document.  It's a
    > bit too late in the day for me to reason through them, though.

To be clear: any registrar which has ever formed a valid voucher-request MAY
retrieve the audit-log at regular intervals to verify the status of the
device.  The words, "now already validated" means that the MASA agreed with
the voucher-request.  Most implementations are going to log the
voucher-request as part of the internal audit log, so a memcmp() on that is enough.

This would reveal new owners.  Whether the new owner is legitimate or not is
not something we can answer: it might be that the device has been stolen, or
maybe it's legitimately lent, rented, sold, etc.

    >> > Section 11
    >>
    >> > I am somewhat embarassed that I did not previously note that the
    >> > mechanism used to generate the domainID needs to be
    >> > second-preimage-resistant or an attacker can claim to be a registrar for
    >> > a domain that already exists.
    >>
    >> Right now, that's in:
    >>
    >> 5.8.2.  Calculation of domainID
    >>
    >> The domainID is a binary value (a BIT STRING) that uniquely
    >> identifies a Registrar by the "pinned-domain-cert"
    >>
    >> If the "pinned-domain-cert" certificate includes the
    >> SubjectKeyIdentifier (Section 4.2.1.2 [RFC5280]), then it is to be
    >> used as the domainID.  If not, the SPKI Fingerprint as described in
    >> [RFC7469] section 2.4 is to be used.  This value needs to be
    >> calculated by both MASA (to populate the audit-log), and by the
    >> Registrar (to recognize itself).
    >>
    >> We tried hard and found a way not to say SHA-1 directly, allowing SHA256 to
    >> replace it appropriately.

    > That's all good and admirable; I'm suggesting that we add a note in the
    > security considerations of this document noting that we rely on the
    > domainID (however determined) to be second-preimage-resistant.

I've added this to the security considerations as 11.2.

    doc> Although the nonce used by the Pledge in the voucher-request does not
    doc> require a strong cryptographic randomness, the use of TLS in all of
    doc> the protocols in this document does.
    >>
    >> > We discuss the need for strong randomness in the nonce in Section 11.3,
    >> > so it's not clear this is actually true.
    >>
    >> We don't think that the voucher nonce has to be of the same quality as something that
    >> goes into a KDF.  It is at the level of TCP Sequeunce number, not seed for
    >> generating a private key...

    > I mean, we literally say "Reducing the possibility of this is why the
    > pledge is mandated to generate a strong random or pseudo-random number
    > nonce."  So to also say "the nonce [...] does not require a strong
    > cryptographic randomness" seems to be in conflict with the former
    > statement.
    > Are you saying that "strong random" and "strong cryptographic random" mean
    > different things, or am I misreading the document in some other way?

I take your point, and I guess we were splitting hairs.
I'll just rephrase it to remove the Although statement.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-