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

From: Larry Zhu <[email-masked]>
Date: Thu, 19 Jul 2007 20:48:43 -0700

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

   GSS-API [RFC2743] provides security services to callers in a generic
   fashion, supportable with a range of underlying mechanisms and
   technologies and hence allowing source-level portability of
   applications to different environments.  For example, Kerberos is a
   GSS-API mechanism defined in [RFC4121].  It is possible to design a
   GSS-API mechanism that can be used with FKA-TLS in order to, for
   example, provide client authentication, and is so weak that its GSS-
   API token MUST NOT be in clear text over the open network.  A good
   example is a GSS-API mechanism that implements basic authentication.
   Although such mechanisms are unlikely to be standardized and will be
   encouraged in no circumstance, they exist for practical reasons.

   In order to provide a standard way for protecting weak GSS-API data
   for use over FKA-TLS, TLSWrap is defined in this section as a pseudo
   GSS-API mechanism that wraps around the real GSS-API authentication
   context establishment tokens.  This pseudo GSS-API mechanism does not
   provide per-message security.

   The syntax of the initial TLSWrap token follows the
   initialContextToken syntax defined in Section 3.1 of [RFC2743].  The
   TLSWrap pseudo mechanism is identified by the Object Identifier
   iso.org.dod.internet.security.mechanism.tls-wrap (1.3.6.1.5.5.16).

   Subsequent TLSWrap tokens MUST NOT be encapsulated in this GSS-API
   generic token framing.

   TLSWrap encapsulates the TLS handshake and data protection in its
   context establishment tokens.

   The innerContextToken [RFC2743] for the initial TLSWrap context token
   contains the ClientHello message encoded according to [RFC4346].  No
   PSK ciphersuite can be included in the client hello message.  The
   targ_name is used by the client to identify the server and it follows
   the name forms defined in Section 4 of [PKU2U].

   Upon receipt of the initial TLSWrap context token, the GSS-API server
   processes the client hello message.  The output GSS-API context token
   for TLSWrap contains the ServerHello message and the ServerHelloDone
   potentially with the optional handshake messages in the order as
   defined in [RFC4346].

   The GSS-API client then processes the server reply and returns the
   ClientKeyExchange message and the Finished message potentially with
   the optional handshake messages in the order as defined in [RFC4346].
   The client places the real GSS-API authentication mechanism token as
   an application data record right after the TLS Finished message in
   the same GSS-API context token for TLSWrap.  Because the real
   mechanism token is placed after the ChangeCipherSpec message, the
   GSS-API data for the real mechanism is encrypted.  If the GSS-API
   server is not authenticated at this point of the TLS handshake for
   TLSWrap, the TLSWrap context establishment MUST fail and the real
   authentication mechanism token MUST not be returned.

   The GSS-API server in turn processes the client reply and returns the
   TLS Finished message, the server places the reply token from the real
   authentication mechanism, if present, as an application data record.

   If additional TLS messages are needed before the application data,
   these additional TLS messages are encapsulated in the context token
   of TLSWrap in the same manner how the client hello and server hello
   message are encapsulated as described above.

   If additional tokens are required by the real authentication
   mechanism in order to establish the context, these tokens are placed
   as an application data record, encoded according to [RFC4346] and
   then returned as TLSWrap GSS-API context tokens, with one TLSWrap
   context token per each real mechanism context token.  The real
   mechanism context tokens are decrypted by TLSWrap and then supply to
   the real mechanism to complete the context establishment.

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

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 20:54:11 +0200 (MEST)

Larry Zhu wrote:
> http://www.secure-endpoints.com/tls-gss/draft-santesson-tls-gssapi-03.txt
> 

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

---

From: Larry Zhu <[email-masked]>
Date: Fri, 20 Jul 2007 12:08:40 -0700

>  - requires the use of specific ciphersuites

Hum? Which specific ciphersuites are required?

>  - defines new ciphersuites

Where is the definition?

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.

>    accessible to the application caller

Why do we care?

>    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:[email-masked]] 
Sent: Friday, July 20, 2007 11:54 AM
To: Larry Zhu
Cc: [email-masked]
Subject: Re: [TLS] encrypting GSS data:
draft-santesson-tls-gssapi-03.txt

There is a saying:

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.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Jul 2007 22:15:04 +0200 (MEST)

> >  - defines new ciphersuites

Unless I missed the TLS working groups rough consensus to add
PSK ciphersuites as a mandatory to implement ciphersuite into TLS 1.2
it counts as a new (and specific) ciphersuite for all versions of TLS.
It definitely counts as new for older versions of TLS.

(Was it Nico who used a distinct ciphersuite ID TLS_GSS when talking
 about the current draft?)

Repeating myself, orthogonality to TLS is one of things I'm favouring,
which means that my conceived architecture should fly just fine as
an extension to TLSv1.1, TLSv1.0 and even SSLv3.

> I do not see this requirement either

I'm sorry if I have been jumping to a wrong conclusion too fast.
Nico started the thread "[TLS] Negotiation in draft-santesson-tls-gssapi"
asking for how you intend to select for a common gssapi mechanism
asserting that you would need either SPNEGO or an alternative means.

I may have wrongly interpreted your silence to this question
(incomparison to the two appendix you have posted upon other questions)
as an indication that you didn't want to supply an alternative to SPNEGO.

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

new messages (=states) within the existing TLS handshake?

> negotiated, and the process time will be reduced because Kerberos is a

I don't know what size your typical certs and cert paths are,
but ALL security context establishment tokens (combined) of the
~20 gssapi mechanism I've seen (except NTLM) beat the typical
server certificate messsage size by at least a factor of 3.

> >    accessible to the application caller

Maybe because of the KISS principle?

> implement. I do not think it is needed. It is there illustrate how the

I wouldn't mind if on some questions you would answer:
oh, for this we could just use the following existing protocol
feature, which everyone supports already because it has been
mandatory to implement, and we don't even need to change anything.  ;-)

-Martin