Re: [kitten] Requesting WG adoption of several SCRAM related documents

On 04/11/2021 12:06, Sam Whited wrote:
> Having reconsidered this in light of some of these comments, I think I
> agree in terms of SCRAM-SHA-512 and SCRAM-SHA3. While I'm certainly not
> *against* publishing these mechanisms (as I mentioned, I have
> implemented them and used them already in some places) I do think SCRAM-SHA-
> 256, for example, is likely strong enough for now.
I am happy to defer decision on bringing them into the WG till a later date.
> It doesn't show any
> signs of weakness, so we might want to focus on a mechanism that has its
> own hash/CB negotiation instead and is extensible enough to add 2FA
> later (or whatever other requirements this group comes up with: better
> hash agility comes to mind). I suppose I've changed to being neutral on
> publishing the new SCRAM mechanisms.
>
> As for the 2FA document I think that represents something that's missing
> from *current* mechanisms and should likely move forward. If we were to
> focus on new mechanisms that could implement 2FA I think we'd be doing a
> disservice to existing SASL/SCRAM users who may not be able to evaluate
> and update to a new mechanism, but may be able to add 2FA to their
> existing setup more quickly.

I feel the same.

So my update proposal is to work on the following in the WG:

1) SCRAM 2FA extension

2) Something like draft-cridland-kitten-clientkey for SASL 
re-authentication that can be used with SCRAM or similar mechanisms

3) A possible informational document about best SASL implementation 
practices, in particular how to deal with some SASL mechanisms only 
being available for some users.

Best Regards,

Alexey

> —Sam
>
> On Wed, Nov 3, 2021, at 16:31, Simon Josefsson wrote:
>> 3 nov. 2021 kl. 17:43 skrev Robbie Harwood <rharwood@redhat.com>:
>>> Simon Josefsson <simon@josefsson.org> writes:
>>>
>>>> Hi.  I'm not strongly opposed to these work items, but I do feel
>>>> publishing these documents without adressing high-level concerns
>>>> have a risk of causing problems during deployment.  I think the WG
>>>> should understand and consider the implication before adopting the
>>>> documents
>>>> - maybe there is alternative work that needs to happen
>>>>    before/instead.
>>> Hi Simon, do you have any further thoughts on this in light of
>>> Ruslan's and Alexey's comments in reply?
>> No.  I agree with what the replies, and haven’t changed my opinion.
>> I’d rather see work on addressing the problems that were brought
>> up, or stronger mechanisms, instead. But things aren’t a zero-sum
>> game, so if enough people wants these drafts published, that’s what
>> will happen.
>>
>> /Simon
>> _______________________________________________
>> Kitten mailing list Kitten@ietf.org
>> https://www.ietf.org/mailman/listinfo/kitten