>>>>> "Eric" == Eric Rescorla <[EMAIL PROTECTED]> 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
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
