draft-josefsson-password-auth-00.txt

[Nicolas Williams]

> I.e., we could merge YAP and the other proposals into one generic
> mechanism.

Very, very roughly, primarily to illustrate the context token exchanges:

IDi = initiator name
IDt = target acceptor name
IDa = acceptor name (like IDt, but asserted by the acceptor)
S   = salt derived from IDt or IDa
K   = PBKDF2(password || S, iteration)
R1  = response_function(K, [challenge] || channel bindings || [cnonce])
R2  = response_function2(K, R1)

1/2   rt (   channel bindings and no mutual auth)
    I -> A:  IDi, [IDt,] R1

1     rt (   channel bindings and    mutual auth)
    I -> A:  IDi, IDt, R1
    A -> I:  R2

1 1/2 rt (no channel bindings and no mutual auth)
    I -> A:  IDi, [IDt]
    A -> I:  IDa, challenge
    I -> A:  nonce, R1

2     rt (no channel bindings and    mutual auth)
    I -> A:  IDi
    A -> I:  IDa, challenge
    I -> A:  nonce, R1
    A -> I:  R2

A target name is needed so the acceptor's verifier can be a weak
password equivalent (meaning it's a password equivalent only for
authenticating to the same acceptor).  Therefore it's useful to
have a target name even when mutual auth is not requested.

A target name is required for mutual auth, of course.

The 1 1/2 rt version could add DH key agreement for PFS.  And the 2 rt
version could add DH key agreement for PFS and some privacy protection
of IDi.  That is probably not worthwhile for any SASL application, since
they tend to have STARTTLS-type options, and for GSS one could always
add PFS with stackable mechanisms.

Nico
--