GSS-API and SSL - their coexistence, and related issues

[Bill Buffam <[e-mail]>]

Judging by the traffic level, it seems to me that there's a lot of
apathy on the question of the merits and feasibility of putting GSS-API
over SSL. Which leads me to think that perhaps this is the wrong
question. I want to try to summarize what I think are the requirements,
and what the options and issues are.

(in what follows, I'm using "mechanism" in its jargon sense, to indicate
a GSS mechanism (for example, Kerberos))

Requirements
1) Mechanism-independent API for applications and middleware to use.

2) Transport-independent mechanisms

3) CryptoAlgorithm-independent mechanisms.


Possible Options

1) GSS-API as the mechanism-independent API. 
Issues:
(a) Application writers seem not to like GSS-API. It seems very
cumbersome to program.
(b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
to require much effort and some compromise.
(c) Popular support for GSS-API seems weak. It's now the native
interface to Kerberos, but the only other mechanism so far using it is
Entrust's SPKM (an X.509-based public key mechanism). No other
developer, to the best of my knowledge, has embraced SPKM. (Can anyone
from Entrust comment on the uptake of GSS-API in the Entrust user base?)
(d) Microsoft has publicly stated a commitment to SSPI (Windows-style
GSS-API) as its native interface to Kerberos and SSL, yet has been
silent since the beginning of this discussion questioning the
feasibility of GSS/SSL coexistence. (Hello Microsoft. Can you comment?)
    
2) Winsock (or similar) as the mechanism-independent API.
Issues:
(a) A Winsock-style interface may be ideal for applications that want a
minimum of aggravation in invoking security functions, but a management
API will be needed to configure behavior that the application writer
likely doesn't care about (or doesn't know enough to decide, or should
by policy be decided at a more global level) (e.g. ciphersuites)
(b) We just moved the responsibility for organizing the transport
independence. With GSS-API, the caller is responsible for managing the
transport. With Winsock (or similar) we're making the SSL layer
responsible for the transport. This seems to be an advantage. Firstly,
the application is freed from a lot a tedious state maintenance, and
sees a much simpler interface. Secondly, in systems that only care about
TCP/IP, that's the only transport we need to implement. Thirdly, in
systems that do need to deal with other transports, we make the
selection and handling of that transport the responsibility of the
system (not the application) and control its selection through the
(putative) management interface.
(c) We can apparently embrace Kerberos migration within the SSL
mechanism, as defined in 
ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-kerb-cipher-suites-00.txt
This implies that SSL (or TLS or whatever it becomes) becomes the
unifying framework within which all future session-oriented security
mechanisms will live. It appears to set the stage for GSS-API and
SSL/TLS to compete for the role of unifying orchestrator of
session-oriented security. The very existence of this draft seems to me
to be a tacit admission that current SSL techniques are more
developer-friendly than GSS-API. Perhaps the authors could comment.

3) No standard API. Each mechanism does its own thing.
Issues:
(a) Ugh!

Summary - Issues - Musings
Option 2 looks, in some respects, very attractive. Yet it seems to give
SSL/TLS the crown jewels as the central nucleus of session-oriented
security. Is that what we want?

As a security middleware developer, I want to apply my efforts to the
APIs that application developers want to see and will find most
effective to use. So to all the application developers out there I ask,
What are your preferences on these issues? Do you have Kerberos
migration and expansion (to public key) issues? Or are you jumping
straight into SSL and embedding it in your applications? Is each
application going to have its own embedded SSL? What API do you want to
see? Do you care about transports other than TCP/IP?

If you're subscribed to these lists, and you don't care about these
issues, I'd be really interested to know *why* you don't care.

And if you got this far, thanks.

-- 

Bill Buffam
Unisys, Malvern PA
[e-mail]