RE: [TLS] encrypting GSS data: draft-santesson-tls-gssapi-03.txt

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

Martin Rex wrote:
> In contrast to this, the current ID:
>  - requires the use of specific ciphersuites

Hum? Which specific ciphersuites are required?

>  - defines new ciphersuites

Where is the definition?

>  - requires a new and optional feature from the gssapi mechanism
    that close to none of the installed base of mechanism has
    and that many mechanisms can not easily or not at all provide

where is the requirement?

>  - requires SPNEGO for negotiation of mechanism.

I do not see this requirement either

>  - requires massive changes to the entire TLS state machine

Please quantify. FKA-TLS just defines a new way to derive the PSK.

>  - inflates the size and processing time of the entire TLS handshake

Please quantify. On the contrary, we expect the size to be reduced
because we do not need to send the certificates bags if FKA-TLS is
negotiated, and the process time will be reduced because Kerberos is a
lot faster.

>  - leaves it completely in the mist how to extort gssapi handles
>    that TLS will need to perform a gssapi context establishment
>    durint the TLS hanshake available to the application caller
>    to make any GSS-API extensions (names,attributes,authorizations)
>    accessible to the application caller

Why do we care?

>  - you just came up with yet another pseudo-mechanism in order
>    to protect the gssapi token exchange

It is an option to address your concern. It is not required to
implement. I do not think it is needed. It is there illustrate how the
protection can be done.

--larry


-----Original Message-----
From: Martin Rex [mailto:Martin.Rex at sap.com] 
Sent: Friday, July 20, 2007 11:54 AM
To: Larry Zhu
Cc: tls at ietf.org
Subject: Re: [TLS] encrypting GSS data:
draft-santesson-tls-gssapi-03.txt


Larry Zhu wrote:
> 
> A new section is inserted in -03: the TCPWrap pseudo mechanism is
> defined to describe how to TLS protect GSS-data.
> 
>
http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.tx
t
> 
> 6.  Protecting GSS-API Authentication Data

To me it looks like this is going into the wrong direction.

There is a saying:
"Perfection [in design] is achieved not when there is nothing left
 to add, but rather when there is nothing left to take away."

Actually, there is a requirement for advancing protocol specs on
the standards track that follows this spirit.  Feature creep is
one of the reasons why more and more IETF standards lately
revision&cycle
on proposed status instead of advancing to draft.  I believe this will
hurt us in the long run.

My suggested architecture is intended to fly with an installed base
legacy gssapi implementation and with as little changes to TLS
as is humanely possible, then entire mechanism negotiation in
a fairly generic and small Hello extension plus a new container
content type to carry the GSSAPI handshake following the TLS handshake.
TLS will never ever touch, know or care about gssapi mechanisms,
gssapi functions, gssapi object handles, gssapi naming or gssapi
extensions.
I firmly believe we can obivate SPNEGO in this protocol entirely,
as well as any kind of mechglue stuff.


In contrast to this, the current ID:
  - requires the use of specific ciphersuites
  - defines new ciphersuites
  - requires a new and optional feature from the gssapi mechanism
    that close to none of the installed base of mechanism has
    and that many mechanisms can not easily or not at all provide
  - requires SPNEGO for negotiation of mechanism.
  - requires massive changes to the entire TLS state machine
  - inflates the size and processing time of the entire TLS handshake
  - leaves it completely in the mist how to extort gssapi handles
    that TLS will need to perform a gssapi context establishment
    durint the TLS hanshake available to the application caller
    to make any GSS-API extensions (names,attributes,authorizations)
    accessible to the application caller
  - you just came up with yet another pseudo-mechanism in order
    to protect the gssapi token exchange

-Martin


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