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

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 <[EMAIL PROTECTED]>

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

_______________________________________________
sasl mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/sasl