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

[Eliot Lear <[e-mail]>]

Hi,

Could we recap a bit on this?  I have commented on the use of the rfc822Name myself, and was a bit concerned about misuse and misinterpretation prior to rfcSELF being present.

Now that it is it represents a new convention.  The question at hand is whether the information found on the LHS could be subject to misinterpretation by non-participants.  I wonder if we could add an EKU as a SHOULD to break the logjam.

Eliot


> On 1 Nov 2019, at 21:14, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> 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 =-
> 
> 
> 
> 
>