[dix] Re: [Ietf-http-auth] New draft on anti-phishing requirements

[Sam Hartman <[e-mail]>]

>>>>> "Eric" == Eric Rescorla <[e-mail]> writes:

    Eric> 1. This is not principally a protocol problem but rather a
    Eric> UI problem.  The protocol problems are generally well
    Eric> understood. If the UI problems are solved, nearly any
    Eric> protocol will work. In particular, there have been a number
    Eric> of published designs [1] [2] that have mostly adequate
    Eric> (though not perfect) protocols, though without complete

I agree with you that this is not principally a protocol problem.  I'm
not sure I agree that this is principally a UI problem; I think it is
principally an architecture problem where you need the UI and protocol
to cooperate.

I also believe that as you point out, the protocol problems are mostly
solved.  I do think there is still work to do on getting a protocol
that is easy to deploy and that for example deals with enrollment,
etc.


    Eric> 2. It's really important to distinguish between different
    Eric> levels of attack.  Conventional phishing attacks rely on
    Eric> generating a reference which appears to be valid but
    Eric> actually points at the attacker's site. (This is why SSL/TLS
    Eric> doesn't help much).

    Eric>    But this is different from attacks in which the attacker
    Eric> actually intercepts the user's communication. In these
    Eric> settings, some sort of cryptographic protection for the
    Eric> channel (a la HTTPS) or the messages (a la S-HTTP) must be
    Eric> provided.

Are there specific places in my document where you believe the distinction is critical?

    Eric>    On a similar note, in current phishing attacks the
    Eric> attacker attempts to directly extract the user's
    Eric> password. If C-R mechanisms are used, a dictionary attack is
    Eric> natural. I assume that's why you wave in the direction of
    Eric> ZKPPs in S 4.3. However, it's worth asking whether we would
    Eric> be satisified with a system that was only partly
    Eric> strengthened against dictionary attacks (see [2] again).

Yes, probably.  I think we'd be satisfied with many things better than
what we have:-) I think we'd like to get a ZKPP, but I think we have
no reason to assume the IPR situation will be any better with this
effort.

    Eric> 3. The term "password equivalent" is a bit confusing. See
    Eric> draft-iab-auth-mech for some discussion of strong versus
    Eric> weak password equivalent.

Your IAB draft seems to be focusing on what is stored rather than on
what is transported in the protocol.  I don't have a problem if a
server stores a weak password equivelant, but I do have a problem if
the server stores or even receives a strong password equivelant.

    Eric> 4. I agree that server authentication is a good, but I'm not
    Eric> totally sold that it's a necessity. 

I will work on selling you or revising my position.
    Eric> 5. You write:

    Eric>    The risk of dictionary attack is always a significant
    Eric> concern for password systems.  Users can (but typically do
    Eric> not) minimize this risk by choosing long, hard to guess
    Eric> phrases for passwords.  The risk can be removed once a
    Eric> password is already established by using a zero-knowledge
    Eric> password protocol.

    Eric> This is not strictly true. A ZKPP removes the risk of
    Eric> offline dictionary attack, but not online attack. These
    Eric> attacks do still get mounted [3]

Yes, and I even know that:-) Thanks for pointing out that I was being
sloppy.  Will fix.

    Eric>    However the risk of dictionary attack is always present
    Eric> when setting up a new password or changing a password.
    Eric> Minimizing the number of services that use the same password
    Eric> and being extra careful to make sure the right server is
    Eric> used when establishing a password can minimize this risk.

    Eric> It's not clear to me that this helps, unless you're assuming
    Eric> a ZKPP.  If the attacker can capture a 
    Eric> hashed password or
    Eric> C-R handshake (which a phisher can generally force in
    Eric> non-ZKPP cases) then they can mount an offline dictionary
    Eric> attack anyway. Consider a typical design where the user has
    Eric> a master password P and then generates per-site passwords as
    Eric> H(Site-Name || P). In the C-R handshake, the user provides:

    Eric> H(challenge || H(Site-Name || P).

    Eric> Dictionary attacking this isn't significantly harder than
    Eric> dictionary attacking H(Site-Name || P).

I'm not sure what you meant by this above.  If you mean using
different passwords, I meant using different master passwords.  I
believe that actually does help.  But I was assuming a ZKPP in that
paragraph, and I believ in the ZKPP case, contacting the right server
does help.  I will update the text.


    Eric> 6. You write:

    Eric>    In situations where there is an identity provider that is
    Eric> separate from the website as a relying party, additional
    Eric> requirements are needed.  The identity provider MUST verify
    Eric> that the website is a valid relying party for this identity.
    Eric> Some identity providers will allow anyone to accept their
    Eric> identity.  However particularly for financial institutions
    Eric> and large service providers it will be common that only
    Eric> authorized business partners will be able to accept the
    Eric> identity.  The confirmation that the the relying party is
    Eric> such a business partner will often be a significant part of
    Eric> the value provided by the identity provider, so it is
    Eric> important that the protocol enable this.  The relying party
    Eric> MUST prove its identity is the one expected by the identity
    Eric> provider.

    Eric> I agree that this is is a likely business goal for identity
    Eric> providers, but it's not required for protection against
    Eric> phishing. Really, there are two interests here:

    Eric> 1. To prove to the user (the guy with the browser) that he
    Eric> is doing business with an "authorized" provider.  2. To
    Eric> allow the identity provider to extract rents from the
    Eric> relying parties.

    Eric> Neither strictly requires the relying party authenticating
    Eric> to the identity provider during the transaction. The first
    Eric> can obviously done by issueing the relying party a long-term
    Eric> credential. The second can be done by encrypting the
    Eric> credential under the relying party's key. You don't
    Eric> necessarily need the identity provider to receive a proof
    Eric> that the relying party was able to decrypt it.

I don't believe that my requirements would require that the relying
party talk to the identity provider.  I believe that assuming a
reasonable set of trust anchors, having the web browser ask the
identity provider if the dnsname is allowed to accept the identity.
That provides a protocol hook allowing the identity provider to meet
the requirement that it MUST confirm the relying party is a valid
relying party for the identity.  If the relying party later proves
that it has a trusted certificate for this identity it meets the
second requirement.

Can you suggest clarifications to the text?


    Eric> -Ekr

P.S. Thanks for the references.

--Sam

_______________________________________________
dix mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dix