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

[Marc Horowitz <[e-mail]>]

Bill Buffam <[e-mail]> writes:

>> 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.

I think your analysis is reasonable.  I caught a bit of this thread on
[e-mail], and responded there, but seem to have missed the
members of the other two lists, so I'm going to repost the whole
thing.  Apologies if you see it twice.  I hate to say this, but if
people reply, keeping it on all the lists would be good, since not
everyone is subbed everywhere.

--cut--

Mike Eisler <[e-mail]> writes:

>> I've had similar thoughts. One could create a GSS-API mechanism
>> that mimiced SSL's CipherSuites as QOP values (using the same
>> numerical values). And one could also mimic SSL's CipherSuite
>> negotiation during the GSS_Init_sec_context/GSS_Accept_sec_context
>> handshake.
>>
>> The value in this would be in simplifying the deployment of
>> protocols that use GSS-API security into operating environments
>> that favor SSL (for example web browsers). While the result would
>> NOT be the SSL protocol, it would be security equivalent to what
>> SSL delivers. Presumably, if the operating environment has
>> modularized the SSL layer appropriately, the GSS-SSL mechanism
>> could share code with the SSL protocol's API:
>>
>> 
>> internal SSL-api		GSS-API
>> 	|			   |
>> ssl-protocol engine		gss-ssl-mech
>> 		\		/
>> 		 ssl-crypto-code

I've had similar thoughts to Mike's but I'd splice it in somewhat
differently.  SSL has two advantages.  From an application author's
point of view, you have a sockets-like api which implements a secure
channel.  From a security point of view, you have a deployed key
infrastructure (which is somewhat fragmented and incomplete, but
between netscape, verisign, and RSA, it's getting somewhere):

    internal ssl api
	    |
     x.509  +  sockets

I would add gssapi in there as a cryptosuite:

    internal ssl (tls) api
	    |
     (gssapi, x.509) + sockets
	|
    x.509-ssl, kerberos, spkm, whatever

This would let new and old ssl apps continue to work together.  A pair
of new ssl apps could use any gssapi mechanism instead of x.509
certificates.  Also, apps which didn't want to use ssl could still
take advantage of the key management infrastructure (mainly the
widely-known commercial CA's) growing up around SSL.

Adding gssapi here would be very similar to Ari's kerberos draft.

		Marc

--cut--

My response basically fits in as a variant of option 2c in Bill's
analysis:

>> (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.

My integration would seem to provide for a nice split between SSL/TLS
and GSSAPI.  SSL/TLS provides a simple API for application developers
to implement to.  Of course, for some applications, the simple
approach of protecting the transport layer will be inadequate, and
those developers can use the more complex but more powerful GSSAPI.
GSSAPI can be used as an SSPI, as Microsoft is doing, and as an API.
It would be very nice if MS would participate in this aspect of the
IETF, so that there are not two different but related standards for
this (MS and IETF).  Other consumers of the GSSAPI could include ONC
RPC, IPsec, and proprietary applications such as Oracle.

GSSAPI, then, is used as an interface for providing different key
*management* systems.  What is interesting about the differences
between SSL/X.509, Kerberos, PGP, etc. is not the difference in
cryptosystems (RC4 vs DES vs IDEA), but the difference in key
management approach (heirarchical public key infrastructure vs central
trusted third-party vs web of trust).  SSL key management can remain
parallel to GSSAPI for backward compatibility, but future development
should continue under GSSAPI, so that users of other API's can
benefit.

At the bottom of the abstraction is the application of cryptosuites to
various key management infrastructures.  There isn't a particular
standard I can think of right now for this, but it would seem to be
possible to define a standard to allow cryptographic algorithms (in
particular, cryptosystems, hashes, MAC's, and combinations) to be
portably and safely consumed by a wide range of security technologies.

This layering does not allow one to make GSSAPI calls and get a series
of tokens which are wire-compatible with SSL, but I don't think that's
important, either.  What GSSAPI does need is an extension to better
support stream-oriented I/O.

Richard Ward: are there any documents which describe the SSPI, and
does it make sense on non-windows os's?  (I know, you don't care :-)

		Marc