[PATCH] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[PATCH] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jim Foraker]

Signed-off-by: Jim Foraker <foraker1-i2BcT+NCU+M@public.gmane.org>
---
 include/infiniband/mad.h |    2 ++
 src/libibmad.map         |    2 ++
 src/mad_internal.h       |    1 +
 src/smp.c                |   12 ++++++++++++
 4 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/include/infiniband/mad.h b/include/infiniband/mad.h
index 5d62307..278b9bc 100644
--- a/include/infiniband/mad.h
+++ b/include/infiniband/mad.h
@@ -1489,6 +1489,8 @@ MAD_EXPORT uint8_t *smp_set_status_via(void *data,
ib_portid_t * portid,
 				       unsigned attrid, unsigned mod,
 				       unsigned timeout, int *rstatus,
 				       const struct ibmad_port *srcport);
+MAD_EXPORT void smp_mkey_set(struct ibmad_port *srcport, uint64_t
mkey);
+MAD_EXPORT uint64_t smp_mkey_get(const struct ibmad_port *srcport);
 
 /* cc.c */
 MAD_EXPORT void *cc_query_status_via(void *rcvbuf, ib_portid_t *
portid,
diff --git a/src/libibmad.map b/src/libibmad.map
index 7c7587b..a4d4418 100644
--- a/src/libibmad.map
+++ b/src/libibmad.map
@@ -146,5 +146,7 @@ IBMAD_1.3 {
 		mad_dump_port_ext_speeds_counters;
 		cc_query_status_via;
 		cc_config_status_via;
+		smp_mkey_get;
+		smp_mkey_set;
 	local: *;
 };
diff --git a/src/mad_internal.h b/src/mad_internal.h
index 3c32d10..5deac27 100644
--- a/src/mad_internal.h
+++ b/src/mad_internal.h
@@ -40,6 +40,7 @@ struct ibmad_port {
 	int port_id;		/* file descriptor returned by umad_open() */
 	int class_agents[MAX_CLASS];	/* class2agent mapper */
 	int timeout, retries;
+	uint64_t smp_mkey;
 };
 
 extern struct ibmad_port *ibmp;
diff --git a/src/smp.c b/src/smp.c
index a337663..14c74ed 100644
--- a/src/smp.c
+++ b/src/smp.c
@@ -46,6 +46,16 @@
 #undef DEBUG
 #define DEBUG 	if (ibdebug)	IBWARN
 
+void smp_mkey_set(struct ibmad_port *srcport, uint64_t mkey)
+{
+	srcport->smp_mkey = mkey;
+}
+
+uint64_t smp_mkey_get(const struct ibmad_port *srcport)
+{
+	return srcport->smp_mkey;
+}
+
 uint8_t *smp_set_status_via(void *data, ib_portid_t * portid, unsigned
attrid,
 			    unsigned mod, unsigned timeout, int *rstatus,
 			    const struct ibmad_port *srcport)
@@ -67,6 +77,7 @@ uint8_t *smp_set_status_via(void *data, ib_portid_t *
portid, unsigned attrid,
 	rpc.timeout = timeout;
 	rpc.datasz = IB_SMP_DATA_SIZE;
 	rpc.dataoffs = IB_SMP_DATA_OFFS;
+	rpc.mkey = srcport->smp_mkey;
 
 	portid->sl = 0;
 	portid->qp = 0;
@@ -105,6 +116,7 @@ uint8_t *smp_query_status_via(void *rcvbuf,
ib_portid_t * portid,
 	rpc.timeout = timeout;
 	rpc.datasz = IB_SMP_DATA_SIZE;
 	rpc.dataoffs = IB_SMP_DATA_OFFS;
+	rpc.mkey = srcport->smp_mkey;
 
 	if ((portid->lid <= 0) ||
 	    (portid->drpath.drslid == 0xffff) ||
-- 
1.7.1



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jim Foraker]

Signed-off-by: Jim Foraker <foraker1-i2BcT+NCU+M@public.gmane.org>
---
 include/infiniband/mad.h |    2 ++
 src/libibmad.map         |    2 ++
 src/mad_internal.h       |    1 +
 src/smp.c                |   12 ++++++++++++
 4 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/include/infiniband/mad.h b/include/infiniband/mad.h
index 5d62307..278b9bc 100644
--- a/include/infiniband/mad.h
+++ b/include/infiniband/mad.h
@@ -1489,6 +1489,8 @@ MAD_EXPORT uint8_t *smp_set_status_via(void *data, ib_portid_t * portid,
 				       unsigned attrid, unsigned mod,
 				       unsigned timeout, int *rstatus,
 				       const struct ibmad_port *srcport);
+MAD_EXPORT void smp_mkey_set(struct ibmad_port *srcport, uint64_t mkey);
+MAD_EXPORT uint64_t smp_mkey_get(const struct ibmad_port *srcport);
 
 /* cc.c */
 MAD_EXPORT void *cc_query_status_via(void *rcvbuf, ib_portid_t * portid,
diff --git a/src/libibmad.map b/src/libibmad.map
index 7c7587b..a4d4418 100644
--- a/src/libibmad.map
+++ b/src/libibmad.map
@@ -146,5 +146,7 @@ IBMAD_1.3 {
 		mad_dump_port_ext_speeds_counters;
 		cc_query_status_via;
 		cc_config_status_via;
+		smp_mkey_get;
+		smp_mkey_set;
 	local: *;
 };
diff --git a/src/mad_internal.h b/src/mad_internal.h
index 3c32d10..5deac27 100644
--- a/src/mad_internal.h
+++ b/src/mad_internal.h
@@ -40,6 +40,7 @@ struct ibmad_port {
 	int port_id;		/* file descriptor returned by umad_open() */
 	int class_agents[MAX_CLASS];	/* class2agent mapper */
 	int timeout, retries;
+	uint64_t smp_mkey;
 };
 
 extern struct ibmad_port *ibmp;
diff --git a/src/smp.c b/src/smp.c
index a337663..14c74ed 100644
--- a/src/smp.c
+++ b/src/smp.c
@@ -46,6 +46,16 @@
 #undef DEBUG
 #define DEBUG 	if (ibdebug)	IBWARN
 
+void smp_mkey_set(struct ibmad_port *srcport, uint64_t mkey)
+{
+	srcport->smp_mkey = mkey;
+}
+
+uint64_t smp_mkey_get(const struct ibmad_port *srcport)
+{
+	return srcport->smp_mkey;
+}
+
 uint8_t *smp_set_status_via(void *data, ib_portid_t * portid, unsigned attrid,
 			    unsigned mod, unsigned timeout, int *rstatus,
 			    const struct ibmad_port *srcport)
@@ -67,6 +77,7 @@ uint8_t *smp_set_status_via(void *data, ib_portid_t * portid, unsigned attrid,
 	rpc.timeout = timeout;
 	rpc.datasz = IB_SMP_DATA_SIZE;
 	rpc.dataoffs = IB_SMP_DATA_OFFS;
+	rpc.mkey = srcport->smp_mkey;
 
 	portid->sl = 0;
 	portid->qp = 0;
@@ -105,6 +116,7 @@ uint8_t *smp_query_status_via(void *rcvbuf, ib_portid_t * portid,
 	rpc.timeout = timeout;
 	rpc.datasz = IB_SMP_DATA_SIZE;
 	rpc.dataoffs = IB_SMP_DATA_OFFS;
+	rpc.mkey = srcport->smp_mkey;
 
 	if ((portid->lid <= 0) ||
 	    (portid->drpath.drslid == 0xffff) ||
-- 
1.7.1



--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Hal Rosenstock]

On 3/6/2012 5:12 PM, Jim Foraker 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.

> Signed-off-by: Jim Foraker <foraker1-i2BcT+NCU+M@public.gmane.org>
> ---
>  include/infiniband/mad.h |    2 ++
>  src/libibmad.map         |    2 ++
>  src/mad_internal.h       |    1 +
>  src/smp.c                |   12 ++++++++++++
>  4 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/include/infiniband/mad.h b/include/infiniband/mad.h
> index 5d62307..278b9bc 100644
> --- a/include/infiniband/mad.h
> +++ b/include/infiniband/mad.h
> @@ -1489,6 +1489,8 @@ MAD_EXPORT uint8_t *smp_set_status_via(void *data, ib_portid_t * portid,
>  				       unsigned attrid, unsigned mod,
>  				       unsigned timeout, int *rstatus,
>  				       const struct ibmad_port *srcport);
> +MAD_EXPORT void smp_mkey_set(struct ibmad_port *srcport, uint64_t mkey);
> +MAD_EXPORT uint64_t smp_mkey_get(const struct ibmad_port *srcport);
>  
>  /* cc.c */
>  MAD_EXPORT void *cc_query_status_via(void *rcvbuf, ib_portid_t * portid,
> diff --git a/src/libibmad.map b/src/libibmad.map
> index 7c7587b..a4d4418 100644
> --- a/src/libibmad.map
> +++ b/src/libibmad.map
> @@ -146,5 +146,7 @@ IBMAD_1.3 {
>  		mad_dump_port_ext_speeds_counters;
>  		cc_query_status_via;
>  		cc_config_status_via;
> +		smp_mkey_get;
> +		smp_mkey_set;
>  	local: *;
>  };
> diff --git a/src/mad_internal.h b/src/mad_internal.h
> index 3c32d10..5deac27 100644
> --- a/src/mad_internal.h
> +++ b/src/mad_internal.h
> @@ -40,6 +40,7 @@ struct ibmad_port {
>  	int port_id;		/* file descriptor returned by umad_open() */
>  	int class_agents[MAX_CLASS];	/* class2agent mapper */
>  	int timeout, retries;
> +	uint64_t smp_mkey;

Is this mkey for this port or all ports in the subnet ? Looks to me from
usage that it's all ports in the subnet.

-- Hal

>  };
>  
>  extern struct ibmad_port *ibmp;
> diff --git a/src/smp.c b/src/smp.c
> index a337663..14c74ed 100644
> --- a/src/smp.c
> +++ b/src/smp.c
> @@ -46,6 +46,16 @@
>  #undef DEBUG
>  #define DEBUG 	if (ibdebug)	IBWARN
>  
> +void smp_mkey_set(struct ibmad_port *srcport, uint64_t mkey)
> +{
> +	srcport->smp_mkey = mkey;
> +}
> +
> +uint64_t smp_mkey_get(const struct ibmad_port *srcport)
> +{
> +	return srcport->smp_mkey;
> +}
> +
>  uint8_t *smp_set_status_via(void *data, ib_portid_t * portid, unsigned attrid,
>  			    unsigned mod, unsigned timeout, int *rstatus,
>  			    const struct ibmad_port *srcport)
> @@ -67,6 +77,7 @@ uint8_t *smp_set_status_via(void *data, ib_portid_t * portid, unsigned attrid,
>  	rpc.timeout = timeout;
>  	rpc.datasz = IB_SMP_DATA_SIZE;
>  	rpc.dataoffs = IB_SMP_DATA_OFFS;
> +	rpc.mkey = srcport->smp_mkey;
>  
>  	portid->sl = 0;
>  	portid->qp = 0;
> @@ -105,6 +116,7 @@ uint8_t *smp_query_status_via(void *rcvbuf, ib_portid_t * portid,
>  	rpc.timeout = timeout;
>  	rpc.datasz = IB_SMP_DATA_SIZE;
>  	rpc.dataoffs = IB_SMP_DATA_OFFS;
> +	rpc.mkey = srcport->smp_mkey;
>  
>  	if ((portid->lid <= 0) ||
>  	    (portid->drpath.drslid == 0xffff) ||

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Hefty, Sean]

> 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.

Is something more needed than just calling smp_mkey_set() to change it when needed?

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jason Gunthorpe]

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.

-- 
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>        (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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Ira Weiny]

On Fri, 9 Mar 2012 11:04:59 -0700
Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org> 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.

Jim already discussed that and we would like to do that but for now this will allow the diags to function with the current OpenSM model.

Ira

> 
> -- 
> Jason Gunthorpe <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>        (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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Ira Weiny
Member of Technical Staff
Lawrence Livermore National Lab
925-423-8008
weiny2-i2BcT+NCU+M@public.gmane.org
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jim Foraker]

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jason Gunthorpe]

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 <jgunthorpe-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>        (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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jim Foraker]

On Fri, 2012-03-09 at 13:01 -0800, Jason Gunthorpe wrote:
> 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.
     Large random strings end up having to be stored on disk, which may
be its own issue.  An attacker need not bother with a preimage attack at
all if the admin has copied a bulky keyfile to every host so as to make
their lives tenable.  "Well they shouldn't do that" may not be listened
to any better than "don't use weak passwords" has been.
     I like PBKDF2 because it's simple to add on top of a HMAC, and
provides easily-tunable key stretching.  Going to SHA2-512 makes the
stretching far less important with sufficient key material, but it's
still of benefit, particularly if that material isn't as good as you
wish it was.

> >      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.
      Oh, that's certainly the intent.  The reality though is that at
multiple layers, mkeys have not been thought about, not been
well-tested, or have been hacked in clearly as an afterthought in
current codebases.  My hope is that there are not any inherent
weaknesses in the spec.  My expectation is that there are several
exploitable weaknesses in the code.  If we want to install a stronger
front door, it would behoove us to make sure the windows aren't already
the weakest link.

> 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.
     B is potentially equivalent to using a perfectly secure KDF of some
sort.  "Perfect security" being what it is though, there may be some
folks who just don't want to risk any sort of preimage attack. A's
security depends on how that config file is generated and distributed.
Its key benefit is simplicity and configurability -- the admin gets free
reign to generate keys however they want, according to local needs and
policy.  They also get to keep the file up to date with new guids as
hardware comes and goes.
     In my mind, the most useful way forward is derived keys of some
sort.  However, I don't think it's necessarily a one-size-fits-all
solution, and supporting a few differing schemes seems reasonable to me.

     Jim

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Hal Rosenstock]

On 3/9/2012 12:09 PM, Hefty, Sean 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.
> 
> Is something more needed than just calling smp_mkey_set() to change it when needed?

I don't think so but the "tricky" part is the mkey itself.

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Hal Rosenstock]

On 3/9/2012 1:04 PM, 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.

As there is no standard for this and there are various different
requirements here, I'm not sure that one algorithm fits all so IMO it's
best to make this as flexible as possible and allow for various
algorithms/approaches to be open sourced.

-- Hal
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jason Gunthorpe]

On Tue, Mar 13, 2012 at 08:31:50AM -0400, Hal Rosenstock wrote:
> On 3/9/2012 1:04 PM, 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.
> 
> As there is no standard for this and there are various different
> requirements here, I'm not sure that one algorithm fits all so IMO it's
> best to make this as flexible as possible and allow for various
> algorithms/approaches to be open sourced.

That would be a disaster from a usability and security perspective. We
need one really good standard, not tens of half baked ideas. MKey
generation is such a minor point in the grand scheme of things, giving
people lots of choice makes no sense.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jason Gunthorpe]

On Fri, Mar 09, 2012 at 05:09:07PM -0800, Jim Foraker wrote:

> > 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.

>      Large random strings end up having to be stored on disk, which may
> be its own issue.  An attacker need not bother with a preimage attack at
> all if the admin has copied a bulky keyfile to every host so as to make
> their lives tenable.  "Well they shouldn't do that" may not be listened
> to any better than "don't use weak passwords" has been.

Sure, but the only other options that have been brought up:
  a) A config file of keys - that has to be copied too
  b) completely random keys (in a file) - that has to be copied
  c) A password - is weak to offline attacks, and if an attaker can
     compromise a secure file then they can probably compromise the
     tool that accepts the password from the admin.

So, it really isn't much of a difference at all.

In truth, we probably don't want to distribute anything to the
hosts, but rely on some kind of authenticated transaction with the SA
to fetch the mkey data. Eg the admin could use his kerberos login
ticket to get the mkey of a node from the SA's database. (Of course, if
you could steal the key file, you can probably steal a kerberos ticket
as well..)

> exploitable weaknesses in the code.  If we want to install a stronger
> front door, it would behoove us to make sure the windows aren't already
> the weakest link.

Unless someone gets a viable mkey model working none of the vendors
are really going to care if their implementations are any good..

>      B is potentially equivalent to using a perfectly secure KDF of some
> sort.  "Perfect security" being what it is though, there may be some
> folks who just don't want to risk any sort of preimage attack. 

These folks should be using pkey to prevent SMA's from even being
contacted by an untrustable end port.

> A's security depends on how that config file is generated and
> distributed.  Its key benefit is simplicity and configurability --
> the admin gets free reign to generate keys however they want,
> according to local needs and policy.  

That would almost certainly be a distaster, very few sites would have
the skills to make this work, and IMHO, the gain over a secure
generator is very negligible.

> up to date with new guids as hardware comes and goes.  In my mind,
> the most useful way forward is derived keys of some sort.  However,
> I don't think it's necessarily a one-size-fits-all solution, and
> supporting a few differing schemes seems reasonable to me.

It is always prudent to have some way to upgrade algorithms when doing
crypto, but I really disagree that introducing complexity for
something as minor as mkey is a good choice. People are far more
likely to make a bad choice and get no meaningful security at all.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Hal Rosenstock]

On 3/13/2012 12:35 PM, Jason Gunthorpe wrote:
> On Tue, Mar 13, 2012 at 08:31:50AM -0400, Hal Rosenstock wrote:
>> On 3/9/2012 1:04 PM, 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.
>>
>> As there is no standard for this and there are various different
>> requirements here, I'm not sure that one algorithm fits all so IMO it's
>> best to make this as flexible as possible and allow for various
>> algorithms/approaches to be open sourced.
> 
> That would be a disaster from a usability and security perspective. We
> need one really good standard, not tens of half baked ideas. MKey
> generation is such a minor point in the grand scheme of things, giving
> people lots of choice makes no sense.

I've already heard several ideas on what MKey generation should be and
not just the ones on the list so far. I doubt there will be agreement by
all parties on this and I think different schemes can be accommodated.
It's either that or the standard tools will support one scheme and there
will be several "proprietary" variants of the tools in those
environments which I think would not be good.

-- Hal

> Jason
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jim Foraker]

On Tue, 2012-03-13 at 09:50 -0700, Jason Gunthorpe wrote: 
> On Fri, Mar 09, 2012 at 05:09:07PM -0800, Jim Foraker wrote:
> 
> > > 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.
> 
> >      Large random strings end up having to be stored on disk, which may
> > be its own issue.  An attacker need not bother with a preimage attack at
> > all if the admin has copied a bulky keyfile to every host so as to make
> > their lives tenable.  "Well they shouldn't do that" may not be listened
> > to any better than "don't use weak passwords" has been.
> 
> Sure, but the only other options that have been brought up:
>   a) A config file of keys - that has to be copied too
>   b) completely random keys (in a file) - that has to be copied
>   c) A password - is weak to offline attacks, and if an attaker can
>      compromise a secure file then they can probably compromise the
>      tool that accepts the password from the admin.
> 
> So, it really isn't much of a difference at all.
     If the random keys in b) are stored in a file, then it simply
becomes a specific case of a).  A better way of phrasing the b) idea
would be, the SM generates the MKey, and if you wish to use it, your
only choice is to ask the SM for it.
     a) is certainly the same as your suggestion of a KDF with a long
string stored in a file, inasmuch as access to the file gives you quick
access to the keys.  Actually, it's a little worse with a) -- at
protection level 2, one could just send SMPs to a port iterating thru
all the mkeys in the file until one works, whereas with the KDF, you're
going to have to figure out its guid first (although that's still
probably not hard).
     I see the essential difference between "large random strings" and
"passwords" as being, where is keying material stored?  Regardless of
key length or strength, if the means of providing tools with the key is
sufficiently onerous, it will be worked around.  For passwords, that
means post-it notes under keyboards.  For keyfiles, that means copying
the file to a network filesystem and/or every host you might want to use
it from.  This works for rndc, because there's generally little reason
for domain admins to "stray" too far from a small number of DNS servers
for zone work.  My impression is that most IB admins want to be able to
run diagnostics from anywhere on the fabric, which implies much wider
deployment.  For the most part, if the keyfile ends up on every host,
it's not all that different than just using a single mkey across the
fabric.
     Certainly, if a text file can be compromised, a binary can too.
But the admin still has to go login to the compromised host and type the
password -- it's not there waiting to be taken on every host.  It's a
tradeoff of risks.
     Another option would be to use a "hybrid" distribution method, a la
HKDF.  Jason's suggestion is trivially close to the HKDF "expand" step
(given that output is less than hash size), either of which could be
used with appropriate host-specific information thrown in.  One could
optionally either read that master key directly from a keyfile, or
frontend it with one of the popular strengthening algorithms that
derives the master key from an easier-to-type/remember password.  Since
this strengthening only needs to be done once (unlike my earlier PBKDF2
suggestion), some serious CPU power could be devoted to it (seconds or
fractions thereof).  Combined with some good salting based on other
config file values, this would make it reasonably difficult to crack
most non-trivial passwords.

> In truth, we probably don't want to distribute anything to the
> hosts, but rely on some kind of authenticated transaction with the SA
> to fetch the mkey data. Eg the admin could use his kerberos login
> ticket to get the mkey of a node from the SA's database. (Of course, if
> you could steal the key file, you can probably steal a kerberos ticket
> as well..)
     This already exists, in the form of smkey-authenticated access to
SA PortInfo Records, and should probably be the preferred way of
fetching mkeys.  The question is, how do you determine mkeys when the SA
is hosed or otherwise inoperative?  If the answer is, "you don't," then
there's no reason to bother with a KDF over random assignment.

> > exploitable weaknesses in the code.  If we want to install a stronger
> > front door, it would behoove us to make sure the windows aren't already
> > the weakest link.
> 
> Unless someone gets a viable mkey model working none of the vendors
> are really going to care if their implementations are any good..
     That's the thing I'm hoping we can do here -- and where I think the
real concern is.  What particular key model to use is secondary to
determining what rules must be followed to ensure keys aren't
accidentally disclosed.
     For instance, one could imagine an attacker sitting on a
compromised host and changing the port guid of the HCA to the guid of
another host on the fabric.  I previously found code in OpenSM (although
I'm not seeing it at the moment) that looked like it would prevent this
attack, but only as a side effect.  This could fail however if a) the
attacker has managed to temporarily force the other HCA offline somehow,
b) the SM is not the current OpenSM and lacks this protection, or c) the
attacker convinces OpenSM to restart and gets initialized before the
legitimate HCA.  If the SM uses a mapping based solely on port guid, it
will generously hand a valid mkey over to the attacker.
     Adding LID to the keying information seems like it might be useful,
since it's harder for the attacker to control, but this doesn't help in
case c, since the impostor HCA will probably also get assigned the
legitimate HCA's LID, pulled from the guid2lid file.  Adding directed
route information seems like the hardest thing for an attacker to foil,
but I don't know that random clients can easily compute the directed
route the SM happens to use on all fabrics.
     I suspect that there are a number of cases like this lurking, which
we should try to understand so that we know whether a KDF (or
potentially any multi-key algorithm) can be securely deployed, and what
types of seed information will be needed to do so.

> >      B is potentially equivalent to using a perfectly secure KDF of some
> > sort.  "Perfect security" being what it is though, there may be some
> > folks who just don't want to risk any sort of preimage attack. 
> 
> These folks should be using pkey to prevent SMA's from even being
> contacted by an untrustable end port.
     SMPs are not bound by partitioning.  The SA will respect
partitioning WRT filtering results, but any host can talk directly to
any endpoint's SMA, even if the spec says they should refrain from doing
so.

> > A's security depends on how that config file is generated and
> > distributed.  Its key benefit is simplicity and configurability --
> > the admin gets free reign to generate keys however they want,
> > according to local needs and policy.  
> 
> That would almost certainly be a distaster, very few sites would have
> the skills to make this work, and IMHO, the gain over a secure
> generator is very negligible.
     My suspicion is that very few sites with sufficient clue to
successfully deploy IB are really going to trip horribly over
maintaining a text file.  Certainly, distributing a file with n keys is
no harder than distributing a file with one master key.  Also, "how it's
distributed" may mean, "it's only available to the SM, and other clients
lose."  A is a poor solution in terms of protecting users from
themselves.  A is a great solution in terms of flexibility and tool
simplicity.  It abdicates SMs and utils from fretting about policy, and
lets them concentrate on implementation.  It's yet another variant on
"do one thing and do it well."  That doesn't mean I'm keen to deploy it.

> > up to date with new guids as hardware comes and goes.  In my mind,
> > the most useful way forward is derived keys of some sort.  However,
> > I don't think it's necessarily a one-size-fits-all solution, and
> > supporting a few differing schemes seems reasonable to me.
> 
> It is always prudent to have some way to upgrade algorithms when doing
> crypto, but I really disagree that introducing complexity for
> something as minor as mkey is a good choice. People are far more
> likely to make a bad choice and get no meaningful security at all.
     Most likely, people will make no choice at all and use a default,
until they find it annoying or insufficient for their purposes.  I think
ideally we need as few methods as possible, as many as necessary, and a
really good default.  I won't claim to know how many are truly
necessary, but I can certainly see wanting two (a KDF of some form, and
random distributed via SA only), if not three ("legacy" single key).
None of these seem outrageous, and provide clear tradeoffs between
security and ease of use to meet different organization's needs.
     Pragmatically though, I don't think there's a necessity for
complete standardization.  There is great benefit to using common
methods, and that should be encouraged, but maintainers should implement
(or choose not to implement) policies in the manner they believe is in
the best interests of their users.  

     Jim
> 
> Jason

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH fixed] libibmad: Add MKey support to SMP requests via smp_mkey_get/set()

[Jason Gunthorpe]

On Thu, Mar 15, 2012 at 05:27:12PM -0700, Jim Foraker wrote:

> for zone work.  My impression is that most IB admins want to be able to
> run diagnostics from anywhere on the fabric, which implies much wider
> deployment.  For the most part, if the keyfile ends up on every host,
> it's not all that different than just using a single mkey across the
> fabric.

It is really hard to make something that is reistant to a potentially
compromised host while still allowing that hose to access a shared
secret key.. That is a loosing battle. People who care about MKey
security have to give up runing diags on potentially compromised hosts.

>      Another option would be to use a "hybrid" distribution method, a la
> HKDF.  Jason's suggestion is trivially close to the HKDF "expand"
> step

Specifying HMAC-something-something as the MKey generator and then
providing an option to produce the fixed length HMAC key via password
expander algorithm seems reasonable to me. People who want that can
generate their key blob file from a password, or do it on the fly in a
tool.

The HMAC-something-something key file could even be password encrypted
for use by the diags, and this could be done in a diag-tool-specific
manner. The SM need not care about that.

These address both of your concerns while keeping the SM operation,
and the actual generation of the MKey straightforward and something we
should be able to agree on.

> > In truth, we probably don't want to distribute anything to the
> > hosts, but rely on some kind of authenticated transaction with the SA
> > to fetch the mkey data. Eg the admin could use his kerberos login
> > ticket to get the mkey of a node from the SA's database. (Of course, if
> > you could steal the key file, you can probably steal a kerberos ticket
> > as well..)

>      This already exists, in the form of smkey-authenticated access to
> SA PortInfo Records, and should probably be the preferred way of

I'm not sure SMKey is well specified enough for this, and even if it
is, you've just re-created the global well known mkey problem.

> fetching mkeys.  The question is, how do you determine mkeys when the SA
> is hosed or otherwise inoperative?  If the answer is, "you don't," then
> there's no reason to bother with a KDF over random assignment.

My preference for a algorithmic derivation and outright rejection of
other options is due to recovery and clustering of the SM. It should
not be possible to loose or corrupt the SM MKey database, even when it
is being dynamically modified as nodes come and go. The simplest
approach is via a GUID hashing scheme, eg HMAC, or something
functionally analogous.

Considering the case of a clustered SM, it is simply too much
complexity for no real gain to make MKey into an actual transactional
database, which is pretty much required for any other scheme.

> > > exploitable weaknesses in the code.  If we want to install a stronger
> > > front door, it would behoove us to make sure the windows aren't already
> > > the weakest link.
> > 
> > Unless someone gets a viable mkey model working none of the vendors
> > are really going to care if their implementations are any good..

>      That's the thing I'm hoping we can do here -- and where I think the
> real concern is.  What particular key model to use is secondary to
> determining what rules must be followed to ensure keys aren't
> accidentally disclosed.

>      For instance, one could imagine an attacker sitting on a
> compromised host and changing the port guid of the HCA to the guid of
> another host on the fabric.  I previously found code in OpenSM (although
> I'm not seeing it at the moment) that looked like it would prevent this
> attack, but only as a side effect.  This could fail however if a) the
> attacker has managed to temporarily force the other HCA offline somehow,
> b) the SM is not the current OpenSM and lacks this protection, or c) the
> attacker convinces OpenSM to restart and gets initialized before the
> legitimate HCA.  If the SM uses a mapping based solely on port guid, it
> will generously hand a valid mkey over to the attacker.

Yes, you are absolutely right. A compromised end port discloses many
mkeys without heroics on the part of the SM to prevent that.

A SM would have to tie port GUIDs to valid locations within the
fabric, which would greatly complicate administration of some classes
of system.

Or the spec has to be updated to use real crypto, and out of band
keying to secure SMPs. (This would not be a bad thing...)

>      Adding LID to the keying information seems like it might be useful,
> since it's harder for the attacker to control, but this doesn't help in
> case c, since the impostor HCA will probably also get assigned the
> legitimate HCA's LID, pulled from the guid2lid file. 

Yes, the LID doesn't really add value.

> Adding directed route information seems like the hardest thing for
> an attacker to foil, but I don't know that random clients can easily
> compute the directed route the SM happens to use on all fabrics.

The SM would have to essentially tie a port GUID to being connected to
a specific switch port, and an admin would have to intervene if things
are re-cabled.

We can't include directed route information in the MKey value, if you
re-cable then you have to reset the MKeys, which is not the intended
use-model for MKey.

>      I suspect that there are a number of cases like this lurking, which
> we should try to understand so that we know whether a KDF (or
> potentially any multi-key algorithm) can be securely deployed, and what
> types of seed information will be needed to do so.

Unfortunately I don't think the spec was really intended to be secure
against a rouge end point..

> > These folks should be using pkey to prevent SMA's from even being
> > contacted by an untrustable end port.
>      SMPs are not bound by partitioning.  The SA will respect
> partitioning WRT filtering results, but any host can talk directly to
> any endpoint's SMA, even if the spec says they should refrain from doing
> so.

... case in point. I think you are right (I was thinking of GMPs, eg
for perfmon). Adding PKey filtering for SMPs ultimately would be of
more help than all this mkey stuff.
 
> > > A's security depends on how that config file is generated and
> > > distributed.  Its key benefit is simplicity and configurability --
> > > the admin gets free reign to generate keys however they want,
> > > according to local needs and policy.  
> > 
> > That would almost certainly be a distaster, very few sites would have
> > the skills to make this work, and IMHO, the gain over a secure
> > generator is very negligible.
>      My suspicion is that very few sites with sufficient clue to
> successfully deploy IB are really going to trip horribly over
> maintaining a text file.  Certainly, distributing a file with n keys is
> no harder than distributing a file with one master key. 

Maintaing a text file with N securely created random numbers mapped
exactly to GUIDs in the fabric, such that GUIDs are in the text file
before joining the fabric and once a line it added it is never
lost, removed or changed? Kept perfectly in sync across all SMs in the
cluster? That is a pretty aweful problem to saddle someone with.

You've already pointed out many real ways the mkey can be exposed, so
I'm not seeing the point in overkilling the generation of the
key. Or really even a reason to provide choice. Nobody would ever
attack the source of MKeys when there are much easier avenues to
approach.

The only value is going from a well known single mkey to port-unique
mkeys, and I think that should be the only choice presented to the
user.

Jason
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html