Re: Determining strength of encryption provided by a GSS-API mechanism
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Determining strength of encryption provided by a GSS-API mechanism
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, as do mechanisms. 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
- 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)
> Well, if the WG can provide a way to control and determine which ciphers
> are supported, this would be great.
One could do this with an extension for credentials acquisition, another
for security context inquiry, and a way to do policy<->QoP mapping
(though one would never need it -- just for completeness). Something
like:
/*
* Set the policy that may be used to establish security contexts, and
* the policy that will be used as the default QoP (GSS_C_QOP_DEFAULT)
* for per-message token functions (gss_wrap() and friends).
*
* (We could also just add a variant of gss_add/acquire_cred() instead
* of modifying an existing cred handle.)
*/
OM_uint32
gss_set_cred_policy(
OM_uint32 *minor_status,
gss_cred_id_t input_cred,
gss_OID mech,
gss_cred_id_t *output_cred,
gss_buffer_t context_establishement_policy,
gss_buffer_t per_msg_token_policy
);
OM_uint32
gss_add_cred_policy(
/* same args as gss_add_cred() */
...
/* plus: */
gss_buffer_t context_establishement_policy,
gss_buffer_t per_msg_token_policy
);
...
/*
* Find out the name of a policy that was used to establish a security
* context, and the name of the policy that set the default QoP for that
* security context.
*/
OM_uint32
gss_inquire_sec_context_policy(
OM_uint32 *minor_status,
gss_ctx_id_t ctx,
gss_buffer_t context_establishement_policy,
gss_buffer_t per_msg_token_policy
);
OM_uint32
gss_qop_to_policy(
OM_uint32 *minor_status,
gss_buffer_t per_msg_token_policy,
gss_qop_t *qop
);
OM_uint32
gss_policy_to_qop(
OM_uint32 *minor_status,
gss_qop_t qop,
gss_buffer_t per_msg_token_policy
);
Nico
--
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.