[ofa-general] Re: [PATCH] saquery: --smkey command line option

[Ira Weiny]

On Fri, 23 May 2008 04:07:35 -0700
Hal Rosenstock <hrosenstock at xsigo.com> wrote:

> On Thu, 2008-05-22 at 15:47 -0700, Ira Weiny wrote:
> > I guess my question is "does saquery need this to talk to the SA?"
> > 
> > I am assuming the answer is "yes".
> 
> It depends on whether trusted operations are needed to be supported or
> not. A normal node has no need for trusted operations. There was a
> reason why the additional information was hidden with a key. It allows a
> malicious user to effect not just his node but the subnet.

Ok...  I guess from your other emails the point is that ULP's must get these
keys by some "out of spec" method?  saquery only queries information, much of
which I think ULP's require to establish connections etc.  How are others
solving this problem?

> 
> As I mentioned, this starts to be a slippery slope with the management
> keys. I think a better approach when non default key is in place is to
> support this via the OpenSM console as OpenSM knows all the keys it's
> supposed to.

<just thinking out loud...>
   When you mention this I start to think about the secure API which Tim
   submitted a few months ago and was not accepted.  I know we are still
   discussing how to do "secure console" but perhaps this is a very valid use
   case for the SM to answer SSL socket connections to get keys?
</thinking> (yea, no longer thinking...  ;-)

Ira

> 
> > I noticed this in the spec section 14.4.7 page 890:
> > 
> >    "The SM Key used for SM authentication is independent of the SM Key in the
> >    SA header used for SA authentication."
> > 
> > Does this mean there could be 2 SM_Key values in use?
> 
> This was a clarification added at IBA 1.2.1. The SA SMKey is really an
> SA Key. This lack of separation is a limitation in the current OpenSM
> implementation.
> 
> -- Hal
> 
> > Ira
> > 
> > 
> > On Thu, 22 May 2008 08:10:29 -0700
> > Hal Rosenstock <hrosenstock at xsigo.com> wrote:
> > 
> > > On Thu, 2008-05-22 at 17:56 +0300, Sasha Khapyorsky wrote:
> > > > On 07:46 Thu 22 May     , Hal Rosenstock wrote:
> > > > > Sasha,
> > > > > 
> > > > > On Thu, 2008-05-22 at 16:53 +0300, Sasha Khapyorsky wrote:
> > > > > > This adds possibility to specify SM_Key value with saquery. It should
> > > > > > work with queries where OSM_DEFAULT_SM_KEY was used.
> > > > > 
> > > > > I think this starts down a slippery slope and perhaps bad precedent for
> > > > > MKey as well. I know this is useful as a debug tool but compromises what
> > > > > purports as "security" IMO as this means the keys need to be too widely
> > > > > known.
> > > > 
> > > > When different than OSM_DEFAULT_SM_KEY value is configured on OpenSM
> > > > side an user may know this or not, in later case saquery will not work
> > > > (just like now). I don't see a hole.
> > > 
> > > I think it will tend towards proliferation of keys which will defeat any
> > > security/trust. The idea of SMKey was to keep it private between SMs.
> > > This is now spreading it wider IMO. I'm sure other patches will follow
> > > in the same vein once an MKey manager exists.
> > > 
> > > -- Hal
> > > 
> > > > Sasha
> > > 
>