Re: which is our DIGEST-MD5 successor?

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Tom Yu <tlyu@xxxxxxx> writes:

> We have had several password-based SASL mechanism proposals submitted
> to the WG for the purpose of replacing DIGEST-MD5.  Much of our
> discussion has centered on SCRAM, but I would like to make sure that
> we have consensus behind SCRAM and that all proposals presented to us
> have been adequately considered.
>
> I believe the HEXA proposal has been merged into SCRAM.  Simon
> Josefsson has also submitted a password-based mechanism.  During
> IETF70, I had misunderstood Simon's intention with this document and
> believed that he was withdrawing it.  Simon has since stated that he
> intends to continue pursuing his document.  The document remains
> expired, as far as I can tell, so this may not be relevant anymore.
> (Simon, do you intend to renew the document?)

Let me clarify: given that there weren't much interest from the SASL
community, I didn't think there were any point in describing the SASL
mappings of the GSS-API mechanism that my document specifies.  I may
have said that I would retire that part of the document.  My intention
is still to pursue the rest of the document as a normal GSS-API
mechanism.  I always wanted it possible to use the mechanism with GS2,
and when implementing I would probably use that as the first test case.

I do intend to pursue the GSS-API mechanism part of that document, but
alas haven't had time to implement it yet.  My document doesn't
necessarily have to be an IETF document though.  If SCRAM evolves into a
GSS-API mechanism, I would consider to use that instead, and drop my
proposal.  Or we could merge SCRAM and my draft, if people can agree on
the design.  My requirements are that it should be a GSS-API mechanism
and that it should use hashing, and not be specific to the SASL context.
I don't think I have other strong requirements.

A SASL-specific password-mechanism is likely to be simpler than a
GSS-API mechanism from a specification complexity point of view.  If
people want a dead simple SASL password mechanism specification that do
not mention GSS-API, I don't think that approach is compatible with my
goals.  Then we'll end up with two solutions for these two different
goals.

> I think Chris Newman said during the WG session at IETF70 that he
> believed there was nothing in Simon's document that was not in SCRAM,
> apart from a few paragraphs about making the protocol consistent with
> GS2.  I later realized that Chris is listed as an author of SCRAM, and
> would like additional opinions.

SCRAM isn't a GSS-API mechanism, as far as I know, so it fails the first
criteria I had when writing my password-auth document.  I must admit
that I haven't reviewed SCRAM since it was initially discussed.  Where
can I find the latest SCRAM document?

For reference, the latest version of my password document is available
from <http://josefsson.org/password/>.

/Simon