Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 13/05/2015 21:37, Jeffrey Altman wrote: On 5/13/2015 3:17 PM, Nico Williams wrote: Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? Nico, Look for draft-burdis-cat-srp-sasl. It was never standardized but I believe there is an implementation in Cyrus/SASL. This is the most recent version I could find http://www.opensource.apple.com/source/passwordserver_sasl/passwordserver_sasl-159/cyrus_sasl/doc/draft-burdis-cat-srp-sasl-xx.txt Jeffrey Altman No, I was referring to the (apparently never defined, though I thought it was) use of RFC2945 (SRP 3) as a GSS mechanism, with the additional bug fixes in SRP-6 (RFC5054) and SRP-6a (no RFC). Here I am referring to the SRP mechanism enhancements in RFC5054, not the TLS binding also in RFC5054. Because SRP-3 and SRP-6 is (from the outside) a kind of authenticated DH exchange, neither end will be ready to calculate MIC values until the primary exchange messages have been completed (this does not include any additional key confirmation messages that might be folded into the channel binding legs). This differs from Kerberos, where each end knows the MIC key before sending its first GSS token. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 13/05/2015 21:17, Nico Williams wrote: We're closer. On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote: On 13/05/2015 17:46, Nico Williams wrote: On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. The problem is that negotiating twice is bad (for various reasons), and SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is a two-level negotiation that is fraught with peril, therefore forbidden. Ok, having not studied the standard SASL in GSS specification, I presumed each GSS-encapsulated SASL mechanism would have its own GSS mechanism OID in some systematic way, leaving just one negotiation. SASL/GS2 is the other way around: GSS in SASL. The idea is that you can have GSS as SASL mechanisms in a way that sucks less than the original GSS-in-SASL bridge in RFC (that added an extra round-trip), and which makes it easy to add mechanisms like SCRAM as both, a GSS and a SASL mechanism. I'm perfectly happy to drop SASL though. Ah, I thought from context it was a way to use SASL as GSS mechanisms, with GSS presumably beingthe more powerful API for multi-leg protocols. Since I generally expect some mechanisms to only have standards for a form that can be bound to a channel or MIC, it would be best to keep the ability to reuse both standards via some existing bridging mechanism. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. It's quite complex owing to having been underspecified in the first place then having grown a number of bug workarounds over the years. Yes, but it is now a mature protocol, and I was trying to avoid creating yet another near identical handshake protocol. The only complication in a negotiation mechanism is protecting the negotiation. Since the TLS handshakes are ultimately integrity- protected, there's no complication at all to having the client send a list of mechanisms and the server pick one (the client can even send an optimistic choice's initial context token). In fact, it's much nicer than SPNEGO in many ways; if at all possible one should avoid SPNEGO. Among other things, not using SPNEGO means that it will be much easier to implement this protocol without extensions to GSS (extensions would be needed only to optimize it). Again, please say which GSS extensions would be needed to use SPNEGO rather thanyet-another- negotiation-protocol. In your protocol the client already sent a SPNEGO initial security context token. A response is required, as GSS context establishment token exchanges are strictly synchronous. As written, I had forgotten about the Finished messages. Thus the point wasto simply delay the server GSS response (2. GSS leg) to just after switching onthe encryption, later in the same round of messages. The 3. leg (second client to server GSS token) would then follow etc. We could extend GSS (see below) to support late channel binding, but since a mechanism might not be able to do it, this protocol would have to fall back on MIC tokens to complete the channel binding, in some cases at a cost of one more round trip. There is also the fallback to early channel binding (by not sending the first legs before the channel binding data is available). The resulting round trip counts would need to be studied closely to pick one. With PROT_READY there should be no need for an extra round-trip. Depends a lot on the mechanism. Some GSS mechanisms (other than Kerberos IV/V) cannot use their MIC until they have received a later token from the other end, but can incorporate binding data earlier than that. I think GSS-SRP-6a has that property. Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? See other subthread. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. However the early channel binding might save a leg. You
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. I am of cause aware that some existing mechanisms have both SASL native and GSS native bindings and that those bindings are mutually exclusive, such that one must decide at standardization time if the SASL native or GSS native form shall be used for interoperability. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. However I strongly suspect that using ALPN will cause practical conflicts with early HTTP/2 implementations and early ALPN implementations, as such early implementations are likely to only cater to that single use of ALPN. In contrast there are now multiple unrelated deployed TLS extensions, so that mechanism is more stable and more ready to handle new uses. We don't have to use the ALPN approach, and we don't have to support SASL. But see below. 2. The TLS client always begins by sending the first GSS/SPNego leg in a (new) TLS extension GSS-2. This is incompatible with doing channel binding the GSS way. Instead we'd have to exchange MICs of the channel binding when the GSS context is fully established. (This is fine, of course, and not a criticism, just pointing this out.) This is why I specified the alternate ordering below. Note however that not all versions of all GSS implementations (notable the Microsoft SSPI variant) may support the GSS channel binding mechanism. 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension GSS-2 to confirm support. Well, presumably the first response GSS token should go here. No, see below. 4. The second and subsequent legs of the GSS handshake are sent as the sole contents of the first encrypted records, actual application data is not sent until the GSS handshake succeeds. Note that the first encrypted server to client record (containing the second leg) can be sent in the same protocol round trip as the second half of the TLS handshake. It is an open design issue if these TLS records should be tagged as application records or key exchange records. This is just as in the ALPN approach. They should be tagged as application records so that the implementation can be either at the application layer or in the TLS library. However if it is negotiated via a TLS extension rather than TLS 1.2+ ALPN, thenintegration in the TLS stack will be unavoidable anyway. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. Yep, however as this entails extra round trips, it is not the only option. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. However the early channel binding might save a leg. 7. If the client wants encryption of the first GSS leg, it can either abstain from including that leg in the first SPNego GSS leg, or it can send a 0-byte first leg and then send the real first SPNego leg in the first encrypted client o server record, with the server responding with the second leg in the first encrypted server to client record as before (but no longer in the same round trip as the second half of the TLS handshake). With the ALPN approach this is a given. However if the first leg need not be encrypted and need not know thechannel binding, it can be sent a round earlier. This can (I hope) be decided on a per mechanism basis, thus if a GSS mechanism need not know its channel binding until the second leg, implementations that can provide the binding to the GSS layer later can take advantage of it.
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 5/13/2015 3:17 PM, Nico Williams wrote: Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? Nico, Look for draft-burdis-cat-srp-sasl. It was never standardized but I believe there is an implementation in Cyrus/SASL. This is the most recent version I could find http://www.opensource.apple.com/source/passwordserver_sasl/passwordserver_sasl-159/cyrus_sasl/doc/draft-burdis-cat-srp-sasl-xx.txt Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
We're closer. On Wed, May 13, 2015 at 07:10:10PM +0200, Jakob Bohm wrote: On 13/05/2015 17:46, Nico Williams wrote: On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. The problem is that negotiating twice is bad (for various reasons), and SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is a two-level negotiation that is fraught with peril, therefore forbidden. Ok, having not studied the standard SASL in GSS specification, I presumed each GSS-encapsulated SASL mechanism would have its own GSS mechanism OID in some systematic way, leaving just one negotiation. SASL/GS2 is the other way around: GSS in SASL. The idea is that you can have GSS as SASL mechanisms in a way that sucks less than the original GSS-in-SASL bridge in RFC (that added an extra round-trip), and which makes it easy to add mechanisms like SCRAM as both, a GSS and a SASL mechanism. I'm perfectly happy to drop SASL though. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. It's quite complex owing to having been underspecified in the first place then having grown a number of bug workarounds over the years. Yes, but it is now a mature protocol, and I was trying to avoid creating yet another near identical handshake protocol. The only complication in a negotiation mechanism is protecting the negotiation. Since the TLS handshakes are ultimately integrity- protected, there's no complication at all to having the client send a list of mechanisms and the server pick one (the client can even send an optimistic choice's initial context token). In fact, it's much nicer than SPNEGO in many ways; if at all possible one should avoid SPNEGO. Among other things, not using SPNEGO means that it will be much easier to implement this protocol without extensions to GSS (extensions would be needed only to optimize it). In your protocol the client already sent a SPNEGO initial security context token. A response is required, as GSS context establishment token exchanges are strictly synchronous. As written, I had forgotten about the Finished messages. Thus the point wasto simply delay the server GSS response (2. GSS leg) to just after switching onthe encryption, later in the same round of messages. The 3. leg (second client to server GSS token) would then follow etc. We could extend GSS (see below) to support late channel binding, but since a mechanism might not be able to do it, this protocol would have to fall back on MIC tokens to complete the channel binding, in some cases at a cost of one more round trip. With PROT_READY there should be no need for an extra round-trip. Depends a lot on the mechanism. Some GSS mechanisms (other than Kerberos IV/V) cannot use their MIC until they have received a later token from the other end, but can incorporate binding data earlier than that. I think GSS-SRP-6a has that property. Kerberos in particular supports PROT_READY. There is no Kerberos IV GSS mechanism, FYI. I'd never heard of GSS-SRP-6a; do you have a reference? 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. However the early channel binding might save a leg. You mean late. Your idea seems to be to exposed knowledge of when is the latest that a mechanism can begin to use the channel binding so as to delay giving it the channel binding until we know it. That would be a significant change to GSS, and often it won't help (e.g., Kerberos, the mechanism of interest in this thread). The idea would be if an implementation (not the protocol extension specification as such) is blessed with a non-standard GSS option to provide the channel binding after the 1. leg, but not with the early MIC use ability of Kerberos, the the protocol extension should not prevent it from taking advantage of this to do the channel binding before the 2. leg, rather than
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
For the TL;DR: My original quick writeup included some mistakes in the details of TLS (forgot about Finished messages) and SASL/GS2. It is thus in more than anticipated need of change before it can become a proper spec, finding and fixing such mistakes is the main benefit of having this kind of discussion. On 13/05/2015 17:46, Nico Williams wrote: On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. The problem is that negotiating twice is bad (for various reasons), and SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is a two-level negotiation that is fraught with peril, therefore forbidden. Ok, having not studied the standard SASL in GSS specification, I presumed each GSS-encapsulated SASL mechanism would have its own GSS mechanism OID in some systematic way, leaving just one negotiation. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. It's quite complex owing to having been underspecified in the first place then having grown a number of bug workarounds over the years. Yes, but it is now a mature protocol, and I was trying to avoid creating yet another near identical handshake protocol. It'd be much easier to send a list of mechanism OIDs in the ClientHello, have the server announce a choice in its response, and have the first GSS token sent as early application data in the same flight as the client's Finished message (assuming traditional TLS handshakes here), with GSS channel binding. When the client knows what mechanism they want they could send the initial context token in the ClientHello (if it's not too large) and use MIC tokens for channel binding. But isn't that (essentially) what SPnego does, but in a standardized way with historic quirks? The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. However I strongly suspect that using ALPN will cause practical conflicts with early HTTP/2 implementations and early ALPN implementations, as such early implementations are likely to only cater to that single use of ALPN. Perhaps so. I would prefer to optimize the GSS flights as well too. Ditto. 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension GSS-2 to confirm support. Well, presumably the first response GSS token should go here. No, see below. In your protocol the client already sent a SPNEGO initial security context token. A response is required, as GSS context establishment token exchanges are strictly synchronous. As written, I had forgotten about the Finished messages. Thus the point wasto simply delay the server GSS response (2. GSS leg) to just after switching onthe encryption, later in the same round of messages. The 3. leg (second client to server GSS token) would then follow etc. The ordering of GSS message tokens is of cause crucial for the security guarantees of many mechanisms. It was all about when to send the next token, never about reordering or omitting them. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. Yep, however as this entails extra round trips, it is not the only option. With PROT_READY there should be no need for an extra round-trip. Depends a lot on the mechanism. Some GSS mechanisms (other than Kerberos IV/V) cannot use their MIC until they have received a later token from the other end, but can incorporate binding data earlier than that. I think GSS-SRP-6a has that property. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Wed, May 13, 2015 at 12:03:33PM +0200, Jakob Bohm wrote: On 12/05/2015 21:45, Nico Williams wrote: On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. How? I thought SPNEGO encapsulated and negotiated arbitrary GSS mechanisms. The problem is that negotiating twice is bad (for various reasons), and SASL has non-GSS mechanisms, so negotiating SASL mechanisms, then GSS is a two-level negotiation that is fraught with peril, therefore forbidden. To me the key benefit of SPNEGO is the existence of already battle tested negotiation code readily available i many/most current GSS implementation. It is one less thing to design and implement wrong. It's quite complex owing to having been underspecified in the first place then having grown a number of bug workarounds over the years. It'd be much easier to send a list of mechanism OIDs in the ClientHello, have the server announce a choice in its response, and have the first GSS token sent as early application data in the same flight as the client's Finished message (assuming traditional TLS handshakes here), with GSS channel binding. When the client knows what mechanism they want they could send the initial context token in the ClientHello (if it's not too large) and use MIC tokens for channel binding. The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. However I strongly suspect that using ALPN will cause practical conflicts with early HTTP/2 implementations and early ALPN implementations, as such early implementations are likely to only cater to that single use of ALPN. Perhaps so. I would prefer to optimize the GSS flights as well too. 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension GSS-2 to confirm support. Well, presumably the first response GSS token should go here. No, see below. In your protocol the client already sent a SPNEGO initial security context token. A response is required, as GSS context establishment token exchanges are strictly synchronous. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. Yep, however as this entails extra round trips, it is not the only option. With PROT_READY there should be no need for an extra round-trip. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. However the early channel binding might save a leg. You mean late. Your idea seems to be to exposed knowledge of when is the latest that a mechanism can begin to use the channel binding so as to delay giving it the channel binding until we know it. That would be a significant change to GSS, and often it won't help (e.g., Kerberos, the mechanism of interest in this thread). 7. If the client wants encryption of the first GSS leg, it can either abstain from including that leg in the first SPNego GSS leg, or it can send a 0-byte first leg and then send the real first SPNego leg in the first encrypted client o server record, with the server responding with the second leg in the first encrypted server to client record as before (but no longer in the same round trip as the second half of the TLS handshake). With the ALPN approach this is a given. However if the first leg need not be encrypted and need not know thechannel binding, it can be sent a round earlier. This can (I hope) be decided on a per mechanism basis, thus if a GSS mechanism need not know its channel binding until the second leg, implementations that can provide the binding to the GSS layer later can take advantage of it. No, this can't be decided on a per-mechanism basis, not without first modifying GSS significantly. 9. When the GSS-2 extension is negotiated, TLS implementations SHOULD allow anonymous (unauthenticated) cipher suites even if they
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
I wonder if we could do this in the KITTEN WG list. Maybe not every extension to TLS needs to be treated as a TLS WG work item... We should ask the security ADs. Nico -- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
I should add that I prefer a protocol that optimizes the GSS round trips over one that doesn't, though that means using SPNEGO for negotiation (when negotiation is desired). ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Tue, May 12, 2015 at 08:23:34PM +0200, Jakob Bohm wrote: How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). SASL/GS2 and SPNEGO are incompatible. The ALPN approach is to do the mechanism negotiation via ALPN. This is much better than SPNEGO in general. We don't have to use the ALPN approach, and we don't have to support SASL. But see below. 2. The TLS client always begins by sending the first GSS/SPNego leg in a (new) TLS extension GSS-2. This is incompatible with doing channel binding the GSS way. Instead we'd have to exchange MICs of the channel binding when the GSS context is fully established. (This is fine, of course, and not a criticism, just pointing this out.) 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension GSS-2 to confirm support. Well, presumably the first response GSS token should go here. 4. The second and subsequent legs of the GSS handshake are sent as the sole contents of the first encrypted records, actual application data is not sent until the GSS handshake succeeds. Note that the first encrypted server to client record (containing the second leg) can be sent in the same protocol round trip as the second half of the TLS handshake. It is an open design issue if these TLS records should be tagged as application records or key exchange records. This is just as in the ALPN approach. They should be tagged as application records so that the implementation can be either at the application layer or in the TLS library. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. This is the MIC exchange I mention above. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. If we're doing a MIC exchange then we don't need to know the channel binding a initial security context token production time. 7. If the client wants encryption of the first GSS leg, it can either abstain from including that leg in the first SPNego GSS leg, or it can send a 0-byte first leg and then send the real first SPNego leg in the first encrypted client o server record, with the server responding with the second leg in the first encrypted server to client record as before (but no longer in the same round trip as the second half of the TLS handshake). With the ALPN approach this is a given. 8. If the GSS mechanism reports failure, the TLS connection SHALL be aborted with a specified alert. Yes. 9. When the GSS-2 extension is negotiated, TLS implementations SHOULD allow anonymous (unauthenticated) cipher suites even if they would not otherwise do so, however they MUST be able to combine the GSS-2 extension with any and all of the cipher suites and TLS versions they otherwise implement. For instance, if an implementation of the GSS-2 extension is somehow bolted on to a fully patched OpenSSL 1.0.0 library (via generic extension mechanisms), then that combination would support it with TLS 1.0 only, and TLS 1.3 capable implementations would be negotiating TLS 1.0 when doing GSS-2 with such an implementation. If only GSS mechanisms that provide integrity protection or better as used, then this is fine. 10. Session resumption and Session renegotiation shall have the same semantics for the GSS authentication result as they do for certificate validation results done in the same handshakes. Yes. 11. NPN and ALPN are neither required nor affected by GSS-2 and operate as they would with any other TLS mechanisms, such as certificates. NPN is out of the question now. You're missing a status message for authorization (GSS authentication might complete, but authorization fail), though this is not strictly necessary: the server can simply close the connection, including sending an alert about this (or not) just before closing the connection. Nico -- ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On 11/05/2015 20:52, Nico Williams wrote: On Mon, May 11, 2015 at 04:42:49PM +, Viktor Dukhovni wrote: On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject[*] TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. [*] Except when employing unauthenticated encrypted communication to mitigate passive monitoring (oportunistic security). As this would be replacing RFC2712, it's not opportunistic to begin with :) As this would be a new RFC, it might be usable for cases where RFC2712 was never usable. How about the following simplifications for the new extension, lets call it GSS-2 (at least in this e-mail). 1. GSS (including SASL/GS2) is always done via the SPNego GSS mechanism, which provides standard handling of mechanism negotiation (including round-trip optimizations), and is already its own standard (complete with workarounds for historic bugs in the dominant implementation...). 2. The TLS client always begins by sending the first GSS/SPNego leg in a (new) TLS extension GSS-2. 3. The TLS server (if it supports and allows the extension) responds with a 0 byte TLS extension GSS-2 to confirm support. 4. The second and subsequent legs of the GSS handshake are sent as the sole contents of the first encrypted records, actual application data is not sent until the GSS handshake succeeds. Note that the first encrypted server to client record (containing the second leg) can be sent in the same protocol round trip as the second half of the TLS handshake. It is an open design issue if these TLS records should be tagged as application records or key exchange records. 5. In the last legs, the GSS mechanism is told to (mutually if possible) authenticate some already defined hash of the TLS handshake, thereby protecting the key exchange.Other than the round trip saving for the first 2 legs, this is what distinguishes GSS-2 from simply doing application level GSS over a TLS connection. Any GSS negotiated keys are not used beyond this authentication of the TLS key exchange. 6. If the GSS mechanism preferred by the client requires the authenticated hash value to be known before sending the first GSS leg, then the client shall simply abstain from including that first leg in the first leg SPNego message if sent in the client hello extension. 7. If the client wants encryption of the first GSS leg, it can either abstain from including that leg in the first SPNego GSS leg, or it can send a 0-byte first leg and then send the real first SPNego leg in the first encrypted client o server record, with the server responding with the second leg in the first encrypted server to client record as before (but no longer in the same round trip as the second half of the TLS handshake). 8. If the GSS mechanism reports failure, the TLS connection SHALL be aborted with a specified alert. 9. When the GSS-2 extension is negotiated, TLS implementations SHOULD allow anonymous (unauthenticated) cipher suites even if they would not otherwise do so, however they MUST be able to combine the GSS-2 extension with any and all of the cipher suites and TLS versions they otherwise implement. For instance, if an implementation of the GSS-2 extension is somehow bolted on to a fully patched OpenSSL 1.0.0 library (via generic extension mechanisms), then that combination would support it with TLS 1.0 only, and TLS 1.3 capable implementations would be negotiating TLS 1.0 when doing GSS-2 with such an implementation. 10. Session resumption and Session renegotiation shall have the same semantics for the GSS authentication result as they do for certificate validation results done in the same handshakes. 11. NPN and ALPN are neither required nor affected by GSS-2 and operate as they would with any other TLS mechanisms, such as certificates. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Mon, May 11, 2015 at 04:42:49PM +, Viktor Dukhovni wrote: On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject[*] TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. [*] Except when employing unauthenticated encrypted communication to mitigate passive monitoring (oportunistic security). As this would be replacing RFC2712, it's not opportunistic to begin with :) ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-dev] Replacing RFC2712 (was Re: Kerberos)
On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject[*] TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. [*] Except when employing unauthenticated encrypted communication to mitigate passive monitoring (oportunistic security). -- Viktor. ___ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
