Subject: [TLS] GSS based PSK-TLS

From: Larry Zhu <[email-masked]>
Date: Fri, 13 Jul 2007 16:46:12 -0700

We would like to request for comments for the GSS based PSK-TLS ID:

http://www.ietf.org/internet-drafts/draft-santesson-tls-gssapi-02.txt

We have few comments that came after the draft submission that we felt 
it is important to bring up some of them to the list here. 

Jeff Altman will make -03 available before ITTF69 that would merge the
changes 
so far.

1) Why the GSS handshake does not come before the hello message?

Having the GSS handshake before the hello is not backward compatible 
with the TLS protocols.

2) Why the GSS handshake does not come after the key exchange message?

We do not want to pay for the cost of the DHE or RSA in this case. 
The main motivation for us is to enable Kerberos to secure TLS
connections. 
Kerberos is a lot faster, and we intend to keep it that way.

3) why it is not an issue to have arbitrary number of GSS round trips?

This has been raised previously. 

The arguments that EKR made starting on 3/8/2007 on the old thread may
not 
apply given that we are doing the Kerberos AP-REQ and AP-REP in the
hello 
messages using TLS extensions, and the Kerberos shared key is them 
imported to PSK-TLS. 

We (Jeff, Stefan and I) would like to have folks to review the 
new ID and see if your opinions have changed.

We believe the revised ID has minimal impact to the TLS state machine.

Also there are the handshake loop could be a stretch for mobile 
devices that have limited computing capabilities or in situations 
where the network latency is large such as satellite links. 

To address that concern, we introduce a policy that limit the # of 
GSS hand shake messages. 

In addition, the TLS client does not choose a GSS mechanism that can 
potentially have a large number of round-trips in the above
circumstances. 
The TLS client chooses which set of cipher suites to support as it does
today, 
and it can choose which GSS mechanism set is supported according to
RFC4178.
 
4) client authentication

The client and server authentication as defined in -02 need clarity. 
The following text describes the mechanism. 

   The client MUST NOT include a gss_api TLS extension if there is no
   PSK ciphersuite [RFC4279] included in the cipher_suites field of the
   client hello message.

   Initially the client computes the gss_api TLS extention data by
   calling GSS_Init_sec_context() [RFC2743] to establish a security
   context.  The TLS client MUST set the mutual_req_flag and identify
   the server by targ_name so that mutual authentication is performed in
   the course of context establishment.

   If the mutual authentication is not available on the established GSS-
   API context, the PSK key exchange described in Section 2 of [RFC4279]
   MUST NOT be selected, and the DHE_PSK or RSA_PSK key exchange MUST be
   negotiated instead in order to authenticate the server.
          
   If the GSS-API mechanism in the gss_api TLS extension provides client
   authentication [RFC2743], the CertificateRequest, the client
   Certificate and the CertificateVerify handshake messages MUST NOT be
   present.  This is illustrated in Appendix A.

          Client                                               Server

          ClientHello(with AP-REQ)  -------->
                                             ServerHello(with AP-REP)
                                   <--------          ServerHelloDone
          ClientKeyExchange
          [ChangeCipherSpec]
          Finished                  -------->
                                                   [ChangeCipherSpec]
                                   <--------                Finished
          Application Data         <-------->       Application Data

             Fig. 2. Kerberos FKA-TLS example message flow

5) what are the parameters to GSS PRF?

   The input parameters to GSS_Pseudo_random() to compute the shared
   scret value MUST be provided as follows:

   o  The context is the handle to the GSS-API context established in
      the given session.

   o  The prf_key is GSS_C_PRF_KEY_FULL.

   o  The prf_in contains the UTF8 encoding of the string "GSS-API TLS
      PSK".

   o  The desired_output_len is 64.  In other words, the output keying
      mastering size is 64 in bytes.

6) how are the GSS mechanisms negotiated?

This logic is encapsulated in GSS. SPNEGO as defined in RFC4178 can do
it. 

The concern is that such negotiation can be suboptimal when there are
two 
layers of negotiation, one in the TLS hello message, and the other in
the 
GSS layer. We believe such concern can be addressed by allowing
additional 
input to GSS negotiation to share the negotiation hint.  That can be 
accomplished, for example, by extending RFC4178.

As long as the cipher suite decision is made in one round-trip that the 
fact that the GSS OID options are carried in a GSS token instead of the 
TLS cipher list does not result in a two-layer negotiation.

-- Larry Zhu on behalf of Larry, Jeff and Stefan.

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Martin Rex <[email-masked]>
Date: Tue, 17 Jul 2007 23:41:52 +0200 (MEST)

> Kerberos is a lot faster, and we intend to keep it that way.

TLS session can be cached, resumed and forked.  Although performance
is an issue for a significant amount of our customers, the
RSA-server-authentication in the SSL handshake is NOT normally
an issue (it only becomes an issue if the SSL session cache is
configured too small).  So-called SSL Accellerators have a really
hard time to provide a benefit.  They might add latency and an
additional point of failures, and can hardly keep up with x86-based
multi-cpu multi-core machines (both in terms of price and performance).

GSS-API security context can not be cached and not be resumed.

A while ago I looked with HTTPWatch at the messages exchanged
between MSIE6 and IIS6 using HTTPS+Negotiate.  IIS6 forces
the client with 401 Unauthorized through a full new Kerberos
authentication with each and every request on an established
TLS channel.  I'm not impressed, and will not easily buy
"proposed solutions" for Microsoft-asserted performance issues.

And why is TLS authentication performance made a non-issue
for StartTLS vs FastArmor and a big issue here?

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Tue, 17 Jul 2007 15:40:10 -0700

> TLS session can be cached, resumed and forked.  Although performance
is an issue for a significant amount of our customers, the RSA-server-
> authentication in the SSL handshake is NOT normally an issue (it only
becomes an issue if the SSL session cache is configured too small).
So-called 
> SSL Accellerators have a really hard time to provide a benefit.  They
might add latency and an additional point of failures, and can hardly
keep up 
> with x86-based multi-cpu multi-core machines (both in terms of price
and performance).

This will continue to work. I would like to emphasize FKA-TLS is a
variant of PSK-TLS.

> GSS-API security context can not be cached and not be resumed.

you do not need to resume in the GSS level. You can resume in the
PSK-TLS level. Again, this is a variant of PSK-TLS, you have all the
bells and whistlers of PSK-TLS.

--larry

-----Original Message-----
From: Martin Rex [mailto:[email-masked]] 
Sent: Tuesday, July 17, 2007 2:42 PM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [TLS] GSS based PSK-TLS

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 18 Jul 2007 01:17:33 +0200 (MEST)

> This will continue to work. I would like to emphasize FKA-TLS is a

With the current proposal this will be pretty difficult and awkward.

> bells and whistlers of PSK-TLS.

As soon as you say GSS-API, a lot of unsaid things become an issue
which the current draft does not address at all, and which create
huge architectural problems (for the TLS implementation).

 - GSS-API naming

 - GSS-API extensions, like authorization
   (Microsoft will likely want impersonation to work)
   persitence of GSS-API objects and attributes and access to
   such attributes (currently existing as well as future defined ones)

With the proposed architecture FKA-TLS bolts GSS-API deep into
the TLS (protocol) stack, and in order to make anything besides
an "authentication succeded" boolean available to the calling
application, you will have to hack up the TLS API in a massive
way to make the underlying GSS-API accessible and session
caching interoperate smoothly with GSS-API related feature
requests and expectations of the calling application.

Compare this to an architecture, where you have an almost vanilla
TLS stack with support for a small "GSS-API mechanism list negotiation
extension plus server name signalling" and one or more vanilla
legacy GSS-API mechanisms bundled by an thin additional glue layer
that combines this into a TLS-with-adjacent-GSSAPI-handshake,
where you can plug'n'play gssapi mechanisms and TLS stacks.

In such an architecture, you may still have to solve the
GSS-API persistence in this additional top-level glue layer,
but you can support close to any existing and conceivable GSS-API 
mechanism and the necessary changes to SSL/TLS are
minimalistic and fully transparent/orthogonal to the
evolution of the TLS protocol&stack (like addition of
new ciphersuites).  Not having to deal with GSS-API
extensinos, objects, object persistence and naming
within TLS will be by far the biggest advantage. 

Generating a self-signed RSA server certificate is trivial and a non-issue.

Ignoring a self-signed RSA server certificate when the server
is authenticated by GSS-API as well is trivial and a non-issue.

Do NOT overestimate the security of the "endpoint identification"
that Web-Browsers currently perform (EKR: I really appreciate your
choice of terminology in rfc-2818).  As I said before, the approach
taken by SSH is much better, even without CA-signed host keys.

-Martin

---

From: Larry Zhu <[email-masked]>
Date: Tue, 17 Jul 2007 18:00:20 -0700

> With the current proposal this will be pretty difficult and awkward.

Please elaborate. The FKA-TLS is a supper set of PSK-TLS, can you
explain why a different way to establish the shared key would make it
worse.

> which the current draft does not address at all, and which create huge

> architectural problems (for the TLS implementation).

I would like to understand what are the things unsaid.

> - GSS-API naming

This ID does not define additional naming. Any naming scheme would work.
If there is the need to call out for a specific naming, please do tell.

>   such attributes (currently existing as well as future defined ones)

What are those? If you have non-standard extensions, you will need to
take care of it yourself. The draft will work with standard GSS-API
operations.
We envision it is sufficient with what is said in -03.

> With the proposed architecture FKA-TLS bolts GSS-API deep into the TLS

> (protocol) stack, and in order to make anything besides an 
> "authentication succeded" boolean available to the calling 
> application, you will have to hack up the TLS API in a massive way to 
> make the underlying GSS-API accessible and session caching 
> interoperate smoothly with GSS-API related feature requests and 
> expectations of the calling application.

What is the TLS API you are referring to here?

> Compare this to an architecture, where you have an almost vanilla TLS 
> stack with support for a small "GSS-API mechanism list negotiation 
> extension plus server name signalling" and one or more vanilla legacy 
> GSS-API mechanisms bundled by an thin additional glue layer that 
> combines this into a TLS-with-adjacent-GSSAPI-handshake,

Let me reiterate that the ID does not encourage plug'n'play of GSS
mechanisms.

> In such an architecture, you may still have to solve the GSS-API 
> persistence in this additional top-level glue layer, but you can 
> support close to any existing and conceivable GSS-API mechanism and 
> the necessary changes to SSL/TLS are minimalistic and fully 
> transparent/orthogonal to the evolution of the TLS protocol&stack 
> (like addition of new ciphersuites).  Not having to deal with GSS-API 
> extensinos, objects, object persistence and naming within TLS will be 
> by far the biggest advantage.

 Let me reiterate that this ID does not encourage plug'n'play of GSS
mechanisms.

> Generating a self-signed RSA server certificate is trivial and a
non-issue.

It is hard to trust that cert and authenticate the server. This approach
provides a high-scalable and robust solution without PKI.

> Ignoring a self-signed RSA server certificate when the server is 
> authenticated by GSS-API as well is trivial and a non-issue.

This is an understatement. This approach pushes the solution down the
stack.

> taken by SSH is much better, even without CA-signed host keys.

Please describe the problems and see if this ID can address them.

--larry