[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: which is our DIGEST-MD5 successor?
--On Monday, March 10, 2008 11:47:42 PM +0100 Simon Josefsson <simon@xxxxxxxxxxxxx> wrote: 



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 would be very disappointed to see separate password mechanisms for SASL and GSS-API, rather than one mechanism that can be used with either. Producing only a SASL mechanism would fail to meet the needs of GSS-API applications desiring support for password authentication (I would expect those to include NFSv4, though I haven't actually talked to that community).
While meeting the needs of pure GSS-API applications is not part of the SASL WG's mandate, I think we need to consider that there is going to be some demand for such a mechanism, which means it's likely to get done -- especially since Simon is telling us he's going to go ahead with that work whether or not it ends up also being the SASL WG's work product.
So, it seems highly likely there will be a GSS-API password mech. Any such mech would have to go to some effort _not_ to work with GS2, which means that if we also do a SASL-only password mech, then there will be two independent password mechanisms that can be used with SASL. That means we will have duplicated effort in developing those mechanisms, and there will be confusion among users, operators, and SASL application protocol designers and implementers as to which mechanism they should use.
Given all of that, I think everyone is best served by merging Simon's effort with SCRAM and producing a single mechanism which has the best properties of both, including the ability to be used as a GSS-API mechanism and a clear enough specification that it is possible to do a direct-to-SASL implementation without requiring a GSS-API library or an inderstanding of how GSS-API works. 



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/>.
If you're going to continue this effort, I do think you should continue to maintain it as an internet-draft, where it can be easily found. I also think that if the SASL WG ends up deciding to produce a SASL-only mechanism, you should pursue publishing your GSS-API mechanism on the standards-track via the individual submission process (i.e. find an AD to sponsor it). While I would prefer to see a single mechanism that can be used with either framework, I believe that having two mechanisms would be preferable to not having a suitable password mechanism for GSS-API. 

-- Jeff