[cryptography] Anti-GSS falsehoods (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM))

Nico Williams nico at cryptonector.com
Mon Jun 27 13:58:26 EDT 2011

On Fri, Jun 24, 2011 at 11:00 AM, Marsh Ray <marsh at extendedsubset.com> wrote:
> On 06/24/2011 02:04 AM, Nico Williams wrote:
>> Every bank that uses Active Directory uses Kerberos, and the GSS-like
>> SSPI.  And the Kerberos GSS mechanism (through SSPI, on Windows).  The
>> native Windows TLS implementation is accessed via SSPI.
> I've used/abused the Windows SSPI a few times for various things. It's
> pretty darn abstract. Which is not a criticism, only that it's less of an
> API than a intra-host transport protocol for shipping loosely related
> structures between apps and the security providers which are as diverse as
> Kerb and TLS.

I'm not sure what you mean by "abstract".  What I mean when I say
"abstract API" is what you see in RFC2743: an API described in generic
terms and notation rather than in any on programming language.

>> http://msdn.microsoft.com/en-us/library/aa375506%28v=vs.85%29.aspx
> For example, the Microsoft doco on InitializeSecurityContext()
> has a description and then again separate pages for every security support
> provider (SSP) that ships with Windows.

That's kind of annoying, I agree.  Other OSes don't do that.  For
example, there is no separate manpage for each mechanism's
gss_init_sec_context() entry point in any Unix or Linux that I know

Part of the reason MSFT does this, I suspect, is that they've come to
use SSPI for so many things (TLS, SASL, GSS).

> Again, there's nothing wrong with this. But I suggest a guideline for our
> discussion of the design of crypto APIs: The API must not be so abstract
> that it doesn't actually encrypt any data.

Huh?  SSPI sure does have functions for encrypting data.  The init sec
context function isn't it -- that's for authentication and key


More information about the cryptography mailing list