draft-josefsson-password-auth-00.txt

[Nicolas Williams]

On Thu, Mar 29, 2007 at 03:33:33PM +0200, Simon Josefsson wrote:
> I'm not really that familiar with the naming corners of GSS-API...  In

You need to specify what name types the mech supports and how to convert
from generic name syntaxes (<username>, <service>@<host>) to mechanism-
specific syntaxes (which for a password-based mechanism might be the
identity function) and what mechanism-specific name types exist, their
syntaxes and so on (there wouldn't be any for a password-based mech).
And then there's the exported name token format, which for
password-based mechs should also be trivial.

> any case, how to salt the password is an open question.  Perhaps the

Well, you'd want to salt it with the server's name, so the verifier is
different at each server.  Then again, many sites might object.  So you
might want a two level verifier derivation where the first step is not
salted with the server name and the second is -- then one could
distribute the output of the first step as the verifier for all servers
in a site.

> exported name format can be used as the salt value with PKCS#5 PBKDF2?

Yes.  But there's two names: the client's and the server's.

> But then you'll need to transfer the PBKDF2 iteration counter, or
> (worse) fixate it.  The iteration counter question is the main reason
> why I haven't used PBKDF2 yet.  That, and I'm not sure PBKDF2 in this
> protocol actually protects against any valid security threats.

Either negotiate the iteration count or make it part of the mechanism
name/OID.

Kerberos V uses PBKDF2.  I see no reason why we couldn't use it here.

Nico
--