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
>
>
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
