[Date Prev][Date Next]
Re: Authentication issues (Re: authmeth review notes [long])
While I do not agree with many of your points (and could argue
them point by point), I'd like to refocus this discussion on
the offered text and how it could be word-smithed to be more
consistent the consensus already reached on a number of issues
in this area.
>>>> s/more passwords/more passwords, each an OCTET STRING,/
>>>> s/compare/compare in an octet wise/ [as clarified]
is, I agree, problematic. Mainly because it implies that the
each of the stored values is an OCTET STRING. I also did
not intend to disallow use of various hash functions (or even
other functions such as U-Mich's ces) to be used in comparisons.
I do believe consensus did support changing the TS to allow
such (if it could be done in a reasonable manner).
My intent was more to clarify that the presented value is an
OCTET STRING and servers must be prepared to handle (but
not necessarily support) arbitrary content of this protocol
field. While mostly a protocol issue, because of past problems
in this area, I think it something which [authmeth] should
at least hint to (and clarification to the earlier part of
this section should be sufficient).
Additionaly, as we discussed before, there are a number of
limitations on the kinds of password storage mechanisms that
can be used. In particular, one's which require recovering
user input before application of SASLprep. This likely can
be handled as a note to implementors.
To more this forward, I will shortly offer new changes for
the WG to consider.