Re: Determining strength of encryption provided by a GSS-API mechanism

[Alexey Melnikov <alexey.melnikov at isode.com>]

Nicolas Williams wrote:

> On Wed, Aug 12, 2009 at 09:08:53PM +0100, Alexey Melnikov wrote:
>  
>
> > > Though we've discussed designs for APIs that allow applications to
> > > request / determine which strength profiles to use / are in use.
> > >      
> > Can you provide a pointer?
> >    
> Searching my sent box for mails with "qop" in the subject I see this:
>
>    Date: Fri, 22 Sep 2006 10:33:34 -0500
>    From: Nicolas Williams <Nicolas.Williams at sun.com>
>    To: Alexey Melnikov <alexey.melnikov at isode.com>
>    Cc: Hai Zaar <haizaar at gmail.com>, kitten at ietf.org
>    Subject: GSS-API QoPs and SASL SSF (Re: SASL always returns ssf=56 for GSSAPI)
>  
:-).

> > > IMO only relative strength should matter,
> > >      
> > This is how SSF is used, for the most part. But you are right, there is 
> > no way to reclassify a cipher as weak using SSF.
> >    
> Apps hardcode SSF values at build time,
Actually apps don't. My server certainly doesn't. It has 2 file 
configuration options: min_ssf and max_ssf for controlling use of 
security layers.

> as do mechanisms.
Mechanisms do, because they have no way of learning from GSS-API. So 
either mechanisms have to hardcode the highest known value, or they need 
to lie that they support certain SSF.

> That means
> they can't be changed without rebuilding and redeploying code.  That's
> bad.
>
> There's other things that are bad:
>
> - numbers for this just suck; policy names are much better
>  
Well, it means you need to have entirely different API and, more 
importantly, UI for managing such policies. Good UIs like this are 
difficult.

> - strength may be context-specific, as in the case of the Kerberos V
>   GSS-API mechanism (where the enctype used is completely independent
>   of the SASL mechanism name / GSS mech OID)
>