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. ? > > > > 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?
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
