[TLS] Re: the use cases for GSS-based TLS and the plea for integrating

[Martin Rex <Martin.Rex at sap.com>]

There is currently one proposal from Microsoft available as an ID and
I'm planning to come up with an ID in the September/October timeframe
based on the comments that I've made.

The two approaches are in some aspect fundamentally different.
One thing that I particularly dislike about the current ID is its
total silence/ignorance about the necessary changes to add this
to existing implementations and software architectures.


Personally, this impact on the installed base, existing implementations
and existing modularization and software architecture is a significant
concern when comparing the merits of different approaches. YMMV.


 a) draft-ietf-santesson-tls-gssapi:

    - uses GSS-API as a key distribution scheme in order to
      seed a TLS-PSK cihpersuite.  So the (PS)Key is not really
      pre-shared, it is created for and distributed with the
      very same TLS handshake

    # of round-trips: 
       without optimistic gssapi context token
              tls-handshake + gssapi-handshake
       with optimistic gssapi context token (e.g. SPNEGO+optimistic token):
              correct guess: tls-handshake + gssapi-handshake - 1
              wrong   guess: tls-handshake + gssapi-handshake

    advantages:
     * if the gssapi mechanism uses PK-ops-free context establishment
       the the TLS handshake can be performed entirely without PK-ops

    disadvantages:
     * works only with gssapi mechanisms that establish a shared
       session key during security context establishment
       (which essentially means: offer confidentiality message protection)
     * is currently limited to new gssapi mechanisms implementing
       the optional GSS_prf API extension
     * the entire GSS-API security context establishment MUST
       be performed completely inside the TLS handshake
     * requires major re-enginering of the TLS state machine and
       new handshake messages
     * will add at least one round-trip to the TLS-handshake if
       negotiation of gssapi mechanisms should be done and
       _NO_ optimistic gssapi context token scheme is used
     * will mess severly with the protocol stack software architecture
       because the calling application will likely want to
       get access to gssapi extensions/features/attributes
       from the gssapi context and object handles that
       are being using deeply within and owned/managed by TLS during
       the TLS handshake

     * does not provide identity protection for the client
     * does not improve security (weaknesses) over a regular
       gssapi authentication without TLS


 b) my (developing) concept/idea which I have been buiding up during
    my numerous postings last week on the TLS mailing list.

  - uses GSS-API as an additional or alternative authentication method
    for one or both peers on top of a regular TLS ciphersuite and
    after an almost vanilla TLS handshake (using a TLS Hello extension
    for determining availabilty of the protocol extension and selection
    of a common gssapi mechanism), plus three additions to TLS:

     - (preferably) an additional content type at the SSL/TLS record layer
       and API calls/extensions to exchange gssapi context establishment
       tokens following the TLS handshake between the peers

     - the possibility to update (using XOR) the pre-master secret and
       re-generate a new session key of a newly established SSL session
       synchronously (maybe this should use yet another content type
       similar to change_cipher_spec).

     - the possibility to attach an opaque (size-limited) flat-memory
       object to an SSL session (+session cache entry) where
       a seperate software module "TLSplus" above TLS can store those
       gssapi attributes which the application caller might
       want or need on SSL/TLS session resume
       I think it would be good to combine the attaching of
       additional attributes and the update of the pre-master secret
       and keying material

   # of round-trips:
       regular (and this includes mech negotiation):
             tls-handshake + gssapi-handshake
       with TLS-finished piggyback optim.:
             tls-handshake + gssapi-handshake - 1

   the additional TLSplus module will have to implement most of what
   represents gssapi-over-tls, i.e. set up the (simple OID) list of gssapi
   mechanisms for the TLS Hello extension, determine after the
   TLS handshake whether gssapi-over-tls and which mechanism OID
   was negotiated in the Hello extension, perform the GSS-API
   handshake when the TLS handshake is finished (optionally
   using the (clients) TLS finished message(s) as channel bindings,
   update the TLS session crypto keys if the gssapi mechanism can
   provide entropy for a cryptographic binding, collect gssapi
   attributes which the app cares about, serialize them into
   a flat memory object and ask TLS to attach them to the SSL session.

   disadvantages:
     * will incur the (CPU) overhead of a regular TLS handshake in
       addition to the gssapi authentication exchange, which normally
       means a TLS ciphersuite with PK-ops
     * will require one additional round-trip if NO optimization is
       implemented for the client to piggyback the messagee with
       the initiators first gssapi context token onto the
       clients TLS finished message

   advantages:
     * should work with most existing and future TLS cipher suites
     * will work with the entire installed based of gssapi mechs,
       no changes necessary (aside from potential ABI issues).
     * obviates SPNEGO and multi-mech-glues
     * should work with authentication-only gssapi mechanism just fine
       (it doesn't improve the security of the gssapi authentication
        exchange itself, though)
     * should work with SASL instead of GSS-API authentication
       handshakes (at least non-interactive ones)
     * requires only mild modifications of existing TLS implementations
     * should be doable even as a low-impact SSLv3 extension,
       not only TLS v1.x
     * client identity protection because the entire gssapi handshake
       is performed under TLS protection
     * a combination of server-authentication based on SSL server cert
       and client authentication based on gssapi client authentication
       is quite possible, 
     * high orthogonality to the TLS protocol, permitting completely
       independent evolution of gss-api and the TLS protocol stack
     * clear seperation of protocol stacks and abstractions,
       TLS doesn't have to mess with GSS-API, GSS-API doesn't have
       to mess with TLS, TLSplus can be custom tailored to provide
       the amount of gssapi attribute persistence that the application
       needs.

   
   in order to improve interoperability and to ease the use in heterogeneous
   environments, the TLSplus layer should have a self-signed certificate
   generated in case the customer does not (want to) setup a PKI so
   that non-anonymous TLS ciphersuites can be used.


-Martin

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