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

[Hal Rosenstock]

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.

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.

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