jaltman at secure-endpoints.com
Fri May 8 01:28:34 UTC 2015
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 4589 bytes
Desc: S/MIME Cryptographic Signature
More information about the openssl-users