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

[Rick van Rein <[e-mail]>]

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.

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 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?

-Rick