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

[Martin Rex <[e-mail]>]

Bill Buffam wrote:
> 
> 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.

Once you get used to it, you'll appreciate it simplicity.
I like it.

> (b) SSL wasn't designed to fit under GSS-API, and force fitting it seems
> to require much effort and some compromise.

I haven't read anything about SSL, so I'm mere guessing:
- SSL usually comes with a transport mechanism, GSS-API is without
- SSL is synchronus&blocking, GSS-API is whatever you want
- SSL is stream, GSS-API is message-oriented.
- GSS-API v2 defines security context transfer to other processes,
  I don't know if that is defined for SSL

> (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?)

- OSF DCE 1.1 offers GSS-API,
- Sesame-based products use GSS-API as their (only) native interface.

A year ago our development partners did plan to support SPKM in their
commercial product.  Currently they're using their own mechanism,
I don't know when or if they're going to complete their SPKM implementation.
(http://www.secude.com).

> (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?)

If they're careful, it should be possible with some glue layer atop
SSPI to talk to native GSS-API v1 Kerberos implementations.  I would
really appreciate if they added context transfer capabilities to SSPI,
so that GSS-API v2 becomes a possibility.

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

As far as I know, SSL is ALWAYS synchronous and blocking.  This is a
serious limitation, because it impacts scalability and reliability.

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

It is probably the most easy and fast way to go for many small and medium
size applications in spite of a some performance, scalability and
reliability issues.

A large application that pushes every available hardware to it's
limits might not be able to accept any one of these problems...

-Martin