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

From: Matt Hur <[email-masked]>
Date: Thu, 3 Feb 2000 11:57:37 -0800

Per your point #1:
RFC 2712 specififes the use of Kerberos tickets as the authentication
mechanism in TLS.
Below is a loose specification for a simple way to do the same with a krb5
GSS mech (which has been implemented).  I have not submitted this as an IETF
draft.

-- Matt Hur

===================================

RFC 2712 specifies that a Kerberos ticket is used in the ClientKeyExchange
message.  For our purposes, we are using GSS tokens (the result of calls to
init_sec_context/gss_wrap).

Constructing the Client Key Exchange Message:

In RFC2712, the example KerberosWrapper structure is as follows:
 struct
 {
     select (KeyExchangeAlgorithm)
     {
         case krb5:            KerberosWrapper;       /* new addition */
         case rsa:             EncryptedPreMasterSecret;
         case diffie_hellman:  ClientDiffieHellmanPublic;
     } Exchange_keys;

 } ClientKeyExchange;

 struct
 {
     opaque Ticket;
     opaque authenticator;            /* optional */
     opaque EncryptedPreMasterSecret; /* encrypted with the session key
                                         which is sealed in the ticket */
 } KerberosWrapper;                   /* new addition */

For our purposes, we changed this as follows:
 struct
 {
     select (KeyExchangeAlgorithm)
     {
         case krb5:            KerberosWrapper;
         case gss_krb5;        GssKrb5Wrapper;
         case rsa:             EncryptedPreMasterSecret;
         case diffie_hellman:  ClientDiffieHellmanPublic;
     } Exchange_keys;

 } ClientKeyExchange;

 struct
 {
     opaque InitialContextToken;      /* token from call to init_sec_context
*/
     opaque InitialContextToken;      /* token from call to gss_wrap which
contains */
     opaque EncryptedPreMasterSecret; /* the EncryptedPreMasterSecret which
is */
                                      /* encrypted with the session key
sealed */
                                      /* in the ticket */
 } GssKbr5Wrapper;
(InitialContextToken is defined in RFC1964)

In GSS, context establishment may take a few trips (looping over an
init/accept call).  For our purposes (1st effort), we are assuming that we
do not need to do this.  If we cannot make this fly on first pass, then we
have an error condition.

> -----Original Message-----
> From: Mayank Upadhyay [mailto:[email-masked]]
> Sent: Thursday, February 03, 2000 1:16 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: GSS in (something like) TLS?
> 
> 
> >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, 3 Feb 2000 16:52:20 PST

If I understand you correctly, you're suggesting a hybrid approach: use the GSS to wrap the premaster secret, and then proceed with
the rest of TLS as if you had done RSA-based key exchange.  Is that right?

(1) That doesn't apply the selected GSS mechanism to the data conversation, only the key exchange.

(2) Why did you make your GssKbr5Wrapper include two InitialContextTokens?  gss_wrap doesn't emit an InitialContextToken, it emits a
SealedMessage (right?).  Can you be a little more explicit about what's in a GssKrb5Wrapper?

(3) This is not exactly specific to Kerberos; what's critical is that the GSS mechanism's setup phase needs just one message ---
right?

Thanks,
Mike

-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]