Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Thu, 23 Mar 2017 19:23:17 +0000

Folks, 

I support this document. I have the following concerns,

1) A MUD file attribute indicating the expected MUD URL emission method is of security value.

Discussion:
Section 1.3 indicates "three means are defined to emit the MUD URL” which including unsecured modes. This introduces the possibility of a attack wherein an incorrect MUD URL is received. This is discussed in the security considerations where it is currently recommended that "devices that present some form of unauthenticated MUD URL SHOULD be validated by some external means”. A useful external means for detecting such attacks would be for the MUD YANG Model to include a usage description of the means expected by the device:

(this is just an example, arguably a list of these would be appropriate in case device can use multiple methods)

  typedef mud-url-emission-modes {
     type enumeration {
         enum viaDHCP-option {
           description “The device emits MUD URLs using DHCP options";
         }
         enum viaX509IDevID {
           description “The device emits MUD URLs by authenticating using an manufacturer installed X.509 certificate";
           }
         enum viaLLDPframe {
           description “The device emits MUD URLs by authenticating using an manufacturer installed X.509 certificate";
           }
         }
     description “Manufacturer usage description of MUD URL emission methods from this type of device (see section 1.3)";
  }

2) As extensions are added to MUD files to cover additional usage descriptions for devices it would be useful for developers and future work to refer to an IANA name registry defining each extension. As such an IANA name registry for MUD “usage descriptions” is suggested. 

3) .well-known is mandated therefore RFC5785 should be included in the references.

I’m of the opinion that the section 10 (“MUD URL X.509 Extension”) should define a general purpose extension for imparting the manufacturer ‘authority’ portion of the URI. A new one-off authority information statement within X.509 credentials is less than ideal. Since the final MUD URI contains the model information I suggest RFC4108 HardwareModuleNam hwType be used to communicate the ‘model'. This allows the MUD URI to be build dynamically and allows the new extension to be leveraged by future work that wishes to reference other .well-known information at the authority. I understand if this suggestion is not acted on.

- max

re:
> Dear OPSAWG,
> 
> This is a notice to start a two-week OPSAWG WG last call for the document:
> 
> Manufacturer Usage Description Specification
> https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
> 
> Please read the above draft and send any issues, comments, or corrections to this mailing list.
> Please indicate your support or concerns by Friday March 31, 2017.
> 
> Thanks,
> Chairs
> 
>