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

[Eric Rescorla <[e-mail]>]

On Fri, May 18, 2018 at 12:52 PM, Eliot Lear <[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]> 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