On Thu, 2015-05-07 at 21:28 -0400, Jeffrey Altman wrote: > On 5/7/2015 8:40 PM, Viktor Dukhovni wrote: > > On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote: > > > > > There have been some conversations behind Red Hat doors about > > > improving the state of Kerberos/TLS in both standards and > > > implementations. Could we maybe have a broader conversation > > > about how > > > to fix this situation? > > > > To be blunt, if you want better Kerberos support in TLS, the fix > > is to expand the TLS WG charter to explore new directions in TLS > > Kerberos support. Given all the current efforts on 1.3, this is > > not going to happen for quite some time. > > > > There's nothing that can be done in just OpenSSL, and the right > > immediate action is to drop support for the obsolete protocol. > > > > [ FWIW, Nico concurs. ] > > As do I and I am one of the individuals that pushed to get RFC 2712 > passed the TLS WG and added to OpenSSL back in 1999. > > While Viktor is correct that GSS authentication used over TLS with > appropriate channel bindings is a good option, it is not an option > for > everyone. It isn't easy to re-architect protocols that have been > deployed for more than 15 years in production. > > There have been several efforts over the years to better integrate > GSS > and Kerberos into TLS. The approach that I prefer is one in which > TLS > relies upon GSS authentication to produce a shared secret key that is > used to feed the TLS Pre-Shared Key (PSK) functionality. However > that > went nowhere. TLS is complicated enough and there were significant > concerns that creating a GSS hole in the protocol would risk broader > security and performance issues. > > SSH2 + GSS Key Exchange demonstrates how easy it should be to combine > GSS Kerberos with a security protocol and remove the dependency on > key > management. I have often wondered if the real resistance to adding > GSS > to TLS is the negative impact it would have on the bottom lines of > companies that sell server certificates. > > Regardless, the inability to improve the support in this area has > left > the those organizations that rely upon 2712 with the choice of use > insecure protocols or re-implement the applications. I do not > believe > that any sane OS or application vendor can with a straight face > continue > to ship 2712 support. As such it should be removed from OpenSSL > master. I agree that the current situation is not sustainable. I was only hoping to start a conversation about how to improve the situation. For instance, there is this: http://tls-kdh.arpa2.net/ I don't see any reason this couldn't be expanded to do GSSAPI. But maybe this mailing list isn't the right place for such a discussion. Perhaps the right question to ask is how much interest there would be in improving this situation in the TLS WG and whether or not OpenSSL would have interest in implementing such a project. Nathaniel
