Re: scram-sha1 does not tolerate newline characters

[Simon Josefsson]

Lothar May <address@hidden> writes:

> Hi,
>
> I was desparately trying to test the gsasl scram-sha1 authentication
> within our project with a Java test case (own implementation since I
> could not find a lib [1]). I kept getting authentication failures. After
> several hours, including stepping through the gsasl code, I still could
> not see any difference. Finally when switching to hex ascii view I could
> see it:
>
> If the client response to the server challenge is terminated with a "\n"
> newline separator, this leads to authentication failure, even if
> everything else is correct. However, I can add a newline to the first
> client message, if I also add it to client-message-bare in the second
> auth step (which kind of feels wrong, because newline characters should
> not be part of the nonce, see rfc "c-nonce         = printable").
>
> Maybe gsasl could be a bit more tolerant in this regard, as this is a
> text based protocol, and if you test it on the terminal then newline
> characters will be added.
>
> But if this is by design, then it was just my fault not checking
> earlier, sorry, I don't mean to rant, I'm just a little frustrated
> because I lost so much time on this.

This is by design -- I try to validate the input against the ABNF firmly
(although there are some weak spots).  I believe the SCRAM
specification, and in particular the ABNF spec, is clear that additional
white space is not permitted.

Sorry you lost time on this, I'm not sure how to improve things here --
ideas welcome.

/Simon