Subject: Re: GSS in (something like) TLS?

From: Mayank Upadhyay <[email-masked]>
Date: Thu, 3 Feb 2000 01:15:46 -0800 (PST)

>From: "Mike Spreitzer" <[email-masked]>
>Subject: GSS in (something like) TLS?
>
>It seems natural to me for someone who's using the GSS-API to want a 
stream filter protocol similar to TLS to transport the tokens
>that the GSS-API is defined to produce and consume.
...
...
>Does this sound to you like something that should be produced (and if 
so, where)?

This sounds like a good idea. I'm interested in this from the point
of view of a Java developer who would like a streams based API that
can hide the details of the GSS-API from me.

As a different issue, I would also like to have one API that can
provide me with support for both GSS mechanisms and TLS cipher
suites.

It appears that there are two different ways to achieve both goals
together:

(1) Support GSS mechanisms under TLS as new cipher suites and use the
streams based API's that TLS implementations generally provide. We
would need to define new message types to carry the different GSS
tokens at different stages of the the TLS protocol as Mike suggested, 
and also make some exceptions in the TLS protocol for the GSS cipher 
suites.

This would allow existing applications that use TLS to continue to
work seamlessly when switched to a GSS based cipher suite. Moreover,
the TLS handshake negotiation mechanism could be used to negotiate not
just among existing TLS cipher suites but also among any GSS mechanism
based suites. This does not preclude SPNego from being used as yet
another GSS based cipher suite.

Note that applications that could use a GSS based cipher suite for TLS 
will be unable to interoperate with peers that use pure GSS but might 
be able to negotiate successfully with peers that use only TLS 1.0 
cipher suites.

(2) Define a streams based abstraction that utilizes the
GSS-API to wrap/unwrap data as the application writes to or reads from 
the IO streams. To solve the other problem of TLS support, define a 
TLS like mechanism for the GSS-API, as suggested by Frank. This 
mechanism might have to reach into the guts of a TLS implementation 
and utilize just the underlying layers there.

Note that applications that use this TLS like mechanism under GSS will
be unable to interoperate with peers that use just TLS; however, with
the help of SPNego, they might interop with peers that use existing
GSS mechanisms.

Leaving the question of "GSS under TLS" or "TLS under GSS" aside,
there is another issue to note when considering stream filters for
GSS. The GSS-API is well tailored for message based applications that
might wish to protect different messages differently. For instance,
one might be merely integrity protected while another might be
encrypted, and yet another might use a different key strength (QOP)
for either one of these operations. These options are requested via
arguments to the gss_wrap() call. On the other hand, when we impose a
streams based abstraction on the GSS-API there will be one InputStream
(e.g., in Java) and one OutputStream that the application will use. 
The application will then be stuck with "integrity only always" or
"integrity and privacy always", and with the same QOP. These
limitations seem inherent to a stream based API but for the added
convenience of streams, many programmers might be willing to live with
this limitation.

To answer one other question that Mike asked, if we undertake to
provide a solution as outlined in (1) the work might be more 
appropriate for the TLS working group. However, if we were to 
undertake a solution as outlined in (2) then the part of it which 
includes the addition of stream based API for GSS definitely seems 
more appropriate for the CAT WG.

Regards,
Mayank

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email-masked]

---

From: "Mike Spreitzer" <[email-masked]>
Date: Thu, 10 Feb 2000 17:48:03 PST

> can hide the details of the GSS-API from me.

It seems to me that a lot of the details of the API would have to stick around; what I'm asking for is just a particular
higher-level protocol in which to put the tokens in which GSS traffics.  The stream abstraction will be a little easier to use than
the token exchange; is that what you mean?

> provide me with support for both GSS mechanisms and TLS cipher

Yes, and I think this may be good for interoperability and evolutionary reasons as well.  Actually, I think it would be good to have
*two* APIs that each gives me access to both sets of mechanisms --- and those two APIs should be the GSS-API and the one(s?) common
for TLS.

It seems to me that I may be thinking something unusual in terms of software structure for the peers.  It's not the only scenario
we're addressing, but it's a simple one I'd like to include.  I'd like to be able to write code that is a user of the GSS-API ---
not in bed with anything below that API --- and that implements the stream filter I'm asking for.  In particular, without modifying
GSS tokens or even understanding the token formats defined for use with specific GSS mechanisms.

In terms of protocols, I thus think it might be best to combine the two approaches you suggested, with a slight change to your first
(if I understood it correctly).  I like the idea of easing the evolution of the wire protocols as well as easing the evolution of
the APIs.  I also like to minimize round trips.  I'd be inclined to go about them as follows.  The basic idea is to generalize the
TLS protocol by adding record types to carry GSS tokens.  Define a new TLS record type to carry GSS setup tokens.  A client willing
to support both GSS and old TLS starts the negotiation by sending both (1) a TLS Client Hello message and (2) the token out of the
first call on the GSS-API's init-sec-context routine.  These would be two TLS records, with the GSS-oriented one first.  An old
server would simply discard the GSS-oriented record (that's what TLS says it should do with non-understood record types, right?),
thus automatically restricting the negotiation to existing TLS cipher-suites.  A new server would understand this pair of messages
as requesting an expanded negotiation, and respond however it likes.  An old client would send a TLS Client Hello not preceded by a
GSS-oriented message; an old server would be happy, and a new server would understand the client's limitations.

That approach dodges the following bullet on the wire (although not in the API's --- but I think that's less worrisome).  The GSS
identifies a mechanism by an OID; this technique supports decentalized evolution, which I think is good.  TLS identifies a
cipher-suite by a 16-bit number, managed by a central registry, which I think is less good.

As suggested above, I might support also defining GSS mechanisms that employ the existing TLS cipher-suites.  This would give two
ways --- on the wire --- to get to those mechanisms: directly at the generalized TLS level, or indirectly as a mechanism of the GSS
embedded in the generalized TLS.  That doesn't bother me too much.

Mike