Subject: [OPSAWG] Fwd: New Version Notification for draft-ietf-opsawg-mud-21.txt

From: Eliot Lear <[email-masked]>
Date: Thu, 17 May 2018 17:36:02 +0200

Hi everyone,

This draft is intended to address all IESG comments.  Thanks to the IESG
and reviewers for their contributions.  A summary of the changes is
below, but people may wish to do a side by side review.

Eliot

  * Small edits to the abstract
  * Clarity in the introduction that the focus is on protecting the device.
  * Many grammatical/wording improvements
  * Clarity when MUD is most effective.
  * MUD controller -> MUD manager
  * Normative language boiler plate change
  * Clarity on what should happen when a MUD manager can't reach a MUD
    file server
  * A few reference updates
  * Clarity on the validity time of a MUD file
  * Added references to RFCs 5911 and 5912 for SMI changes
  * one additional data element (documentation)
  * one change based on an update to the ACL model during its last call
  * Subsection numbering for node descriptions.
  * Improved text around "controller", direction-initiated.
  * Simplified MUD-URL text.
  * Optional reserved space added to DHCP, LLDP options
  * Simplified DHCP processing.
  * A new certificate field to bind the manufacturer certificate to the
    mud signer.
  * A content type definition for the SMI.
  * Updated security considerations.

Subject: New Version Notification for draft-ietf-opsawg-mud-21.txt
From: <[email-masked]>
To: Ralph Droms <[email-masked]>, Eliot Lear <[email-masked]>, Dan Romascanu <[email-masked]>
Date: Thu, 17 May 2018 08:19:52 -0700

A new version of I-D, draft-ietf-opsawg-mud-21.txt
has been successfully submitted by Eliot Lear and posted to the
IETF repository.

Name:		draft-ietf-opsawg-mud
Revision:	21
Title:		Manufacturer Usage Description Specification
Document date:	2018-05-17
Group:		opsawg
Pages:		60
URL:            https://www.ietf.org/internet-drafts/draft-ietf-opsawg-mud-21.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-opsawg-mud/
Htmlized:       https://tools.ietf.org/html/draft-ietf-opsawg-mud-21
Htmlized:       https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-mud
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-mud-21

Abstract:
   This memo specifies a component-based architecture for manufacturer
   usage descriptions (MUD).  The goal of MUD is to provide a means for
   end devices to signal to the network what sort of access and network
   functionality they require to properly function.  The initial focus
   is on access control.  Later work can delve into other aspects.

   This memo specifies two YANG modules, IPv4 and IPv6 DHCP options, an
   LLDP TLV, a URL, an X.509 certificate extension and a means to sign
   and verify the descriptions.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Joe Clarke <[email-masked]>
Date: Thu, 17 May 2018 12:13:58 -0400

On 5/17/18 11:36, Eliot Lear wrote:
> Hi everyone,
> 
> This draft is intended to address all IESG comments.  Thanks to the
> IESG and reviewers for their contributions.  A summary of the
> changes is below, but people may wish to do a side by side review.

Thanks for working with the IESG to resolve the major comments.

I have a few additional on this draft.

Section 1.7

s/URL that the thing emitted/URL that the Thing emitted/

===

Section 2.1

You changed container "mud" to component "mud" here likely to be
consistent with the use of component in the other two bullets.
However, because "mud" is quoted, it seems like you are directly
referring to the mud container in the YANG model.  Maybe drop the
"mud" or say:

the first component, the "mud" container, ...

===

Section 4.6

s/each every/each and every/

===

Section 4.8

s/This MUST only applied to TCP.  this/This only applies to TCP.  This/

Not sure if that's what you want to say.

===

Section 7

You didn't bump the revision with this YANG module update.  This can
mess up some tooling we have.  Can I ask that you bump this at least
once before final publication?

===

Section 7

I'm not a YANG doctor, but I see formatting inconsistencies in this
module.  It would benefit from running it through pyang -f yang to
normalize the formatting.

===

Section 8.3

The same is true here.  A pyang -f yang will normalize the formatting.

===

Section 9

Suggestion to add documentation to your example MUD file just to hint
at this being a good behavior for the benefit of admins.

===

Section 13

s/To insure that/To ensure that/

===

Section 13.2

s/that the verification step match/that the verification step matches/

===

Section 15

s/alloewed/allowed/

===

Section 16

s/occured/occurred/

===

Section 17.1

s/registred/registered/

===

Appendix B

s/overriden/overridden/

Joe

> 
> Eliot
> 
> 
> * Small edits to the abstract * Clarity in the introduction that
> the focus is on protecting the device. * Many grammatical/wording
> improvements * Clarity when MUD is most effective. * MUD controller
> -> MUD manager * Normative language boiler plate change * Clarity
> on what should happen when a MUD manager can't reach a MUD file
> server * A few reference updates * Clarity on the validity time of
> a MUD file * Added references to RFCs 5911 and 5912 for SMI
> changes * one additional data element (documentation) * one change
> based on an update to the ACL model during its last call *
> Subsection numbering for node descriptions. * Improved text around
> "controller", direction-initiated. * Simplified MUD-URL text. *
> Optional reserved space added to DHCP, LLDP options * Simplified
> DHCP processing. * A new certificate field to bind the manufacturer
> certificate to the mud signer. * A content type definition for the
> SMI. * Updated security considerations.
> 
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 17 May 2018 18:40:43 +0200

Thank you, Joe.  Barring objections, I will hold these as editorial and
work with the RFC Editor on them.

Eliot

---

From: Joe Clarke <[email-masked]>
Date: Thu, 17 May 2018 12:56:53 -0400

On 5/17/18 12:40, Eliot Lear wrote:
> Thank you, Joe.  Barring objections, I will hold these as editorial
> and work with the RFC Editor on them.

That's fine.  I really want to make sure the MUD YANG module gets its
revision bumped since there was a change.

Joe

>>> This draft is intended to address all IESG comments.  Thanks to
>>> the IESG and reviewers for their contributions.  A summary of
>>> the changes is below, but people may wish to do a side by side
>>> review.
>> 
>> referring to the mud container in the YANG model.  Maybe drop
>> the "mud" or say:
>> 
>> You didn't bump the revision with this YANG module update.  This
>> can mess up some tooling we have.  Can I ask that you bump this
>> at least once before final publication?
>> 
>> ===
>> 
>> Section 7
>> 
>> I'm not a YANG doctor, but I see formatting inconsistencies in
>> this module.  It would benefit from running it through pyang -f
>> yang to normalize the formatting.
>> 
>> ===
>> 
>> Section 8.3
>> 
>> Suggestion to add documentation to your example MUD file just to
>> hint at this being a good behavior for the benefit of admins.
>> 
>> ===
>> 
>> Section 13
>> 
>>> * Small edits to the abstract * Clarity in the introduction
>>> that the focus is on protecting the device. * Many
>>> grammatical/wording improvements * Clarity when MUD is most
>>> effective. * MUD controller -> MUD manager * Normative language
>>> boiler plate change * Clarity on what should happen when a MUD
>>> manager can't reach a MUD file server * A few reference updates
>>> * Clarity on the validity time of a MUD file * Added references
>>> to RFCs 5911 and 5912 for SMI changes * one additional data
>>> element (documentation) * one change based on an update to the
>>> ACL model during its last call * Subsection numbering for node
>>> descriptions. * Improved text around "controller",
>>> direction-initiated. * Simplified MUD-URL text. * Optional
>>> reserved space added to DHCP, LLDP options * Simplified DHCP
>>> processing. * A new certificate field to bind the manufacturer 
>>> certificate to the mud signer. * A content type definition for
>>> the SMI. * Updated security considerations.
>> 
>> 
>> 
>> 
>

---

From: "M. Ranganathan" <[email-masked]>
Date: Thu, 17 May 2018 16:36:11 -0400

Hello Eliot,

Thanks for the draft. Which version of access-control-list yang model does
this depend on?

I ask because if it is draft 19 of the ACL standard,  I noticed a
discrepancy in your example (possibly my mistake but I thought I should
bring it to your attention):

On page 52 should the following be changed to
ietf-access-control-list:acls  ? And also there's a similar one in the
default Acls later in the draft.

ietf-access-control-list:access-lists

Thanks

On Thu, May 17, 2018 at 11:36 AM, Eliot Lear <[email-masked]> wrote:

> and reviewers for their contributions.  A summary of the changes is below,
> but people may wish to do a side by side review.
>
> Eliot
>
>
>
>    - Small edits to the abstract
>    - Clarity in the introduction that the focus is on protecting the
>    device.
>    - Many grammatical/wording improvements
>    - Clarity when MUD is most effective.
>    - MUD controller -> MUD manager
>    - Normative language boiler plate change
>    - Clarity on what should happen when a MUD manager can't reach a MUD
>    file server
>    - A few reference updates
>    - Clarity on the validity time of a MUD file
>    - Added references to RFCs 5911 and 5912 for SMI changes
>    - one additional data element (documentation)
>    - one change based on an update to the ACL model during its last call
>    - Subsection numbering for node descriptions.
>    - Improved text around "controller", direction-initiated.
>    - Simplified MUD-URL text.
>    - Optional reserved space added to DHCP, LLDP options
>    - Simplified DHCP processing.
>    - A new certificate field to bind the manufacturer certificate to the
>    mud signer.
>    - A content type definition for the SMI.
>    - Updated security considerations.
>
>
>
>
> ---------- Forwarded message ----------
> Cc:
> Bcc:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>
>

-- 
M. Ranganathan

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 May 2018 09:43:29 +0200

Ok, I take it back.  Ranga found a problem with an example, and Russ
found a glitch with the SMI.  Nothing serious either, but I now propose
to do one more update, once EKR and Ben have had a chance to review and
comment.

Eliot

---

From: Joe Clarke <[email-masked]>
Date: Fri, 18 May 2018 06:46:35 -0400

Chair hat on:

We would like to give this call for review a week timeout with the WG.

Please pay special attention to the security changes Eliot has
described below when reviewing the new text.

We are looking to push this forward EOD on May 25.

Thanks.

Joe

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 May 2018 10:57:31 -0700

Eliot,

The certificate part seems basically right (I think you should require
specific KeyUsage bits).

Maybe I missed it, but I didn't see anything about the level of trust you
should have in cases where you can't reliably tie the endpoint's
transmissions to its certificate.

-Ekr

On Fri, May 18, 2018 at 3:46 AM, Joe Clarke <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chair hat on:
>
> -----BEGIN PGP SIGNATURE-----
>
> iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWv6vBgAKCRBvaI+K/hTP
> hwzAAJ4gQdPZ93IFCwO7nWOca4gu7xbwkwCeJPLWlBoGGKDtuQp8sUHVJy+2lmY=
> =CyhD
> -----END PGP SIGNATURE-----
>
>

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 May 2018 20:56:05 +0200

Hi EKR,

On 18.05.18 19:57, Eric Rescorla wrote:
> Eliot, > > The certificate part seems basically right (I think you should
require specific KeyUsage bits).
It's in there:
> It is expected that the Key Usage extension would contain "Digital
> Signature" and that the extended key usage would include either "code
> signing" or "email protection".

This leaves a little a little flexibility.  I think this is sufficient,
and compatible with existing CAs.

> > Maybe I missed it, but I didn't see anything about the level of trust
you should have in cases where you can't reliably tie the endpoint's
transmissions to its certificate.
It's there but could be clearer:

OLD:
> A
> MUD manager MUST cease processing of that file it cannot validate the
> chain of trust to a known trust anchor until an administrator has
> given approval.

NEW:

> A
> MUD manager MUST cease processing of that file it cannot validate the
> chain of trust to a known trust anchor or the MUDsigner until an
> administrator has
> given approval.

That is- throw an exception and let the admin sort it out.

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 18 May 2018 11:59:40 -0700

On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <[email-masked]> wrote:

> > Eliot, > > The certificate part seems basically right (I think you
> should require specific KeyUsage bits).
> It's in there:
>

I disagree. This is going to lead to a lot of interop problems. You need to
actually specify the bits

OLD:

A

NEW:

A

This is about the file. I'm talking about IP/MAC forgery.

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Fri, 18 May 2018 21:52:21 +0200

On 18.05.18 20:59, Eric Rescorla wrote:
>
>
> On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi EKR,
>
>
>     This leaves a little a little flexibility.  I think this is
>     sufficient, and compatible with existing CAs.
>
>
> I disagree. This is going to lead to a lot of interop problems. You
> need to actually specify the bits

Do you mean something like this:

The Key Usage Extension in the MUD file signature MUST have the bit
digitalSignature(0) or set.

?
>
> > > Maybe I missed it, but I didn't see anything about the level of
> trust you should have in cases where you can't reliably tie the
> endpoint's transmissions to its certificate.

OK.  Noting that this is NOT an authentication standard, we can
certainly reference them.  I propose the following in Security
Considerations:

Devices may forge source (L2/L3) information.  Deployments should apply
appropriate protections to bind communications to the authentication
that has taken place.  For 802.1X authentication, IEEE 802.1AE (MACsec)
is one means by which this may happen.  A similar approach can be used
with 802.11i (WPA2).  Other means are available with other lower layer
technologies.  Implementations using session-oriented access that is not
cryptographically bound should take care to remove state when any form
of break in the session is detected.

Comments?

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 22 May 2018 05:51:16 -0700

On Fri, May 18, 2018 at 12:52 PM, Eliot Lear <[email-masked]> wrote:

> I disagree. This is going to lead to a lot of interop problems. You need
> to actually specify the bits
>
>
>

Yes. Though I would defer to Russ on the bits :)

OLD:

A

NEW:

A

OK.  Noting that this is NOT an authentication standard, we can certainly
reference them.  I propose the following in Security Considerations:

Devices may forge source (L2/L3) information.  Deployments should apply
appropriate protections to bind communications to the authentication that
has taken place.  For 802.1X authentication, IEEE 802.1AE (MACsec) is one
means by which this may happen.  A similar approach can be used with
802.11i (WPA2).  Other means are available with other lower layer
technologies.  Implementations using session-oriented access that is not
cryptographically bound should take care to remove state when any form of
break in the session is detected.

Comments

I think the relevant point is:
"Implementations SHOULD NOT grant elevated permissions (beyond those of
devices presenting no MUD policy) to devices which do not strongly bind
their identity to their L2/L3 transmissions"

-Ekr

---

From: Eliot Lear <[email-masked]>
Date: Tue, 22 May 2018 15:03:01 +0200

I'm ok with that change, and I'll ping Russ on the bits.

Eliot

On 22.05.18 14:51, Eric Rescorla wrote:
>
>
> On Fri, May 18, 2018 at 12:52 PM, Eliot Lear <[email-masked]
>>     I disagree. This is going to lead to a lot of interop problems.
>>     You need to actually specify the bits
>
>
>     The Key Usage Extension in the MUD file signature MUST have the
>     bit digitalSignature(0) or set.
>
>
> Devices may forge source (L2/L3) information.  Deployments should
> apply appropriate protections to bind communications to the
> authentication that has taken place.  For 802.1X authentication, IEEE
> 802.1AE (MACsec) is one means by which this may happen.  A similar
> approach can be used with 802.11i (WPA2).  Other means are available
> with other lower layer technologies.  Implementations using
> session-oriented access that is not cryptographically bound should
> take care to remove state when any form of break in the session is
> detected.
>
> Comments
>
> "Implementations SHOULD NOT grant elevated permissions (beyond those
> of devices presenting no MUD policy) to devices which do not strongly
> bind their identity to their L2/L3 transmissions"
>
> -Ekr
>
>