Subject: GSS-API QoPs and SASL SSF (Re: SASL always returns ssf=56 for GSSAPI)

From: Nicolas Williams <[email-masked]>
Date: Fri, 22 Sep 2006 10:33:34 -0500

Cc'ing KITTEN to record my thoughts on this topic, which started out as
a question about the SASL SSF of the SASL "GSSAPI" mechanism (as in "why
is it always 56?").

IMO absolute SSF values are a broken concept, and dangerous too, because
the relative strengths of individual cryptographic algorithms and
constructions vary over time as cryptanalysis develops.

Local SSF assignments based on local policy that does not rely on a
notion of absolute strength would be better.

Local policies alone would be even better.  (Of course, policies can be
distributed, but must be enforced locally.)

The GSS-API has a limited notion of QoPs that at least does not pretend
to be an absolute SSF-like thing.  Which is very good, but it has its
limitations.

On Fri, Sep 22, 2006 at 01:49:18PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> 
> >On Thu, Sep 21, 2006 at 06:06:57PM +0100, Alexey Melnikov wrote:
> > 
> >
> >>As far as I know there is no portable way to extract strength of the 
> >>strongest cipher from GSSAPI.
> >>Let me know if I am wrong.
> >>   
> >>
> >You are right.
> > 
> >
> So basically I was trying to use presence of a define for AES cipher as 
> a signal that the underlying GSS-API library supports AES. But I guess 
> it didn't work.
> Which GSS-API are you using?

First, the GSS-API notion of QoPs is mechanism-specific, and lacks
useful symbolic names (it's an integer namespace).

Second, there's no way to know what set of QoPs a mechanism[*] or
credential can negotiate.

Third, there's no way to constrain the set of QoPs that will be used nor
negotiated during security context establishment.

Fourth, there's no way to constrain the set of QoPs that a credential
handle can be used to negotiate during security context establishment.

The second, third and fourth points mean that one can't reject
mechanisms or credentials out of hand prior to negotiating mechanisms.
Thus one can negotiate a mechanism that you'll then decide is no good,
at which point one can typically only abort the connection/whatever (ONC
RPC w/ RPCSEC_GSS is an exception).

Fifth, the Kerberos V mechanism doesn't define any useful QoPs.  I think
it should, since:

    There is, however, a way to query what QoPs are available for an
    established security context: GSS_Wrap_size_limit() takes a QoP as
    input!  So if you know what QoPs are available for a mechanism then
    you can ask one by one which ones are available.

So it does make sense, I see now, to define QoPs for the Kerberos V
mechanism other than the default QoP.  Particularly if the limitations
of the GSS-API w.r.t. QoP negotiation are addressed.

I can see the following sorts of extensions to the GSS-API:

 - a function(s) to inquire QoPs supported by individual mechanisms
 - a function(s) to inquire QoPs supported by individual credentials
 - a function(s) to inquire QoPs supported by individual security contexts
   (iterating GSS_Wrap_size_limit() over known QoPs seems a bit clunky)

 - a function to map {qop_name, [mech_OID]} -> {qop_num,  description}
 - a function to map {qop_num, mech_OID}    -> {qop_name, description}

Finally, I think we need a general purpose (i.e., not specific to the
GSS-API) way to express cryptographic policy whereby: a) administrators
get to write simple, but meaningful policies, b) applications can refer
to these by name (including a default policy name), c) frameworks and
mechanisms can provide necessary details for policy evaluation.  Given
the above extensions then such policies could be applied to {mech_oid,
qop_num}, {mech_OID, qop_num_set/range}, {credential}, {credential,
mech_OID} and {security_context}.

[*]  The Solaris RPCSEC_GSS API does provide a way to list the QoPs
     supported by a GSS-API mechanism: see the
     rpc_gss_get_mech_info(3NSL) manpage.

     This relies on a file, /etc/gss/qop, that lists {qop_name, qop,
     mech_name} values.  But it could instead rely on the mechanisms
     providing the information directly through the SPI.

Nico
-- 

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