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)

where password may be a string and n a number of iterations pulled from
a config file.  A KDF seeded with something relatively public seems like
the easy way to balance security and ease of administration.  
     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.
     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.

     Jim

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to