Bug in SCRAM implementation
tmolitor-stud-tu opened this issue · comments
RFC 5802 section 5.1 (last bullet point) states:
Unknown optional extensions MUST be ignored upon receipt.
Only mandatory options should result in an error, if unsupported by one party. To quote the RFC again:
Mandatory extensions sent by one peer but not understood by the
other MUST cause authentication failure (the server SHOULD send
the "extensions-not-supported" server-error-value).
The bug is here:
Line 97 in 9b926aa
Example of an optional attribute that should be ignored by ejabberd:
p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6,d=deadbeef
Example of a mandatory attribute that should result in an unsupported_extension error:
p=tls-exporter,,n=user,r=12C4CD5C-E38E-4A98-8F6D-15C38F51CCC6,m=deadbeef
Thanks, did miss that, will add that.
This should be fixed by 807fc73
Looks good.
Another possible bug: an m= attribute in the client-final-message (step = 4 in your code) should also generate an error response.
@prefiks: Have you seen the last comment from @tmolitor-stud-tu?
Yes, i added that as well