On Mon, Apr 16, 2018 at 6:55 AM, Eliot Lear <l...@cisco.com> wrote: > Hi Eric, > On 16.04.18 14:25, Eric Rescorla wrote: > > Hi Eliot, > > Thanks for continuing the conversation. My question is how this fits into > the system as a whole. > > ISTM that there are two ways in which a MUD policy can affect the > network's behavior: > > - Additive -- it lets the device do things it otherwise might not be > permitted to do (e.g., accept incoming TCP connections) > - Restrictive -- it stops the device from doing things that it otherwise > would be permitted to do (e.g., make connections to IP addresses on non-443 > ports) > > > What you describe is the choice of the network administrator, and not the > standard nor the manufacturer. You are essentially asking, “what is the > default policy? >
No, I'm not asking that. What I'm looking for is the document to describe the various use cases and ensure that the mechanisms it provides actually be able to effect those use cases. In the former case, it's very important not to be able to forge acceptable > MUD policies, but in the latter case, an attacker can just not serve *any* > MUD policy and be in a stronger position than they would be if they had a > valid policy,[...] > > > And so that will depend on the deployment. And many of the attacks would > be detectable. > How would those attacks be detectable? I should mention one use case that I did think of, where additive would be > immediately useful: "This device is made by the same manufacturer as > another device (and hence they can talk to each other). However, I note > that MUD is actually not capable of securely conveying that, because > there's no proof that the device in hand actually is made by the > manufacturer, only that it possesses a public credential for some device > made by that manufacturer. > > > That is the point of building out a PKI, and as I wrote, there are some > interested in providing what amounts to a certification for this purpose. > This is also something the MUD manager can take on: as time goes on it can > white list signers, and it can flag devices that are not recognized as > being risky. In addition, if you have someone willing to take > accountability for that device to lay a claim, it may not be "proof", but > that is good enough in an enterprise environment, where someone can be > called to account for having added the device. > Well, there are two types of PKI here: 1. The one associated with the device certificate 2. The one associated with the MUD signature. My point is that only the former provides any assurance that the actual device has anything to do with the manufacturer. In the latter case, I can just stuff the URL of any manufacturer's MUD policy in my device that I please. -Ekr
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
