On Fri, Mar 09, 2012 at 12:32:55PM -0800, Jim Foraker wrote: > > On Fri, 2012-03-09 at 10:04 -0800, Jason Gunthorpe wrote: > > On Fri, Mar 09, 2012 at 07:59:58AM -0500, Hal Rosenstock wrote: > > > > > What mkey model is being proposed here ? It looks to me like it is a > > > single mkey for all ports in the subnet which is the simplest but least > > > flexible model. If so, I think we need something more flexible as IBA > > > allows each port to have it's own different mkey. > > > > I would like to see some general agreement on a generator for mkey, > > something like: > > > > MKey = HMAC(Subnet_KEY,PortGUID) > > > > This blinds the mkey incase a port is compromised but still lets > > privileged entities compute it from a single key. > I've been thinking about a model like that. In particular, > > MKey = 64 bits of PBKDF2(HMAC-SHA1,password,PortGUID,n)
I don't think using passwords for this sort of thing is really a good idea. It has been shown again and again the extrapolating keys from passwords does not stand up. Better to design around a large true random key (eg how bind's rndc works) than a password. In that instance truncated HMAC-SHA2-512 is entirely sufficient. > I've got some concerns however. There are a number of ways that an > attacker on a host connected to the fabric may attempt to compromise the > local CA's mkey, and/or other mkeys on the fabric in well short of > brute-force time. That may mean digging thru kernel memory for the > local key, or it might mean slyly convincing the SM to just hand over > the mkey for some other CA. The IBA architecture is such that a end port should never be able to learn the mkey of another port. Any bugs that let that happen can be fixed. Leaking an end port's MKey to things on the end port is pretty much expected (although should be guarded against as much as possible) - that is why we want to have distinct mkeys on every port. The only desired property is that a single compromised mkey not lead to knowing all mkeys. > Other than a KDF, the models that I can think of would be a) > per-host mkeys specified in a config file, and b) random per-host keys > generated by the SM. I think before we implement a configuration model > beyond OpenSM's though, we need to make sure we understand the attack > surface first, lest we promote a false sense of security. I think these are both basically equivalent to using HMAC or KDF with a strong key.. ie 'random' would really boil down to iterative HMAC with a state you throw away. -- Jason Gunthorpe <jguntho...@obsidianresearch.com> (780)4406067x832 Chief Technology Officer, Obsidian Research Corp Edmonton, Canada -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
