[OPSAWG] Fwd: I-D Action: draft-ietf-opsawg-mud-23.txt

[Eliot Lear <[e-mail]>]

I've been told to resend this message due to a mailing list glitch. 
Please see below.

--- Begin Message ---

Ben,

Barring any objections to the below I will issue a new draft with edits
tomorrow.  Now please see below.

On 04.06.18 17:40, Benjamin Kaduk wrote:
> Hi Eliot,
>
> On Sat, Jun 02, 2018 at 03:40:34PM +0200, Eliot Lear wrote:
>> This update contains only the following changes:
>>
>>   * A correction (signature -> certificate)
>>   * Slightly change language to make clear that the certificate subject
>>     must be the sameas the id-pe-mudsigner
>>   * Updated dates on the YANG files
>>
>> At this point, I really hope we're done.  Eric, Ben?
> I think we're basically done -- I have just one quibble which
> hopefully is not problematic, and also noted a handful of editorial
> things you can deal with at your leisure.  Thanks for going through
> the multiple rounds of changes addressing our concerns -- the
> document really is much better for it!
>
> At the start of the Security Considerations, we say:
>
>    Based on how a MUD URL is emitted, a Thing may be able to lie about
>    what it is, thus gaining additional network access.  This happens
>    when a device emits a MUD URL using DHCP or LLDP, and is either
>    inappropriately admitted to a class such as "same-manufacturer" or
>    given access to a device such as "my-controller", where such access
>    would otherwise be disallowed.
>
> To me, "[t]his happens when" indicates that the subsequent
> enumeration is an exhaustive list.  I don't really think we've got
> enough experience with this stuff to be able to make such a claim,
> and the list should instead be treated as illustrative.  I think
> that there was some text emailed around that did this nicely,
> something like:
>
> %   Based on how a MUD URL is emitted, a Thing may be able to lie about
> %   what it is, thus gaining additional network access.  This can happen
> %   in a number of ways when a device emits a MUD URL using DHCP or
> %   LLDP, such as being inappropriately admitted to a class such as
> %   "same-manufacturer", given access to a device such as
> %   "my-controller", or being permitted access to an Internet resource,
> %   where such access would otherwise be disallowed.

I think that's fine.
>
>
> And, here's the editorial stuff.
>
> Section 1.5
>
>    o  A DHCP option[RFC2131],[RFC3315] that the DHCP client uses to
>       inform the DHCP server.  The DHCP server may take further actions,
>       such as act as the MUD manager or otherwise pass it along to the
>       MUD manager.
>
> nit: We lost the immediately previous "URL" that "it" referred to, so we
> may want to specifically say "pass the MUD URL along".
>
> Section 13.2
>
>    Prior to processing the rest of a MUD file, the MUD manager MUST
>    retrieve the MUD signature file by retrieving the value of "mud-
>    signature" and validating the signature across the MUD file.  The Key
>    Usage Extension in the signing certificate MUST have the bit
>    digitalSignature(0) set.
>
> nit: do we need to go with "MUST be present and have the bit
> digitalsignature(0) set"?

That is fine.
>
>                             The subject of this certificate MUST be
>    equal to that of the value of id-pe-mudsigner when that extension is
>    present in the device certificate.  If these conditions are not met,
>    or if it cannot validate the chain of trust to a known trust anchor,
>    the MUD manager MUST cease processing the MUD file until an
>    administrator has given approval.
>
> nit-level as well, I guess: I might wordsmith this differently.
>
> NEW:
>
>    When the id-pe-mudsigner extension is present in a device's X.509
>    certificate, the MUD signature file MUST have been generated by
>    a certificate whose subject matches the contents of that
>    id-pe-mudsigner extension.  If these conditions are not met,
>    or if it cannot validate the chain of trust to a known trust anchor,
>    the MUD manager MUST cease processing the MUD file until an
>    administrator has given approval.

Ok.
>
> I might also consider adding something like the following (though
> hopefully it would be obvious and thus not necessary to say):
>
>    Before the signature has been validated, both the MUD file and
>    the resource retrived from the "mud-signature" URL are unverified
>    and should be treated as untrusted input.  In particular, MUD
>    managers can impose a cap on the number of bytes they retrieve
>    from a "mud-signature" URL, to avoid DoS attacks involving
>    presenting a large (invalid) signature file or similar scenarios.

I would rather leave this out for the very reasons you state.  The draft
is already quite wordy.
>
> Section 16
>
>    Implementations SHOULD be configurable to
>    disallow additive access for devices using MUD-URLs that not emitted
>    in a secure fashion such as in a certificate.
>
> nit: "that are not emitted".

Ok
>
>    When certificates are not present, Things claiming to be of a certain
>    manufacturer SHOULD NOT be included in that manufacturer grouping
>    without additional validation of some form.  This will be relevant
>    when it makes use of primitives such as "manufacturer" for the
>    purpose of accessing Things of a particular type.
>
> What is "it" that makes use of primitives such as "manufacturer"?

the MUD manager.
>
>    [...] If the actual MUD file has changed, the MUD
>    manager MAY check the WHOIS database to see if registration ownership
>    of a domain has changed.
>
> Do we need a reference for WHOIS?

I don't think so.  RFC Editor will sort if so.
>
> Appendix C
>
>    In this sample extension we augment the core MUD model to indicate
>    whether the device implements DETNET.  If a device claims not to use
>    NETNET, but then later attempts to do so, a notification or exception
>
> That's also supposed to be 'D'ETNET, right?

Indeed.  Thanks.

Eliot

--- End Message ---