Subject: Impact of a new GSS mech on applications

From: "Josh Howlett" <[email-masked]>
Date: Fri, 20 Mar 2009 11:49:17 -0000

I understand that a GSS caller can either use a default mechanism, or
stipulate that a particular mechanism is used.

>From an application's PoV, what are the implications if a new mechanism
appears on the system?

For example, it seems to me (speaking from a positive of significant
ignorance about GSS) that an application might want impose a common
policy on certain features of GSS-API (anonymity, delegation) across all
mechanisms. However, it also seems that some mechanism-specific policy
might be needed (which mechanisms are permitted, quality of protection,
security services).

I am curious how contemporary applications deal with this.

TIA, josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Mar 2009 11:10:48 -0500

> From an application's PoV, what are the implications if a new mechanism

Acceptor applications are not affected.

For initiator applications:

 - If the application uses a specific mechanism: no impact.

 - If the application negotiates mechanisms: it depends.

   If the new mechanism is anything like SPNEGO, then it's important
   that the application not negotiate it.

   If the new mechanism does not provide per-message tokens but the
   application expects whatever mechanism it negotiates to provide
   per-message tokens then it's important that the application not
   negotiate it.

   Here it'd be useful to have APIs by which to find out about mechanism
   attributes like "is a mechanism-negotiation mechanism like SPNEGO,"
   and "supports wrap tokens" and so on.  In fact, there's an I-D for
   this: draft-ietf-kitten-extended-mech-inquiry-04.txt.

 - If the application uses the default mechanism: it depends on how the
   mechglue selects the default mechanism.

   For example, the Solaris libgss is very dumb about this: it uses the
   first mechanism listed in /etc/gss/mech.

   A better default mechanism selection would be: the first mechanism
   listed in /etc/gss/mech.mechanism listed in /etc/gss/mech for which
   there are initiator credentials.

> might be needed (which mechanisms are permitted, quality of protection,

Yes.

> I am curious how contemporary applications deal with this.

If they have such needs then they either fail if they negotiate a new
mechanism that does not meet those needs, or they must be updated to
blacklist such new mechanisms.

Thus draft-ietf-kitten-extended-mech-inquiry-04.txt.

Nico
--

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 20 Mar 2009 16:43:20 -0000

> > From an application's PoV, what are the implications if a new 
> > mechanism appears on the system?
> 

Doh, of course.

> > policy on certain features of GSS-API (anonymity, 
> delegation) across 
> > all mechanisms. However, it also seems that some mechanism-specific 
> > policy might be needed (which mechanisms are permitted, quality of 
> > protection, security services).
> 
> Yes.
> ...

That seems like a good idea to me, given the issues that you enumerated.

Thanks again for the great information.

josh.