And here's Russ' response. Eliot
--- Begin Message ---Eliot: I would just say that the validation MUST check for digitalSignature bit, and say nothing about the nonRepudiation bit. Russ P.S. Feel free to forward this advice to the working group mail list if that will be helpful. > On May 22, 2018, at 9:20 AM, Eliot Lear <[email protected]> wrote: > > Russ- can you help me with the key usage bits and make sure they're in order? > > Eliot > > > From: Eliot Lear <[email protected]> > Subject: Re: [OPSAWG] Fwd: New Version Notification for > draft-ietf-opsawg-mud-21.txt > Date: May 22, 2018 at 9:03:01 AM EDT > To: Eric Rescorla <[email protected]> > Cc: "[email protected]" <[email protected]>, IESG <[email protected]> > > > 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 >> >> > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg > >
--- End Message ---
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
