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

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Wed, Aug 12, 2009 at 11:26:28PM +0100, Alexey Melnikov wrote:
> Nicolas Williams wrote:
> >Searching my sent box for mails with "qop" in the subject I see this:
> 
> :-).

:)

> >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.

Ah, I stand corrected.

> >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.

Right.

> >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.

I have given the subject much thought, though intermittently, over the
past few years.  I believe the API that I've sketched for you is a very
good start, and that it makes it possible to have very simple UIs for
users and server configuration.

The hard part is about how to express policies.  E.g., a simple "must
use AES" is not enough, and policies are almost unavoidably going to
have mechanism-specific contents.  But fortunately, because policy
contents is a local problem, policy expression is not our problem here :)

(Policy interchange formats are not really a problem that we need to
solve either.  Standard policies could be expressed in English, with the
task of expressing them in machine-readable form being left to
implementors.)

Nico
--