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

Larry Zhu wrote:
> 
> even better, you do not need to do that for every real GSS-API
> mechanism, instead, you can define a stackable protection
> GSS-mechanism like SPNEGO, and use that to protect for the
> real GSS-API mechanisms.

Ouch.

With a simple mechanism (OID) negotiation logic within a
Hello extension, we could get rid of SPNEGO entirely for gssapi-tls.

This would have many advantages:
 - when the common mechanism OID selection is built into
   a TLS extension, then TLS can simply perform the regular
   SSL handshake when no common mechanism is available.

 - it completely avoids the entire SPNEGO codebase.
   a large part of the installed base of GSS-API mechanism doesn't
   have SPNEGO, and as I've said, we would have compelling use
   cases if the scheme would work with the existing installed
   base (of gssapi mechanisms) and without SPNEGO and minimalistic
   changes to SSL/TLS.

   Changes to the Web-Browsers and Web-Servers are necessary,
   of course, but with such a low-impact change as I have been
   describing throughout my last postings, the necessary small
   changes for Browsers like Firefox and TLS implementations would
   come within a few weeks.  And I would give this a much better
   chance to get implemented into our backends and SSL 

 - and additional multi-mechanism glue layer would be entirely
   unnecessary in this scenario.  A server or browser could
   simply load and use the negotiated GSS-API mechanism directly.

Btw. thinking about the security context establishment of GSS-API:
there is no size limit on the context-level tokens within GSS-API.
Although a single SSL Record of 16K would be sufficient for the
majority of environments (gss-api mechanisms) that I have seen,
extensive use of X.509v3 extensions (attributes,constraints,policies,
URLs,disclaimers,digital-junkyard-of-your-favorite-CA) as well
as PACs or similar bloat in Kerberos certificates might exceed 16K.
so a simple framing protocol for the gssapi context level
tokens might be needed.

-Martin

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