[sasl] [Technical Errata Reported] RFC5802 (2652)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC5802,
"Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5802&eid=2652

--------------------------------------
Type: Technical
Reported by: Jehan Pagès <[e-mail]>

Section: 7

Original Text
-------------
   base64-char     = ALPHA / DIGIT / "/" / "+"

   base64-4        = 4base64-char

   base64-3        = 3base64-char "="

   base64-2        = 2base64-char "=="

   base64          = *base64-4 [base64-3 / base64-2]

Corrected Text
--------------
   base64-char     = ALPHA / DIGIT / "/" / "+"

   base64-4        = 4base64-char

   base64-3        = 3base64-char "="

   base64-2        = 2base64-char "=="

   base64          = *base64-4 (base64-4 / base64-3 / base64-2)

Notes
-----
The original version would allow the empty string (hence the base64 encoding of an empty string). Though it may technically be an acceptable base64 encoded string, it is not acceptable in our use as we use it for security features which are not supposed to be empty (though it is not defined this way, but common sense tells).

This formal definition added to the fact there is no textual counter-indication would imply it is authorized to generate for instance an empty salt, salt being formally defined as:

salt            = "s=" base64

And textually (section 2.1):
"Salt: A random octet string that is combined with a password
      before applying a one-way encryption function.  This value is used
      to protect passwords that are stored in an authentication
      database.
"

Other uses of base64 (proof, verifier and channel-binding) are less problematic as they are encoding of formerly exchanged data (hence if empty, it would fail the exchange). But salt being generated by client and server, the current definition would authorize an obviously faulty random salt-generation behaviour.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5802 (draft-ietf-sasl-scram-11)
--------------------------------------
Title               : Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms
Publication Date    : July 2010
Author(s)           : C. Newman, A. Menon-Sen, A. Melnikov, N. Williams
Category            : PROPOSED STANDARD
Source              : Simple Authentication and Security Layer
Area                : Security
Stream              : IETF
Verifying Party     : IESG