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

"Max Pritikin (pritikin)" <pritikin@cisco.com> Thu, 23 March 2017 19:23 UTC

Return-Path: <pritikin@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDD1131639 for <opsawg@ietfa.amsl.com>; Thu, 23 Mar 2017 12:23:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmUG6yiTcZ4m for <opsawg@ietfa.amsl.com>; Thu, 23 Mar 2017 12:23:21 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7365131635 for <opsawg@ietf.org>; Thu, 23 Mar 2017 12:23:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4016; q=dns/txt; s=iport; t=1490296998; x=1491506598; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=suDUr0Dw/0jVzbCIJ6zO2KNQlJQyBNRgkmM2QnMP+EM=; b=aYbhQo+vT9S1kbuEqQwkrMEVx/7ybCaZnIyX8b8x8Py+4vXTlQDl4mcl jT6kQYTmJbzcDpdjkd+qTaVwiC8wKph05rs1jR4jetas0rP4gddHSXESU BkjfCgocBTZ1HH4Ts606lcIW6Tsdrp4m3ykoT3kj1CR34eoe8WLrXzkaM E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0A3AgD8H9RY/4YNJK1eGQEBAQEBAQEBAQEBBwEBAQEBgycqYYESg1uKD5EwlWiCDiqFeByCfT8YAQIBAQEBAQEBax0LhRYGHQYROgsSAQgaAiYCBDAVEgQOigsOqjyCJopEAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBC4dICIJih1ougjEFiSiGNox3AYZ6hlCEf4F7GIUSg1eGM5NhAR84gQRZFUERAYZGiEMrgQOBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.36,211,1486425600"; d="scan'208";a="402117521"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Mar 2017 19:23:17 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v2NJNHYb022826 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for <opsawg@ietf.org>; Thu, 23 Mar 2017 19:23:17 GMT
Received: from xch-aln-013.cisco.com (173.36.7.23) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 23 Mar 2017 14:23:17 -0500
Received: from xch-aln-013.cisco.com ([173.36.7.23]) by XCH-ALN-013.cisco.com ([173.36.7.23]) with mapi id 15.00.1210.000; Thu, 23 Mar 2017 14:23:17 -0500
From: "Max Pritikin (pritikin)" <pritikin@cisco.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
CC: "Eliot Lear (elear)" <elear@cisco.com>
Thread-Topic: WG LC for draft-ietf-opsawg-mud-05
Thread-Index: AQHSpArsNCNn2YcKPUWtkDOh8HfKZw==
Date: Thu, 23 Mar 2017 19:23:17 +0000
Message-ID: <74D7430F-5B42-4857-A49A-AD4AA1845516@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.99.106.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A0F36B6DC0022747BB423A9E41530577@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/Fje88b9m_pqCZ25tV4uX3tYPciY>
Subject: Re: [OPSAWG] WG LC for draft-ietf-opsawg-mud-05
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 19:23:23 -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
> 
>