[TLS] GSS based PSK-TLS

[Larry Zhu <lzhu at windows.microsoft.com>]

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
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls