On Fri, 23 May 2008 04:07:35 -0700 Hal Rosenstock <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > > > _______________________________________________ general mailing list [email protected] http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
