Heikki,
Like these proposals in general.
* Heikki Linnakangas (hlinnakangas@vmware.com) wrote:
> For future-proofing, it would be good to send the
> number of iterations the hash is applied as part of the protocol, so
> that it can be configured in the server or we can just raise the
> default/hardcoded number without changing the protocol as computers
> becomes more powerful (SCRAM does this).
wrt future-proofing, I don't like the "#-of-iterations" approach. There
are a number of examples of how to deal with multiple encryption types
being supported by a protocol, I'd expect hash'ing could be done in the
same way. For example, Negotiate, SSL, Kerberos, GSSAPI, all have ways
of dealing with multiple encryption/hashing options being supported.
Multiple iterations could be supported through that same mechanism (as
des/des3 were both supported by Kerberos for quite some time).
In general, I think it's good to build on existing implementations where
possible. Perhaps we could even consider using something which already
exists for this? Also, how much should we worry about supporting
complicated/strong authentication systems for those who don't actually
encrypt the entire communication, which might reduce the need for this
additional complexity anyway? Don't get me wrong- I really dislike that
we don't have something better today for people who insist on password
based auth, but perhaps we should be pushing harder for people to use
SSL instead?
Thanks,
Stephen
