Subject: Re: [SPKM] Interoperability

From: Martin Rex <[email-masked]>
Date: Fri, 3 Nov 2006 20:36:19 +0100 (MET)

Nicolas Williams wrote:
> 
> On Tue, Oct 31, 2006 at 02:23:50PM -0500, Sam Hartman wrote:
> > * When will we get a spec out?  How long will the market wait?
> >   Sometimes, you have to accept that the market will deploy something
> >   and you have little influence on it.  In those cases it's better to
> >   write a compelling spec and hope that people will migrate.  Other
> >   times, if you can stretch to meet market timing, you can avoid the
> >   market deploying something that does not meet your spec.  That is
> >   very desirable.
> 
> If we cannot get a spec that will meet our needs in time for the market
> then the proposed protocol could go to Informational and a spec that
> does meet our needs can later go to Proposed-Standard, using a different
> OID.

There is a problem in the traditional (simple) GSS-API and how it is
embedded within several application protocols, that there is no
negotiation of a mechanism (OID).  In real distributed environments,
where a component is both, server and client, a switch to a new
OID might require a "flag day".  Depending on the implementation
(and we know that SPKM is underspecified in this area), an updated
enhanced GSS-API mechanism might use the new OID also in the
generic framing of the exported binary canonical name, and
as a result might not reuse any of the existing ACLs based
on binary canonical names...

The use of the mechanism OID in the generic framing of exported
binary canonical names was (primarily) meant to prevent accidental
collisions of two names from distinct namespaces referring to
distinct entities, not to ultimately require distinct exported
names based on the employed authentication mechanism (although
I admit that some saw this as a potential feature, being able
to distinguish mechanisms of different strength in the ACL).

Personally, I see a real benefit if mechanisms sharing a common
namespace can share ACLs, be that ACLs with printable or
binary canonical names.

-Martin

_______________________________________________
SPKM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/spkm

---

From: Sam Hartman <[email-masked]>
Date: Fri, 03 Nov 2006 17:26:35 -0500

>>>>> "Martin" == Martin Rex <[email-masked]> writes:

    Martin> Nicolas Williams wrote:
    >> > * When will we get a spec out?  How long will the market
    >> wait?  > Sometimes, you have to accept that the market will
    >> deploy something > and you have little influence on it.  In
    >> those cases it's better to > write a compelling spec and hope
    >> that people will migrate.  Other > times, if you can stretch to
    >> meet market timing, you can avoid the > market deploying
    >> something that does not meet your spec.  That is > very
    >> desirable.
    >> 
    >> If we cannot get a spec that will meet our needs in time for
    >> the market then the proposed protocol could go to Informational
    >> and a spec that does meet our needs can later go to
    >> Proposed-Standard, using a different OID.

    Martin> There is a problem in the traditional (simple) GSS-API and
    Martin> how it is embedded within several application protocols,
    Martin> that there is no negotiation of a mechanism (OID).  In
    Martin> real distributed environments, where a component is both,
    Martin> server and client, a switch to a new OID might require a
    Martin> "flag day".  

This BOF at least is has a primary goal of trying to solve the problem
for NFS which does have a negotiation mechanism.

We, implementeres are also trying to make SPNEGO much more widely
available.

However you are completely correct that upgrading a specific
deployment can be difficult in the absence of negotiation.  I'm not
sure what to do about this problem other than acknowledge it and
encourage use of negotiation.