RE: [TLS] Review of draft-santesson-tls-gssapi-00

<Pasi.Eronen@nokia.com> Fri, 09 March 2007 10:49 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcfN-0001mB-3I; Fri, 09 Mar 2007 05:49:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HPcfL-0001ky-1L for tls@ietf.org; Fri, 09 Mar 2007 05:49:39 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HPcfJ-0002jE-JH for tls@ietf.org; Fri, 09 Mar 2007 05:49:39 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l29AnOrZ000886 for <tls@ietf.org>; Fri, 9 Mar 2007 12:49:35 +0200
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 12:49:08 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 9 Mar 2007 12:49:08 +0200
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Review of draft-santesson-tls-gssapi-00
Date: Fri, 09 Mar 2007 12:49:11 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F2403DE97E4@esebe105.NOE.Nokia.com>
In-Reply-To: <86mz2nr65m.fsf@raman.networkresonance.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Review of draft-santesson-tls-gssapi-00
Thread-Index: AcdhqFCB2U/5EcZdTnq3MGCYPQF54wAjJcmg
References: <20070122202751.CCBC45C01E@laser.networkresonance.com><A15AC0FBACD3464E95961F7C0BCD1FF01EEDF5A8@EA-EXMSG-C307.europe.corp.microsoft.com> <86mz2nr65m.fsf@raman.networkresonance.com>
From: Pasi.Eronen@nokia.com
To: tls@ietf.org
X-OriginalArrivalTime: 09 Mar 2007 10:49:08.0332 (UTC) FILETIME=[906112C0:01C76238]
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Eric Rescorla wrote:

> >> 2) The extended roundtrips is an un-escapable consequence.  If
> >> necessary I believe we can define an upper boundary of the number
> >> of roundtrips.
> 
> Well, any number >2 is a radical change in the TLS state machine.

I agree; however, there are several ways to do the roundtrips,
and some of them might be slightly less radical than the one
current proposed in draft-santesson-tls-gssapi-01.

Here's one sketch of how this could work:

   ClientHello
   (ciphersuite TLS_RSA_GSSAPI_WITH_AES128_CBC_SHA, 
   gss_api extension with OID list)
                                -------->
                                                   ServerHello
                             (gss_api extension with OID list)
                                                   Certificate
                                <--------      ServerHelloDone
   ClientKeyExchange 
   (just like in normal RSA ciphersuites)
   ChangeCipherSpec
   Finished                     -------->
                                              ChangeCipherSpec
                                <--------             Finished

Then we'd have the GSSAPI exchange:

   ContentType=GSSAPI 
   ("token", gss token data)    -------->
 
                                            ContentType=GSSAPI
                                <--- ("token", gss token data)
 
            (........ repeat 0..N times ..........)

   ContentType=GSSAPI
   ("complete", 
   gss_wrap(channel binding info)) ----->
                                            ContentType=GSSAPI
                                                  ("complete", 
                               gss_wrap(channel binding info))

   Application Data             <------->     Application Data

Here "channel binding info" would be something similar as in
draft-williams-on-channel-binding-01. Using a different content type
and channel binding would avoid the need to feed stuff from GSS-API 
to TLS record layer/handshake layer/key calculations (which AFAIK 
was one thing Eric objected to in IETF67).

(In addition to TLS_RSA_GSSAPI_WITH_*, we could also have
TLS_DHE_GSSAPI_WITH_* ciphersuites, if we need to support
servers without a certificate.)

Comments? 

Best regards,
Pasi

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls