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

[Eliot Lear <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 18.05.18 20:59, Eric Rescorla wrote:
>>
>>
>>     On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <[e-mail]
>>     <mailto:[e-mail]>> wrote:
>>
>>         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.
>>
>>
>>     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.
>
>
> Yes. Though I would defer to Russ on the 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.
>> 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.
>>
>> This is about the file. I'm talking about IP/MAC forgery.
>
> 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
>
>