Usage of Channel Binding

[dequbed]

Usage of Channel Binding

[dequbed]

ok, it might seem a dumb question, but it's genuine. what does it matter if a channel is encrypted or not, if the goal is to make sure that both sides see the same channel? and if the two parties can authenticate each other (which they do) then presuming that the ephemeral keys are indeed only used once, the authentication is bound to that tcp connection - limiting here to tcp like transports makes sense i hope, with udp this might not work. so i think opaque does indeed bind to a channel implicitly, and i think the fact of it being encrypted does not matter, as long as the channel is tcp-like connection-based.

Right, I think we need to fix terminology here:
The encrypted "channel" that is referred to here is the outer secure transport, not anything inside the authentication itself. So, for example if we have an TLS-encrypted XMPP session this TLS layer is the "channel" that is being bound to.

What channel binding aims to do is assure to both parties that this encrypted channel is not being intercepted. This is done by taking some data that uniquely identifies the encrypted channel, such as a transcript hash, TLS exporter data or a hash of a certificate or public key used, and including that data into the cryptographic authentication.

This way the authentication will only succeed if both sides can agree on this data. This way users can be sure their encrypted channel is not being MitM-ed, preventing certain attacks where an attacker waits for an user to authenticate and then uses the elevated permissions of the session context to do nefarious things.

[dequbed]

Relevant documents are:

RFC 5056 for the general principle of channel binding

RFC 9266 for channel binding using TLS exporter

RFC 5929 for channel binding using the public key/certificate used

RFC 5802, Section 6 for an example how channel binding is used in SCRAM

[stef]

Right, I think we need to fix terminology here: The encrypted "channel" that is referred to here is the outer secure transport, not anything inside the authentication itself. So, for example if we have an TLS-encrypted XMPP session this TLS layer is the "channel" that is being bound to.

this is clear.

What channel binding aims to do is assure to both parties that this encrypted channel is not being intercepted.

but this is not what you wrote in the parent post, where you wrote:

Channel binding is about binding an authentication to an underlying encrypted channel like TLS and thus making sure that both sides see the same channel.

and with this interpretation my argument holds the authentication itself is bound to the channel.

you continue:

This is done by taking some data that uniquely identifies the encrypted channel, such as a transcript hash, TLS exporter data or a hash of a certificate or public key used, and including that data into the cryptographic authentication.

but the encrypted(or not) channel is already identified by the ephemeral keys at the end of both peers. as long as those ephemeral keys are not reused in the same pair, this should be already binding the session to the tcp channel.

This way the authentication will only succeed if both sides can agree on this data. This way users can be sure their encrypted channel is not being MitM-ed, preventing certain attacks where an attacker waits for an user to authenticate and then uses the elevated permissions of the session context to do nefarious things.

so then it is not about binding the authentication to the channel, but to actually make sure that the messages after the authentication are from the authenticated peers, and no one else.

but that means that the channel doesn't have to be encrypted, it's enough if the channel is authenticated, so that a mitm cannot change or inject extra messages. and this also means that channel binding only makes sense if there is some kind of security layer (be it auth, or non-malleable confidentiality) after the authentication is successful.

on the other hand this makes SASL OPAQUE with channel binding kinda impossible to use in enterprise settings with MITMboxes at the perimeter, so i guess it has to be optional.

but i guess this kinda makes a case for channel binding to a secure layer, be it tls or the SL from saSL. imo the best solution would be if this would be revived: https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/ and passed. i tried many times triggering nick and chris to pick this up, maybe you can also trigger them?

thanks for clarifying.

[dequbed]

This way the authentication will only succeed if both sides can agree on this data. This way users can be sure their encrypted channel is not being MitM-ed, preventing certain attacks where an attacker waits for an user to authenticate and then uses the elevated permissions of the session context to do nefarious things.

so then it is not about binding the authentication to the channel, but to actually make sure that the messages after the authentication are from the authenticated peers, and no one else.

Yes, that is the core idea. Granted, I use the words "encrypted" and "secure" interchangeable because with todays cryptography secure channels that offer integrity but don't offer confidentiality have become vanishingly rare, although they are of course separate concepts.

What channel binding aims to do is assure to both parties that this encrypted channel is not being intercepted.

but this is not what you wrote in the parent post, where you wrote:

Channel binding is about binding an authentication to an underlying encrypted channel like TLS and thus making sure that both sides see the same channel.

and with this interpretation my argument holds the authentication itself is bound to the channel.

I should have chosen my words here more carefully, I of course mean actively intercepted. But then no, those two statements imply the exact same, even more so if you read "encrypted channel" as "secure channel".

you continue:

This is done by taking some data that uniquely identifies the encrypted channel, such as a transcript hash, TLS exporter data or a hash of a certificate or public key used, and including that data into the cryptographic authentication.

but the encrypted(or not) channel is already identified by the ephemeral keys at the end of both peers. as long as those ephemeral keys are not reused in the same pair, this should be already binding the session to the tcp channel.

No. Nothing necessarily identifies the ephemeral keys, not reusing them does not guard at all against an active attacker. For that you need to either pre-emptively authenticate those keys via e.g. PKI, or authenticate them later, e.g. — as channel binding does — via the user authentication.

[…] but that means that the channel doesn't have to be encrypted, it's enough if the channel is authenticated, so that a mitm cannot change or inject extra messages. and this also means that channel binding only makes sense if there is some kind of security layer (be it auth, or non-malleable confidentiality) after the authentication is successful.

Yes, and?

Notably, this does not imply that this channel can not already exist beforehand.

on the other hand this makes SASL OPAQUE with channel binding kinda impossible to use in enterprise settings with MITMboxes at the perimeter, so i guess it has to be optional.

Not necessarily.

But usually channel binding is an optional feature.

but i guess this kinda makes a case for channel binding to a secure layer, be it tls or the SL from saSL.

You do not need to channel bind to a security layer established using SASL. The authenticity of it is already established due to the authentication it came from. Channel binding is a better replacement for SASL security layers.

imo the best solution would be if this would be revived: https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/ and passed. i tried many times triggering nick and chris to pick this up, maybe you can also trigger them?

Using OPAQUE to set up an authenticated TLS channel is completely orthogonal to SASL channel binding and does not remove the need for it.

[stef]

Yes, that is the core idea. Granted, I use the words "encrypted" and "secure" interchangeable because with todays cryptography secure channels that offer integrity but don't offer confidentiality have become vanishingly rare, although they are of course separate concepts.

neither encrypted nor secure have a well defined meaning. it's better to spell out the security guarantees.

What channel binding aims to do is assure to both parties that this encrypted channel is not being intercepted.

but this is not what you wrote in the parent post, where you wrote:

Channel binding is about binding an authentication to an underlying encrypted channel like TLS and thus making sure that both sides see the same channel.
and with this interpretation my argument holds the authentication itself is bound to the channel.

I should have chosen my words here more carefully, I of course mean actively intercepted. But then no, those two statements imply the exact same, even more so if you read "encrypted channel" as "secure channel".

i dunno, does encrypted mean confidentiality + authenticity, or integrity? does secure channel mean any of these things? and my interpretation only means that the authentication is bound to the channel, meaning the authentication cannot be replayed or reused. your interpretation goes further than that. both are valid, just from different perspectives/understanding what has been said before.

but the encrypted(or not) channel is already identified by the ephemeral keys at the end of both peers. as long as those ephemeral keys are not reused in the same pair, this should be already binding the session to the tcp channel.

No. Nothing necessarily identifies the ephemeral keys, not reusing them does not guard at all against an active attacker. For that you need to either pre-emptively authenticate those keys via e.g. PKI, or authenticate them later, e.g. — as channel binding does — via the user authentication.

of course noone ever authenticates ephemeral keys, that makes no sense. hence you have long-term keys also
these are essential in this setup, via x3dh. and those are(or should be) authenticated during registration. the reason for having ephemeral keys is to have each session being unique, and you could say bound to each other, at least for the sake of replayability and forward security.

[…] but that means that the channel doesn't have to be encrypted, it's enough if the channel is authenticated, so that a mitm cannot change or inject extra messages. and this also means that channel binding only makes sense if there is some kind of security layer (be it auth, or non-malleable confidentiality) after the authentication is successful.

Yes, and?
Notably, this does not imply that this channel can not already exist beforehand.

no but it implies that the channel up to the authentication can be an entirely different one from the one after the authentication.

on the other hand this makes SASL OPAQUE with channel binding kinda impossible to use in enterprise settings with MITMboxes at the perimeter, so i guess it has to be optional.

Not necessarily.
But usually channel binding is an optional feature.

but i guess this kinda makes a case for channel binding to a secure layer, be it tls or the SL from saSL.

You do not need to channel bind to a security layer established using SASL. The authenticity of it is already established due to the authentication it came from. Channel binding is a better replacement for SASL security layers.

well i can totally imagine a completely plaintext (no CIA whatsoever) connection that authenticates parties that authenticate each other via opaque. although i'm not sure what you mean with "the authenticity of ?it? is already established due to the authentication it comes from" i can also totally imagine a TLS connection via a MITMbox that authenticates peers using opaque. and when you write "channel binding is a better replacement[..]" again i'm not sure i understand you, since if you do OPAQUE and use the shared secret that falls out of it to just do a simple xchacha/poly1305 using that you also have implicit channel binding, even if there is an active party in the middle.

imo the best solution would be if this would be revived: https://datatracker.ietf.org/doc/draft-sullivan-tls-opaque/ and passed. i tried many times triggering nick and chris to pick this up, maybe you can also trigger them?

Using OPAQUE to set up an authenticated TLS channel is completely orthogonal to SASL channel binding and does not remove the need for it.

no, not at all. tls is just another security layer (with a whole lot of design-by-committee and politics) that is completely interchangeable with any other "sane" security layer. and actually TLS makes a lot of sense since it is an established proto, that is mostly tolerated everywhere (even the GFW). and opaque+tls is combining the best of both worlds. and i believe that tls-opaque is the correct way to do a sasl security layer based on opaque. (other than feeding a double ratchet, or just plain naked xchacha20/poly1305)

[stef]

i think the trouble is we have very different perspectives, and understand different parts of the domain. it's very productive to trying to understand the other interpretation. thank you for this dialogue!

[dequbed]

neither encrypted nor secure have a well defined meaning. it's better to spell out the security guarantees.

RFC 5056, Section 2

i dunno, does encrypted mean confidentiality + authenticity, or integrity? does secure channel mean any of these things? and my interpretation only means that the authentication is bound to the channel, meaning the authentication cannot be replayed or reused. your interpretation goes further than that. both are valid, just from different perspectives/understanding what has been said before.

RFC 5056, Section 2

I use "encrypted channel" as a secure channel offering confidentiality and integrity.

but the encrypted(or not) channel is already identified by the ephemeral keys at the end of both peers. as long as those ephemeral keys are not reused in the same pair, this should be already binding the session to the tcp channel.

No. Nothing necessarily identifies the ephemeral keys, not reusing them does not guard at all against an active attacker. For that you need to either pre-emptively authenticate those keys via e.g. PKI, or authenticate them later, e.g. — as channel binding does — via the user authentication.

of course noone ever authenticates ephemeral keys, that makes no sense. hence you have long-term keys also these are essential in this setup, via x3dh. and those are(or should be) authenticated during registration. the reason for having ephemeral keys is to have each session being unique, and you could say bound to each other, at least for the sake of replayability and forward security.

This does not in any way authenticate long- or short term keys used by the secure channel. This is exactly what channel binding is about; authenticating the otherwise independently set up secure channel, usually by authenticating the keys used.

[…] but that means that the channel doesn't have to be encrypted, it's enough if the channel is authenticated, so that a mitm cannot change or inject extra messages. and this also means that channel binding only makes sense if there is some kind of security layer (be it auth, or non-malleable confidentiality) after the authentication is successful.

Yes, and?
Notably, this does not imply that this channel can not already exist beforehand.

no but it implies that the channel up to the authentication can be an entirely different one from the one after the authentication.

Yes, and?

You do not need to channel bind to a security layer established using SASL. The authenticity of it is already established due to the authentication it came from. Channel binding is a better replacement for SASL security layers.

well i can totally imagine a completely plaintext (no CIA whatsoever) connection that authenticates parties that authenticate each other via opaque. although i'm not sure what you mean with "the authenticity of ?it? is already established due to the authentication it comes from" i can also totally imagine a TLS connection via a MITMbox that authenticates peers using opaque. and when you write "channel binding is a better replacement[..]" again i'm not sure i understand you, since if you do OPAQUE and use the shared secret that falls out of it to just do a simple xchacha/poly1305 using that you also have implicit channel binding, even if there is an active party in the middle.

If you use SASL security layers the security layer is a product of the authentication exchange. As a very rough approximation a proper SASL authentication exchange establishing a security layer should behave somewhat similar to an AKE (authenticated key exchange).
So, the "authenticity of [the security layer] is already established [because it is based on a modified AKE]"

And thus, yes exactly. If you would use the session key from an OPAQUE authentication to establish a security layer you do not need channel binding.

Using OPAQUE to set up an authenticated TLS channel is completely orthogonal to SASL channel binding and does not remove the need for it.

no, not at all. tls is just another security layer (with a whole lot of design-by-committee and politics) that is completely interchangeable with any other "sane" security layer. and actually TLS makes a lot of sense since it is an established proto, that is mostly tolerated everywhere (even the GFW). and opaque+tls is combining the best of both worlds. and i believe that tls-opaque is the correct way to do a sasl security layer based on opaque.

No, this is entirely orthogonal. Using OPAQUE to bootstrap TLS has the specific applicability of setting up a mutually authenticated encrypted channel using TLS, much like client certificates do. And similiar to client certificates you would then use SASL EXTERNAL as the appropiate SASL mechanism.

To drill it down, SASL security layers are a very specific concept. They are very much not "just use a secure channel like TLS". So no, TLS-OPAQUE is not combining the best of both worlds, it is an entirely different thing.

I will give you half a point though. Using the TLS state machine is probably the best way of doing a SASL security layer. But you wouldn't use TLS-OPAQUE, because that doesn't give you what you need for SASL. Instead you'd do SASL OPAQUE and then use TLS-PSK with the session key.

But at that point, just use TLS. The most you can save here is a single roundtrip for STARTTLS. And if you must reduce round-trips, just use TLS-OPAQUE and SASL EXTERNAL.

([…] or just plain naked xchacha20/poly1305)

And that is a dangerous idea. A lot of the TLS state machine is required to make the usage limits of this AEAD are never hit.

[dequbed]

I'd like to say sorry for my rather harsh wording yesterday. I had become a bit exasperated and it was undue.

[stef]

no worries! it's not easy and it seems we have very different perspectives, so that leads to misunderstandings.

[stef]

neither encrypted nor secure have a well defined meaning. it's better to spell out the security guarantees.

RFC 5056, Section 2

ah. ok, i guess it makes sense to limit the context and definition this rfc. thanks.

i dunno, does encrypted mean confidentiality + authenticity, or integrity? does secure channel mean any of these things? and my interpretation only means that the authentication is bound to the channel, meaning the authentication cannot be replayed or reused. your interpretation goes further than that. both are valid, just from different perspectives/understanding what has been said before.

RFC 5056, Section 2

I use "encrypted channel" as a secure channel offering confidentiality and integrity.

i see.

but the encrypted(or not) channel is already identified by the ephemeral keys at the end of both peers. as long as those ephemeral keys are not reused in the same pair, this should be already binding the session to the tcp channel.

No. Nothing necessarily identifies the ephemeral keys, not reusing them does not guard at all against an active attacker. For that you need to either pre-emptively authenticate those keys via e.g. PKI, or authenticate them later, e.g. — as channel binding does — via the user authentication.

of course noone ever authenticates ephemeral keys, that makes no sense. hence you have long-term keys also these are essential in this setup, via x3dh. and those are(or should be) authenticated during registration. the reason for having ephemeral keys is to have each session being unique, and you could say bound to each other, at least for the sake of replayability and forward security.

This does not in any way authenticate long- or short term keys used by the secure channel.

to quote https://signal.org/docs/specifications/x3dh/#sending-the-initial-message

The following diagram shows the DH calculations between keys. Note that DH1 and DH2 provide mutual authentication, while DH3 and DH4 provide forward secrecy.

where dh[12] are the long-term keys, and dh[34] the ephemeral keys.

This is exactly what channel binding is about; authenticating the otherwise independently set up secure channel, usually by authenticating the keys used.

opaque actually authenticates the used long-term keys during the 3dh ake. channel binding is not about that, earlier we established channel binding is about making sure the messages after the authentication are somehow bound to the authentication.

This does not in any way authenticate long- or short term keys used by the secure channel.

long-term keys are authenticated by the 3dh. and that's all that matters.

[…] but that means that the channel doesn't have to be encrypted, it's enough if the channel is authenticated, so that a mitm cannot change or inject extra messages. and this also means that channel binding only makes sense if there is some kind of security layer (be it auth, or non-malleable confidentiality) after the authentication is successful.

Yes, and?
Notably, this does not imply that this channel can not already exist beforehand.

no but it implies that the channel up to the authentication can be an entirely different one from the one after the authentication.

Yes, and?

i dunno if you know but opaque it self does not need an secure (in your definition) channel at all. so you can easily start with plaintext doing opaque, and then switch to something "secure".

You do not need to channel bind to a security layer established using SASL. The authenticity of it is already established due to the authentication it came from. Channel binding is a better replacement for SASL security layers.
well i can totally imagine a completely plaintext (no CIA whatsoever) connection that authenticates parties that authenticate each other via opaque. although i'm not sure what you mean with "the authenticity of ?it? is already established due to the authentication it comes from" i can also totally imagine a TLS connection via a MITMbox that authenticates peers using opaque. and when you write "channel binding is a better replacement[..]" again i'm not sure i understand you, since if you do OPAQUE and use the shared secret that falls out of it to just do a simple xchacha/poly1305 using that you also have implicit channel binding, even if there is an active party in the middle.

If you use SASL security layers the security layer is a product of the authentication exchange. As a very rough approximation a proper SASL authentication exchange establishing a security layer should behave somewhat similar to an AKE (authenticated key exchange). So, the "authenticity of [the security layer] is already established [because it is based on a modified AKE]"

yes. that makes sense.

And thus, yes exactly. If you would use the session key from an OPAQUE authentication to establish a security layer you do not need channel binding.

exactly. what i'm saying, even if sloppily. excuses for that.

Using OPAQUE to set up an authenticated TLS channel is completely orthogonal to SASL channel binding and does not remove the need for it.

no, not at all. tls is just another security layer (with a whole lot of design-by-committee and politics) that is completely interchangeable with any other "sane" security layer. and actually TLS makes a lot of sense since it is an established proto, that is mostly tolerated everywhere (even the GFW). and opaque+tls is combining the best of both worlds. and i believe that tls-opaque is the correct way to do a sasl security layer based on opaque.

No, this is entirely orthogonal. Using OPAQUE to bootstrap TLS has the specific applicability of setting up a mutually authenticated encrypted channel using TLS, much like client certificates do.

yes, so it goes beyond plain tls as used generally.

And similiar to client certificates you would then use SASL EXTERNAL as the appropiate SASL mechanism.

aha! i think this is the misunderstanding, what i mean, that tls is only established after opaque, as the sl, not before, as it is not needed for opaque.

To drill it down, SASL security layers are a very specific concept. They are very much not "just use a secure channel like TLS". So no, TLS-OPAQUE is not combining the best of both worlds, it is an entirely different thing.

i'm not sure i follow, is this because we think of tls differently? you as something that sasl runs on and me as something were tls is the SL from opauqe?
and the nice thing if we use the shared secret as the input for the session key of tls, then we can actually skip KE3 from opaque, as the encryption of the following packets will implicitly authenticate the client to the server. explicit user auth is only needed with opaque if the shared secret is not used for further encrypted communication.

I will give you half a point though. Using the TLS state machine is probably the best way of doing a SASL security layer. But you wouldn't use TLS-OPAQUE, because that doesn't give you what you need for SASL. Instead you'd do SASL OPAQUE and then use TLS-PSK with the session key.

you are closer to the correct way of doing this than i was in my sloppy way. tls-psk is almost what you want, but better, since psk is a static pre-shared key (as psk implies) it indeed needs roundtrips to set up the tls session, but from opaque a unique shared key already falls out, so you can skip a few steps i hope. but my tls proto understanding at this late stage of tls is limited, so it might be naive.

But at that point, just use TLS. The most you can save here is a single roundtrip for STARTTLS. And if you must reduce round-trips, just use TLS-OPAQUE and SASL EXTERNAL.

i'm not sure i follow the last thought of you there? doesn't it mean that if you use sals external you already have setup tls and executed all the necessary roundtrips for it and there is no "saving steps" whereas if you skip those steps and present the shared key from opaque to be the "session-key" of tls then you indeed skip a few roundtrips?

([…] or just plain naked xchacha20/poly1305)

And that is a stupid idea. I hope you do realize how much of the TLS state machine is required just to make this specific AEAD safe to use.

nope. please tell me. again, my context is, that opaque runs over unsecured channel and then switches to the secured channel using xchacha20/poly1305. not the other way around, having an "encrypted" or secure channel over which you run opaque.

anyway i was thinking of your two goals:

1/ channel binding to an existing tls session over which you run sasl (using perhaps opaque)
2/ KSF configuration

i don't think the original IRTF CFRG opaque spec needs any changes, both of these goals i think are simply achievable.

1/ you want channel binding, so opaque itself authenticates the peers,
which is ok, but you also want to authenticate the channel. so you
just do an extra hmac with the shared secret over the channel
parameters on the server before returning KE2, and the client can
verify this hmac by recalculating the value itself. note this only
binds the channel for the client, if you also want to bind this for
the server we need to send back a similar but different hmac to the
server together with KE3. you don't modify the OPAQUE base spec at
all, and you get what you want.

i mean OPAQUE is a base primitive upon which a lot of other protos
will be (hopefully) built we can try to accomodate all of them and
bloat opaque up, or we can actually build upon it, extending it like
the above. granted, you have 2 (or 4) more hmac calculations per
connection. on the client this makes absolutely no performance
difference, and considering the cost of doing all the elliptic curve
stuff on the server one or two extra hmacs don't mean much of a
difference either.

2/ you want to negotiate/specify somehow the KSF configuration. but i
say this is not necessary! because the server (in the IRTF CFRG
specified version) does not now or care about the clients KSF
config. hell everything would work totally fine, if all clients would
use different KSF configs with the same server.

there is an exception to this, if the server implements the one-step
non-private password registration function that is specified in the
original opaque paper, since then the server does it all, also the
initial KSF when registering. But the IRTF CFRG does specify only the
4 step privacy respecting registration, where the client does the
KSF. However and this sucks, SASL (afaik) doesn't support this, at
least with cyrus-sasl the admin uses saslpasswd2 on the server to
create a new user. and this sucks a lot, since with opaque it is
really awesome that the password doesn't have to be ever exposed to
the server.

so if the registration of users can be somehow solved to actually use
the 4 step privacy-protective registration procedure, then clients can
choose whatever they want for KSF. with one caveat though, in this
case the client needs to remember the KSF configuration, and another
cool thing about opaque would be broken then, the fact that the client
does not have to store or maintain any kind of state or
configuration. which i guess is a bit of cheating, since the client
needs to know the server to which to initiate the opaque dance with,
and if we store a server name, i guess it's also ok to store the ksf
config next to it on clients.

[dequbed]

to quote https://signal.org/docs/specifications/x3dh/#sending-the-initial-message

The following diagram shows the DH calculations between keys. Note that DH1 and DH2 provide mutual authentication, while DH3 and DH4 provide forward secrecy.

where dh[12] are the long-term keys, and dh[34] the ephemeral keys.

I know how X3DH works. None of that matters. See below.

opaque actually authenticates the used long-term keys during the 3dh ake. channel binding is not about that, earlier we established channel binding is about making sure the messages after the authentication are somehow bound to the authentication.

No, quoting RFC 5056:

Channel binding: the process of establishing that no man-in-the-middle exists between two end-points that have been authenticated at one network layer but are using a secure channel at a lower network layer. This term is used as a noun.

Channel Binding does give you this latter assure you are talking about. But not every way of getting this assurance is called "Channel Binding" in the context of SASL.

This does not in any way authenticate long- or short term keys used by the secure channel.

long-term keys are authenticated by the 3dh. and that's all that matters.

No they aren't. And the fact that they aren't is what matters.

So, I think I know what the misunderstanding is. Channel Binding is used in the specific case where you have an already-established secure channel, and after establishing this secure channel perform some sort of authentication that validates this secure channel. This is not debatable, this is the definition of the term Channel Binding in the context of SASL. If you do not have this case, you can not have Channel Binding.

Notably, to drill this down again, if you use SASL to establish a secure channel you can not use Channel Binding to bind to that particular channel.

If you perform OPAQUE in the clear, you can not have channel binding.

[…] but that means that the channel doesn't have to be encrypted, it's enough if the channel is authenticated, so that a mitm cannot change or inject extra messages. and this also means that channel binding only makes sense if there is some kind of security layer (be it auth, or non-malleable confidentiality) after the authentication is successful.

Yes, and?
Notably, this does not imply that this channel can not already exist beforehand.

no but it implies that the channel up to the authentication can be an entirely different one from the one after the authentication.

Yes, and?

i dunno if you know but opaque it self does not need an secure (in your definition) channel at all. so you can easily start with plaintext doing opaque, and then switch to something "secure".

Yes thank you I am well aware of that. But as stated above in that case you can not have Channel Binding. And this issue is about Channel Binding.

What you are describing there is using SASL to establish a secure channel, i.e. the "security layer" part of SASL. Which is an entirely different thing and completely orthogonal to Channel Binding. And, most importantly, does not remove the need for Channel Binding in the specific case in which Channel Binding can be used.

To drill it down, SASL security layers are a very specific concept. They are very much not "just use a secure channel like TLS". So no, TLS-OPAQUE is not combining the best of both worlds, it is an entirely different thing.

i'm not sure i follow, is this because we think of tls differently? you as something that sasl runs on and me as something were tls is the SL from opauqe? and the nice thing if we use the shared secret as the input for the session key of tls, then we can actually skip KE3 from opaque, as the encryption of the following packets will implicitly authenticate the client to the server. explicit user auth is only needed with opaque if the shared secret is not used for further encrypted communication.

Two things:

1. no I'm not thinking about TLS differently. But TLS doesn't magically become the SL of a SASL OPAQUE mechanism, it needs to be specified that way too. And it doesn't help us in the case where we would want to use Channel Binding, see above.
2. No we can not drop KE3. The AEAD in use in modern TLS are not key committing, the fact that we can decrypt packets is not enough for strong authentication.

I will give you half a point though. Using the TLS state machine is probably the best way of doing a SASL security layer. But you wouldn't use TLS-OPAQUE, because that doesn't give you what you need for SASL. Instead you'd do SASL OPAQUE and then use TLS-PSK with the session key.

you are closer to the correct way of doing this than i was in my sloppy way. tls-psk is almost what you want, but better, since psk is a static pre-shared key (as psk implies) it indeed needs roundtrips to set up the tls session, but from opaque a unique shared key already falls out, so you can skip a few steps i hope. but my tls proto understanding at this late stage of tls is limited, so it might be naive.

In this specific use case, as the session key is unique per authentication, you could use the TLS PSK_KE mode which almost directly derives the master secret from the provided PSK, without losing forward secrecy. Using Early Data it also allows you to immediately use the TLS context without having to wait for the answer from the server.

But at that point, just use TLS. The most you can save here is a single roundtrip for STARTTLS. And if you must reduce round-trips, just use TLS-OPAQUE and SASL EXTERNAL.

i'm not sure i follow the last thought of you there? doesn't it mean that if you use sals external you already have setup tls and executed all the necessary roundtrips for it and there is no "saving steps" whereas if you skip those steps and present the shared key from opaque to be the "session-key" of tls then you indeed skip a few roundtrips?

Let's do an example. I'm doing IMAP by the book using STARTTLS. The first round-trip goes to IMAP EHLO, the second and third to STARTTLS handshakes, and the fourth for 'AUTH EXTERNAL'. I am now authenticated.

Next example. I'm doing IMAP with SASL OPAQUE with a security layer established by that. The first round-trip again goes to IMAP EHLO, the second and third however go to 'AUTH OPAQUE'. I am now authenticated and have established a security layer.

Now, last example. I'm doing IMAPS using TLS-OPAQUE. The first and second round-trip go towards TLS-OPAQUE. If I have a fancy IMAP implementation I am immediately authenticated with no further actions necessary. If not, I may need a third roundtrip for 'AUTH EXTERNAL'.
However depending on how TLS-OPAQUE is done the server may also be able to already send the IMAP EHLO in the first round-trip using the (not yet verified) session key, in essence sending the IMAP EHLO directly after KE2 without waiting for the client answering with KE3. The client may also send its first IMAP commands directly after KE3 since it could decrypt the IMAP EHLO sent after KE2.

Notably, none of this early data shenanigans of the last example is possible with a SASL security layer. If you need to keep round-trips to an absolute minimum, TLS-OPAQUE is the way to go.

([…] or just plain naked xchacha20/poly1305)

And that is a stupid idea. I hope you do realize how much of the TLS state machine is required just to make this specific AEAD safe to use.

nope. please tell me. again, my context is, that opaque runs over unsecured channel and then switches to the secured channel using xchacha20/poly1305. not the other way around, having an "encrypted" or secure channel over which you run opaque.

Right, you probably know that XChaCha20/Poly1305 too has usage limits. They are designed to be high, but they do exist. TLS implementations rotate their traffic keys quite regularly. Yes, the usage limits of XChaCha20/Poly1305 are high enough that most prolonged usages are safe enough but the question of "is it safe?" quickly becomes one of "what's your threat model" and I do not want to write out a threat model in an SASL RFC.

anyway i was thinking of your two goals:

1/ channel binding to an existing tls session over which you run sasl (using perhaps opaque) 2/ KSF configuration

i don't think the original IRTF CFRG opaque spec needs any changes, both of these goals i think are simply achievable.

1/ you want channel binding, so opaque itself authenticates the peers, which is ok, but you also want to authenticate the channel. so you just do an extra hmac with the shared secret over the channel parameters on the server before returning KE2, and the client can verify this hmac by recalculating the value itself. note this only binds the channel for the client, if you also want to bind this for the server we need to send back a similar but different hmac to the server together with KE3. you don't modify the OPAQUE base spec at all, and you get what you want.

I could do that, yes. But I could also skip that extra HMAC and then also wouldn't be forced to violate Section 6.2.4. of the OPAQUE spec saying, and I quote, "[The ServerFinish function] MUST NOT return the session_key value if the client authentication material is invalid".

So no, if anything I could send it from client to server in the last message, i.e. next to KE3.

But again, I could also use the MAC that is already there for this specific purpose. Which, IMO, makes just slightly more sense.

i mean OPAQUE is a base primitive upon which a lot of other protos will be (hopefully) built we can try to accomodate all of them and bloat opaque up, or we can actually build upon it, extending it like the above. granted, you have 2 (or 4) more hmac calculations per connection. on the client this makes absolutely no performance difference, and considering the cost of doing all the elliptic curve stuff on the server one or two extra hmacs don't mean much of a difference either.

The change I am proposing does not bloat up OPAQUE in any way shape or form. It is merely improving the ability of OPAQUE to be extended for the things that want to use it.

2/ you want to negotiate/specify somehow the KSF configuration. but i say this is not necessary! because the server (in the IRTF CFRG specified version) does not now or care about the clients KSF config. hell everything would work totally fine, if all clients would use different KSF configs with the same server.

How does my phone know the parameters that my computer has used to register? Every user can use their own KSF config on the same server. But not every client. Very, very far from it.

And as I see it, there are only really two options for this. One of them is somewhat stupid, and the other one is sending authenticated KSF parameters to authenticating clients.

[stef]

snipping the what is channel binding part, which as a concept i misunderstood.

So, I think I know what the misunderstanding is. Channel Binding is used in the specific case where you have an already-established secure channel, and after establishing this secure channel perform some sort of authentication that validates this secure channel. This is not debatable, this is the definition of the term Channel Binding in the context of SASL. If you do not have this case, you can not have Channel Binding.

Notably, to drill this down again, if you use SASL to establish a secure channel you can not use Channel Binding to bind to that particular channel.

If you perform OPAQUE in the clear, you can not have channel binding.

1. no I'm not thinking about TLS differently. But TLS doesn't magically become the SL of a SASL OPAQUE mechanism, it needs to be specified that way too. And it doesn't help us in the case where we would want to use Channel Binding, see above.

well, we do think differently of the application of tls here. but it doesnt matter, yes if used as an SL it needs to be specified for doing so.

2. No we can not drop KE3. The AEAD in use in modern TLS are not key committing, the fact that we can decrypt packets is not enough for strong authentication.

yes we can. believe me, my implementation was the target of the awesome particioning oracle paper, and thus i understand the concept of key committing and the consequences of it. (note that the paper authors had to circumvent my defense in depth measures to mount their attack against my implementation, but they called it a memory safety bug.) so the thing is, since opaque used hmac for authenticating the "envelope" it is keycommitting, and if that hmac fails then opaque fails and no key is being used in poly1305 (which is the part that is non-key committing, not xchacha20). if the hmac succeeds, then it doesn't matter if poly1305 is key committting or not.

In this specific use case, as the session key is unique per authentication, you could use the TLS PSK_KE mode which almost directly derives the master secret from the provided PSK, without losing forward secrecy. Using Early Data it also allows you to immediately use the TLS context without having to wait for the answer from the server.

that sounds quite nice, no?

Let's do an example. I'm doing IMAP by the book using STARTTLS. The first round-trip goes to IMAP EHLO, the second and third to STARTTLS handshakes, and the fourth for 'AUTH EXTERNAL'. I am now authenticated.
Next example. I'm doing IMAP with SASL OPAQUE with a security layer established by that. The first round-trip again goes to IMAP EHLO, the second and third however go to 'AUTH OPAQUE'. I am now authenticated and have established a security layer.
Now, last example. I'm doing IMAPS using TLS-OPAQUE. The first and second round-trip go towards TLS-OPAQUE. If I have a fancy IMAP implementation I am immediately authenticated with no further actions necessary. If not, I may need a third roundtrip for 'AUTH EXTERNAL'. However depending on how TLS-OPAQUE is done the server may also be able to already send the IMAP EHLO in the first round-trip using the (not yet verified) session key, in essence sending the IMAP EHLO directly after KE2 without waiting for the client answering with KE3. The client may also send its first IMAP commands directly after KE3 since it could decrypt the IMAP EHLO sent after KE2.

it is totally ok for the server to send data already together after KE2, but the client can only process that data if KE2 authenticates correctly.

Notably, none of this early data shenanigans of the last example is possible with a SASL security layer. If you need to keep round-trips to an absolute minimum, TLS-OPAQUE is the way to go.

yes. and it also eliminates the need for any sasl, which is also cool.

Right, you probably know that XChaCha20/Poly1305 too has usage limits. They are designed to be high, but they do exist. TLS implementations rotate their traffic keys quite regularly. Yes, the usage limits of XChaCha20/Poly1305 are high enough that most prolonged usages are safe enough but the question of "is it safe?" quickly becomes one of "what's your threat model" and I do not want to write out a threat model in an SASL RFC.

xchacha20 has a 196 bit nonce, which was chosen to be so large to make it practically impossible for it to ever loop around. and thus the "is it safe?" question is a very-very theoretical one.

anyway i was thinking of your two goals:
1/ channel binding to an existing tls session over which you run sasl (using perhaps opaque) 2/ KSF configuration
i don't think the original IRTF CFRG opaque spec needs any changes, both of these goals i think are simply achievable.
1/ you want channel binding, so opaque itself authenticates the peers, which is ok, but you also want to authenticate the channel. so you just do an extra hmac with the shared secret over the channel parameters on the server before returning KE2, and the client can verify this hmac by recalculating the value itself. note this only binds the channel for the client, if you also want to bind this for the server we need to send back a similar but different hmac to the server together with KE3. you don't modify the OPAQUE base spec at all, and you get what you want.

I could do that, yes. But I could also skip that extra HMAC and then also wouldn't be forced to violate Section 6.2.4. of the OPAQUE spec saying, and I quote, "[The ServerFinish function] MUST NOT return the session_key value if the client authentication material is invalid".

hmm. that is curious, i'm very intimate with opaque, and the original paper does not have this limitation. in fact also during drafting of the opaque spec we had lots of discussions of sending extra protocol data already from the server with ke2, with an extra key, but then we threw away that extra key, saying that extra data can also be sent just with the session key itself. hmmm. gotta dig that up, why this requirement is now there.

So no, if anything I could send it from client to server in the last message, i.e. next to KE3.

yes, if it turns out that requirement is indeed necessary then yes.

But again, I could also use the MAC that is already there for this specific purpose. Which, IMO, makes just slightly more sense.

if it would be there for this specific purpose it would allow extra parameters, wouldn't it?

i mean OPAQUE is a base primitive upon which a lot of other protos will be (hopefully) built we can try to accomodate all of them and bloat opaque up, or we can actually build upon it, extending it like the above. granted, you have 2 (or 4) more hmac calculations per connection. on the client this makes absolutely no performance difference, and considering the cost of doing all the elliptic curve stuff on the server one or two extra hmacs don't mean much of a difference either.

The change I am proposing does not bloat up OPAQUE in any way shape or form. It is merely improving the ability of OPAQUE to be extended for the things that want to use it.

i didnt mean you bloat it up, i meant that accomodating all possible uses of opaque and incorporating all their special needs would do so. it's quite a difference, don't take this as any offense please.

2/ you want to negotiate/specify somehow the KSF configuration. but i say this is not necessary! because the server (in the IRTF CFRG specified version) does not now or care about the clients KSF config. hell everything would work totally fine, if all clients would use different KSF configs with the same server.

How does my phone know the parameters that my computer has used to register?

i guess by presenting a drop down menu with a reasonable default, and a bunch of hardcoded extra configs like yolo and paranoia? and storing that info if it turns out correct. this is something that should be solved by a UI i think, and most people should just stick with the default anyway, so i guess config file/cli parameter is enough for the 1%. and it's not like you can easily change the KSF config, you need to reregister if you wanna change it, that is also kind of a pain.

Every user can use their own KSF config on the same server. But not every client. Very, very far from it.

true, i meant to write users, not clients.

And as I see it, there are only really two options for this. One of them is somewhat stupid, and the other one is sending authenticated KSF parameters to authenticating clients.

ok, and what is wrong with: ksf config simply signed by the servers longterm key and sent along with ke2?

[stef]

ok, and what is wrong with: ksf config simply signed by the servers longterm key and sent along with ke2?

and the client can just cache the value if it turns out the config sent is correct.

[stef]

hmmm, maybe not, not sure if the longterm server key is already available to the client before opening the envelope. the spec has gone quite far from the original paper, and it's kinda confusing with all the changes and back-and-forth over the last years that were put into the draft.

[dequbed]

At this point I have nothing to add to this issue. If there are more comments on the original topic feel free to add them.