Re: [openssl-dev] [openssl-users] Kerberos
On 5/13/2015 10:19 AM, Matt Caswell wrote: On 08/05/15 09:40, Matt Caswell wrote: On 08/05/15 02:28, Jeffrey Altman wrote: 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 plan to start preparing the patches to remove it next week. FYI, these patches have now been applied to master. Matt Thank you. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
On 08/05/15 09:40, Matt Caswell wrote: On 08/05/15 02:28, Jeffrey Altman wrote: 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 plan to start preparing the patches to remove it next week. FYI, these patches have now been applied to master. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
On 08/05/15 02:28, Jeffrey Altman wrote: 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 plan to start preparing the patches to remove it next week. Matt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
On 5/8/2015 5:17 PM, Nathaniel McCallum wrote: 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. I think that TLS-KDH is fundamentally flawed because it is tied to the Kerberos protocol. Most operating systems today support Kerberos but they do not support a stable standard Kerberos API because such a creature does not exist in the wild. If we want a TLS implementation to make use of Kerberos authentication on a broad range of operating systems that we must access Kerberos through GSS. Only by using GSS can userland TLS implementations hope to stack on top of the OS provided Kerberos in a portable way. 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. The IETF TLS WG and perhaps the IETF Kitten WG are the appropriate places to hold discussions. Or perhaps hold an IETF BOF first to explore the interest. The last time I was involved the work product was https://tools.ietf.org/html/draft-santesson-tls-gssapi-03 I still believe that is a reasonable approach. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
On Fri, May 08, 2015 at 05:17:29PM -0400, Nathaniel McCallum wrote: I agree that the current situation is not sustainable. I was only hoping to start a conversation about how to improve the situation. RFC2712 uses Authenticator, which is an ASN.1 type quite clearly NOT intended for use outside RFC1510 because it isn't a PDU. RFC2712 unnecessarily constructed its own AP-REQ that's different from the RFC1510 (now 4120) AP-REQ. This is bad for a variety of reasons, not the least of which are complicating Kerberos APIs and/or RFC2712 implementations (which might have to parse out the Authenticator and Ticket from a plain AP-REQ). I also notice that the EncryptedPreMasterSecret is under-specified (is it a Kerberos EncryptedData? who knows?). RFC2712 could be replaced with a properly-done protocol that uses Kerberos in the full TLS handshake (i.e., not in session resumption). This would be the lowest-effort fix. A generic GSS-in-TLS extension would require much more energy (see below). For instance, there is this: http://tls-kdh.arpa2.net/ Yes, it'd be nice to add PFS to the Kerberos AP exchange, and we just might get there, but adding Kerberos and/or GSS to TLS is a very different undertaking. I don't see any reason this couldn't be expanded to do GSSAPI. Well, that's difficult because GSS has arbitrary round trips... You're not the first to want this, see for example here: https://tools.ietf.org/html/draft-santesson-tls-gssapi-01 https://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04 And more if you consider other efforts like False Start and look past GSS/SASL. Probably many more than I know of then... Two main design axis: 1) When does the GSS context token begin, and how is channel binding done. - no GSS mech negotiation, first GSS context token goes in TLS ClientHello; (channel binding done via MIC tokens or GSS_Pesudorandom() output exchanges) or (e.g., if the client needs to negotiate mechs) - TLS ClientHello carries client mechList, server announces a mech in its handshake message, first GSS context token goes in second client handshake flight with normal channel binding (Both options could be specified, with clients choosing as desired.) x 2) How many GSS context tokens can be exchanged and who is responsible for continuing past the traditional TLS handshake. - one round trip only or - arbitrary round trips continued by TLS or by the application The first order of business is to decide on whether or not to support multiple round trips (IMO we must; what's the point if not?). The second is to decide whether or not additional context token round trips are to be done by the application, both as to how they appear on the wire and how they appear in the API. The third is to decide whether GSS mechanism negotiation is supported, and whether it can be optimized away when it's not needed. The fourth is to decide whether SASL (with SASL/GS2 to get GSS) isn't better, since if we're going to spend a pair of flights in negotiation, we might as well let server-talks-first SASL mechs get a leg up on GSS. Remember, SASL can do GSS just fine via SASL/GS2 [RFC5801]. But maybe this mailing list isn't the right place for such a discussion. Well, TLS WG would be the right forum, but they are busy with TLS 1.3. Some of us could get together elsewhere, probably not here. 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. My impression is: none, because TLS WG is too busy at this time, and in the past it has been very difficult to get the necessary level of implementor effort. Past performance is not always a predictor of future performance. It would help if GSS had better, less niche mechanisms. For example: if Kerberos had PKCROSS (based on DANE, say), that would help. Or if ABFAB went viral. But for now everyone in the TLS world is happy _enough_ with WebPKI for server (should be service, but hey) authentication and bearer tokens for user authentication. Part of the problem is that HTTP authentication schemes (whether in HTTP proper or not) have no real binding to TLS, and HTTP is basically a routable (and usually routed) protocol anyways, which complicates everything. But HTTPS is the main consumer of TLS. One might think that adding user authentication options to TLS would be desirable for HTTP applications, but again, the routing inherent to HTTP means that routing must pass along user authentication information, but this isn't always easy. And HTTP is stateless and so doesn't deal well with needing continuation of authentication exchanges, so bearer tokens it basically kinda has to be, so that better mechanisms lose their appeal. If the main consumer of GSS-in-TLS were to be something other than HTTP, well, great, but still, HTTPS is the biggest consumer (next is SMTP)... And it's easier then to
Re: [openssl-dev] [openssl-users] Kerberos
I should have mentioned NPN and ALPN too.
A TLS application could use ALPN to negotiate the use of a variant of
the real application protocol, with the variant starting with a
channel-bound GSS context token exchange.
The ALPN approach can optimize the GSS mechanism negotiation, at the
price of a cartesian explosion of {app protocols} x {GSS mechs}. A
variant based on the same idea could avoid the cartesian explosion. But
hey, TLS is the land of cartesian explosions; when in Rome...
The ALPN approach would be my preference here. With TLS libraries
implementing the GSS context exchange, naturally. The result would be
roughly what you seem to have in mind.
If we ask TLS WG, I strongly suspect that we'll be asked to look at ALPN
first.
I should add that I also would like to see the RFC4121 Kerberos GSS
mechanism gain PFS, independently of TLS gaining GSS.
Nico
--
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
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. ] -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-users] Kerberos
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. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
