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

[Eric Rescorla <[e-mail]>]

Sam Hartman <[e-mail]> writes:

>>>>>> "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 don't think I agree. Both of the papers I cited above provide
basically acceptable phishing defenses without changing the wire
protocol (they do change the password on the server, of
course). So, you could certainly do better with a protocol,
but I think we have existence proofs that one isn't needed.

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

Well, whenever you're talking about capturing credentials versus
capturing the session. Since non-reusable credentials protect
against credential capture but not against hijacking.

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

Sure.

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

I don't think so because we don't agree on the requirements. My 
point is that the relying party does not need to prove its
authorization to the identity provider in any way
in order to solve the phishing problem. It may be required if
the identity provider wants to charge relying parties, but
even then it can be done without "confirming" as I indicated
above.

-Ekr

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