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 protected] > <mailto:[email protected]>> wrote: > > > > On 18.05.18 20:59, Eric Rescorla wrote: >> >> >> On Fri, May 18, 2018 at 11:56 AM, Eliot Lear <[email protected] >> <mailto:[email protected]>> 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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
