Nicolas Williams wrote:
> 
> If this protocol will not provide a way for the server to tell the
> client what GSS-API mechanisms it supports or any other GSS-API
> mechanism negotiation facility then I think the server MUST support
> SPNEGO, else the client and server have to agree a priori on what mechs
> to use.

This observation is correct.

But I would very much dislike calls into SPNEGO by TLS (because
you really DO NOT want to layer it below TLS, where none of the
fancy GSS-API extensions is accessible that everyone is inventing),
unless you pave wide information highways through your TLS stack
or alternative break the abstraction, extort GSSAPI object handles
and function pointers held and managed by TLS to frob the GSSAPI
and SPNEGO implementations directly from above TLS (bypassing TLS).


This is why I want the negotiation of a common mechanism (OID)
be part of the Hello extension.  Its more of a selection according
to the preferences of the server.  It needs to be provided as
a simple OID list to the TLS stack on both sides, and that could
even be done in a generic fashion (not limited to a particular
TLS extension).

I just sent Larry a kind-of brain dump:

The whole idea and concept that I envison is still under construction
in my mind, but I do have a quite good feeling about it.

There are a lot of things/issues to address, not only wire formats
for new/additional messages, but also new semantics and
new requirements for the SSL/TLS module APIs to control
the new semantics.  Inserting a new code layer "TLSplus" that looks
like a TLS implementation (with additional features) to the application
and does all the new magic is inevitable, I believe.

For such an additional TLSplus code layer, we ought to
define several (abstract) characteritics and semantics
and provide rough guidelines how implementors might add
value, bells and whistles, depending on what (primarily
the server application) wants or needs.


Off the top of my mind here is a crude list of characteristics
that I consider important, and I believe that some of these can
not be met with the current proposal:

 - will work with pretty much every existing and conceivable
   GSS-API mechanism (even v1), requiring no changes to the mechanism

 - minimal and generic extension(s) to TLS (not tied to any GSS-API
   mechanism, and maybe not limited to the gssapi-over-tls extension)

    - Hello extension with ability to enable the server to select
      a common (gssapi) mechanism (OID), ignoring of the extension
      and regular SSL-Handshake if no common mechanism is found

    - include support for server name extension (virtual hosting)
      which also means server-side mechanism preference lists that can
      be limited to a particular virtual host and provide
      a hint for the server for selection of a suitable
      gssapi acceptor credential (above TLS)

    - a new ContentType at the TLS record layer to reliably
      distinguish (and prevent confusion) of GSS-API token
      exchanges (following a successfully completed SSL handshake)
      from application data.  A minimal framing protocol for
      the GSS-API token exchange to convey token length in order
      to support GSS-API context level tokens >16KByte,
      and maybe token type (in order to allow of a textual
      error message to the client over the established protected
      TLS channel when the acceptor side encounters and error
      when trying to establish the security context (this is
      not part of GSS-API but of the gssapi-over-tls extension).

    - semantics/constraints of the server certificate path validation
      for the client if the the gssapi-over-tls authentication extension
      is requested and a common gssapi mechanism is found and asserted
      by the server in the server hello message. 

    - probably a possibility to ask the TLS (server) implementation
      to store a (size-limited) flat-memory-object of TLSplus
      state along with a cached TLS session that is available on SSL/TLS
      session resumption and flushed when TLS flushes the session cache entry.
      Depending on the application's desires and requirements, the
      TLSplus layer may want to (or need to) persist some GSS-API
      specific information so that this information can also be
      provided to the calling application on SSL/TLS session resumption.
      For the underlying TLS implementation, this ought to be transformed
      into an opaque flat-memory-object that can be free() whenever
      the associated SSL session cache element is flushed from the cache.

 - will allow the application to access arbitrary GSS-API attributes
   and extensions with no changes to the TLS implementation and
   no violation of layering principles (like using meta-knowlege to
   frob software-layer below TLS directly) and not having to expose
   internal object handles created and managed by TLS.

 - no changes necessary to the gssapi-over-tls spec and neither the
   TLS implementation if additional or new features of a gssapi
   mechanism become available and used by the application caller
   (only changes to TLSplus, and for new GSS-API features to
    the gssapi implementation itself).

 - no changes necessary to the gssapi-over-tls spec the GSS-API
   mechanism, TLSplus or the application when new features are
   added to the underlying TLS implementation

 - orthogonality to TLS, i.e. benefit as much as possible from
   improvements to TLS, like new or stronger ciphersuites,
   new PRF or new TLS version, without changes to TLSplus, GSS-API, app
   and gssapi-over-tls spec -- which pretty much precludes to
   hardware/require any particular ciphersuites in gssapi-over-tls itself.

 - protection of the client identity from network-level sniffing
   (something which not currently available for the SSL client
    certificate).


Since I've been implementing a SAP-internal small "abstraction layer"
on top of SSL and providing support for this and the accompanying
OEM SSL library that we ship over the last 6 years, and for
gssapi based single sign-on over the last 10 years, my thoughts
are very close to real code that could&would implement all the
necessary stuff.

I firmly believe that any solution should allow both, the
TLS protocol&extensions and the GSS-API protocol&extensions to
evolve independently and provide new features with close to no
mutual interference between GSS-API, TLS and the gssapi-over-tls spec.


-Martin


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