Hi Marvin, > I think the specification partially exaggerates on what it is able to > actually achieve security-wise. > > The requirements say: "Allow detection of SASL mechanism downgrades > even if no channel-binding is in use.". However, as this is an > extension to SCRAM, it only allows detection of SASL machanism > downgrades to SCRAM (as already mentioned). The detection only happens > after the client-final-message is sent to the server. This means that > if there was any attacke possible because of downgrading to some > version of SCRAM (and because of no channel-binding being used, the > SASL mechanism serves purely as mechanism of providing client > authentication information), this attack would already be possible with > the data in the client-final-message and thus the attack would not have > been prevented. Or in short: This does not provide a protection against > a downgrade of the SASL mechanism, it merely provides detection after > it is too late. That's a wekness of SCRAM itself. Channel-binding problems will be detected after the client-final-message as well. But detecting a downgrade may still be better than not detecting it at all. At least the user could be informed about the downgrade and change her password.
That said, OPAQUE will not have this weakness and adding the same downgrade protection to OPAQUE would detect the downgrade before sending "credentials" to the server. My proposal furthermore protects the list of channel-binding types agains downgrades. See my mail to Daniel earlier today. > The requirement to "allow detection of downgrades of channel-binding > types" is fulfilled - under the assumption that the attacker was not > able to gain access to the credential database of the server or the > user's cleartext password. This means that as long as any of the user's > clients still uses or can be downgraded to use PLAIN, an attacker can > compromise all clients, including those that implement this > specification. Yes, PLAIN is evil and should only be used if it can not be avoided, I answered that already in another mail. > IMO, changing clients to not accept servers claiming to only support > channel-binding that is worse than what they supported previously is > probably better than this specification (and requires to changes to the > server). That way you won't be protected on your first connection. My proposal detects downgrades even on first connection. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
