On Fri, May 18, 2018 at 12:52 PM, Eliot Lear <l...@cisco.com> wrote: > > > On 18.05.18 20:59, Eric Rescorla wrote: > > > > On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <l...@cisco.com> 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
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
