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

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

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