[cryptography] IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM)

Nico Williams nico at cryptonector.com
Mon Jun 20 22:13:44 EDT 2011


On Mon, Jun 20, 2011 at 8:47 PM, James A. Donald <jamesd at echeque.com> wrote:
> On 2011-06-21 6:34 AM, Nico Williams wrote:
>>
>> The GSS-API has been growing extensions to deal with these situations
>> by exposing more information to the application.  There's also some
>> extensions by which to specify policies/profiles to apply.
>>
>> Creating a whole *new* API to layer above the GSS-API would be OK IFF
>> the new API were effectively a simplified profile of the GSS-API.
>
> The GSS-API has Kerberos implicitly baked into it - symmetric encryption,
> central trusted authority, function call oriented rather than message
> oriented.

Not so!  Please point to some evidence if you wish to insist on this.

I have plenty of evidence against your assertions:

 - Nowhere in the base GSS RFCs is there anything about naming trusted
third parties.  Kerberos realm names, for example, don't get named in
the GSS-API, and this is actually a problem for Kerberos (huh, so GSS
was originally less well-tailored for Kerberos than you assert).

 - Nowhere in the base GSS RFCs is there anything precluding the use
of asymmetric crypto.  Indeed, the original SPKM (simple pk mechanism)
had an option for disconnected messaging based on public key
signatures and encryption.  Additionally, there's now a new PKI-based
mechanism called "PKU2U" (see below).

 - The GSS-API is function call oriented, this is true, but when it
comes to messages there's just two pairs of functions: GSS_GetMIC()
and GSS_VerifyMIC() for HMAC-like messages, and GSS_Wrap() and
GSS_Unwrap() for container-type messages.  In fact, raw Kerberos has
nothing like MIC tokens, so that was a problem for the Kerberos
mechanism designers too (huh, another way in which the GSS-API wasn't
quite so well aligned with Kerberos).

 - There's a large number of GSS-API mechanisms that are either
specified and implemented, implemented with expired I-Ds, or in
process of being standardized:

    - SPKM (OK, this was never widely deployed, and the original spec
had so many problems that we eventually abandoned it)
    - Kerberos (the one you love to hate)
    - SCRAM (a DIGEST-MD5 successor, see RFC5802)
    - PKU2U (a successor to SPKM; implemented by MSFT, implemented in
a branch of Heimdal; I-D is currently)
    - GSS-EAP (work-in-progress in the IETF ABFAB WG, with
implementation also in progress)
    - Oauth (work-in-progress in the IETF KITTEN WG, with
implementation also in progress)
    - SAML (work-in-progress in the IETF KITTEN WG; I don't know of
its current implementation status)

   There have also been quite a few non-standard GSS-API mechanisms:

    - mech_dh (a GSS-based successor to the old, old AUTH_DH)
    - NTLM (don't laugh)
    - GSI has a TLS-as-GSS mechanism, which used "correctly" yields
on-the-wire compatibility with TLS apps (as long as there's no
re-negotiation)

   I made sure, for example, that SunSSH worked with mech_dh and
Kerberos, as those were the only mechanisms I had to work with back in
2004.  So I know that it is possible to write applications that use
the GSS-API in a mechanism-neutral way, and I've worked to add
extensions that make it easier to do that (and the problems addressed
by those extensions weren't that the API was too Kerberos-specific).

There's also SPNEGO, a pseudo-mechanism for negotiating mechanisms.

It'd be trivial to add a variant of SCRAM that uses a ZKPP instead of
a challenge/response digest-type protocol.  In fact, I intend to get
around to doing that if someone doesn't beat me to it.  If we do then
we'll have seven standards-track GSS-API mechanisms, plus three
non-standard mechanisms also listed above, and apparently there are
some proprietary mechanisms as well (of which I know nothing).

Also, there's quite a bit of activity around the GSS-API, both in the
IETF KITTEN WG (son of the old CAT WG), which now owns the GSS-API and
SASL, as well as in the ABFAB WG (which is working on an
EAP/AAA/SAML-based mechanism for the GSS-API).

Also, SASL can now use any GSS-API mechanism via a very simple
mechanism bridge known as "GS2" (see RFC5801).

Nico
--



More information about the cryptography mailing list