[cryptography] Anti-GSS falsehoods (was Re: IETF Working Group Charter on Common Interface to Cryptographic Modules (CICM))
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.
> 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