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
