Hi All, My specific solution is to simply include a *different* fixed string for each variant of SCRAM and GSS-API, and ideally a nonce. Given that applications will have to update their stacks anyway to accommodate the new fixed string in the current proposal I don't see that as a hugely difficult proposition.
The goal of labels in material that is used to derive keys (yes, material that is used to derive keys is necessarily secret, yes material derived from keys is not necessarily secret), is to exclude classes of attack. It is good protocol design. One of the things use of a TLS channel binding gives you is protection for the upper level protocol against TLS being MITMed. Using a fixed string for multiple protocols probably gives you that protection (assuming the channel binding is correctly agreed by both sides). Using a distinct channel binding, even if the upper level protocol is not secure, means that if both sides agree on the channel binding they agree on the intent of the upper layer protocol, i.e. it gives you some level assurance that the client and server agree on what was intended. This eliminates classes of attack such as message confusion. Adding this protection costs virtually nothing, given that you are _already_ commiting to updating this section of code (no code currently makes this specific call to the TLS-Exporter interface). Leaving it out means that people like me who do formal analysis can't reasonably analyse these designs. I build models of protocols and prove they meet certain properties. The only way to keep that analysis viable (we're already talking hundreds of hours of work) is to eliminate classes of attack wholesale. Yes, you can add unique and clever protections into every sub-protocol, but it makes formally proving anything about the security exponentially harder (and yes, I mean that in the literal / mathematical sense). Regards, Jonathan On Tue, 9 Nov 2021 at 13:00, Dave Cridland <[email protected]> wrote: > On Tue, 26 Oct 2021 at 17:33, Jonathan Hoyland > <[email protected]> wrote: > > There isn't even a one-to-one relationship between GSS-API / SCRAM runs. > This channel binding design doesn't protect against messages being swapped > between two GSS-API runs on a single TLS connection. > > As I understand your case, you're suggesting that if the same channel > binding is used on multiple authentication runs within the same TLS > session, there may be cases where this may result in weakening of the > bound authentication. > > It is not clear to me that this is the case. The channel binding data > is known to both parties of the TLS session for the duration of the > TLS session, so it doesn't seem likely that reusing it could actually > cause problems here. > > Most SASL or GSS-API based protocols do not allow multiple > authentications within a single connection, and therefore TLS session, > but there are exceptions. > > I think the exceptions are: > * IMAP with draft-newman-imap-unauth - a three year old I-D not > published as an RFC. > * LDAP (and X.500 DAP) both allow multiple consecutive binds. > > The suggestion you propose in the quote above is that a single message > could be replayed within one TLS session. > > Replay resistance is generally baked into SASL and GSS-API mechanisms, > rather than the channel binding itself. This includes, for example, > SCRAM - replaying one of the messages would result in a failed > authentication whether or not TLS channel binding were to be used. > Some mechanisms are replayable - PLAIN being one - but these both > assume that the TLS session remains confidential, and also they do not > include channel binding information anyway. But there are SASL > mechanisms that have been proposed in the past that do not provide > replay resistance but do include a TLS channel binding. In these > cases, then, your attack is possible and hinges on the reuse of a TLS > channel binding. > > The result would be that - on some IMAP and LDAP servers - an > authenticated user could reauthenticate as themselves. > > Now, all this does assume that an attacker cannot break a TLS session > during the duration of a TLS session; that is, that we assume TLS > sessions maintain confidentiality, integrity, and authenticity during > the session at least. If this is not the case, then it's game over > anyway, on a number of levels, and your proposed attack (which, I > reiterate, is entirely unproven) makes no difference. > > What we do not assume however is that the certificate remains > sacrosanct during this. Again, SASL mechanisms often (and again, this > includes SCRAM) handle their own mutual authentication, so not only > does the client authenticate to the server but the server has to prove > its identity to the client. Assuming ephemeral keying, then, an > attacker compromising the server's certificate doesn't actually make > as much difference as you'd think here. At this point I'm reaching the > edges of my knowledge, but I believe that although the identity as > authenticated by the server's certificate could be spoofed if the > certificate were compromised, ephemeral keying would still protect the > session and SASL mutual authentication would still authenticate the > server later. > > Overall, therefore, I have to ask you to find some kind of concrete > attack. "Reusing an exported key within the same TLS session" does not > appear to form the core of an attack as you suggest. > > Dave. >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
