Re: [kitten] Merging ideas: Renegotiate, TLS-PSK, Key Derivation

[Alexey Melnikov <[e-mail]>]

Hi Rick,

On 18/01/2023 09:42, Rick van Rein wrote:
> Hi,
>
> The ideas presented yesterday sort-of melted together in my mind.
>
> The idea of renegotiation came up, and I wonder if that is specific
> to one SASL mechanism, or could be a general mechanism that can be
> offered for the second round.
I am thinking that renegotiation should work with most "modern" SASL 
mechanisms.
> Likewise, TLS-PSK expects integration with TLS from the application,
> but that is not necessarily impossible; the classical Security Layer
> also integrated into the application.  The SASL layer may facilitate
> by stating that a TLS-PSK key injection will be done (perhaps by
> flagging it as a mechanism that should never be selected).
>
> Both would benefit from the gut feeling I presented, that is key
> derivation based on SASL secret/entropy, which might be defined
> for OPAQUE and is in Section 2.7 of SXOVER-PLUS.  We should think
> carefully if key derivation may be retrofitted on other mechs when
> these facilities/mechs are offered.
I think adding it to SCRAM would be a good idea. I consider CRAM-MD5 and 
DIGEST-MD5 to be legacy SASL mechanisms, so I wouldn't bother extending 
them.
> I suppose the one thing to be careful about would be the timeout
> for the facilation of renegotiation; perhaps mechnames should
> somewhat like
>
> 	TLS-PSK-300      REPEAT-300
> 	TLS-PSK-3600     REPEAT-3600
> 	TLS-PSK-86400    REPEAT-86400
>
> to indicate the maximum client dependency time and the minimum
> server acceptance time.
>
> Would this make sense?

I have a mixed feeling about time limits being advertised in mechanism 
names. I think I would prefer to have a single (or maybe 2) SASL 
mechanisms and advertise the expiration limit inside the mechanism exchange.

Best Regards,

Alexey