On 2006/06/23, at 3:29 PM, Eric Rescorla wrote:
1. Capture-Resistant Credentials (CRC)
Credentials which are designed so that if you authenticate
to relying party (RP) X, X cannot use them to impersonate you to
RP Y
(even if your intention was to go to Y). Phishing is based
on the fact that passwords do not have this property.
The rationale for this feature is to make phishing-type
attacks difficult.
This is a bit confusing; to me (disclaimer -- I'm just a layman, not
a security expert), phishing is based on confusing the user about the
RP's identity, not reusing credentials from RP X with RP Y. Of
course, if you enable Common User Credentials, phishing will be
possible in this manner.
I see what you mean here, but let me try to explain what I'm
talking about and see if you still disagree with my taxonomy.
In a classic phishing attack, the attacker convinces you
to authenticate to them under the impression (in between
your ears) that you're authenticating to someone else. For
concreteness, say that the Phishing site is spoofing Citibank
and the Phishing site has domain name C1tibank.
The reason this works is that the authentication token that
your software sends to C1tibank (your password) is the same
as the token it sends to Citibank. In systems where these
are separated (e.g., Boneh's PwdHash) then phishing attacks
don't work. You can capture an authentication token but
you can't re-use it to impersonate the user to the real RP.
Part of the problem is that the user and the software have
a different view of the RP's identity. The software knows that
C1tibank and Citibank are different, but the user does not.
Fair enough.
Would it be correct to say that HTTP Digest Auth has this property
alreadly (because A2 includes the digest-uri-value)? There are other
attacks that can be made against Digest, of course (e.g., dictionary
against weak passwords), but it's interesting to think of it as
having anti-phishing properties.
With that in mind, I wonder if this is much different from...
2. Hijack-Resistant Authentication (HRA)
An authentication system in which credentials which are bound to
protocol messages in such a way that attacker who observes the
credentials can't use them to authenticate messages of their
choice. The rationale for this feature is to make cut-and-paste
attacks difficult.
To take a concrete example here, PwdHash is susceptible to
hijacking attacks (do ordinary connection hijacking) if SSL/TLS
is not used but is not susceptible to straight phishing attacks.
So, I don't think these are different.
Did you mean you *do*?
11. Private Authentication (PA)
Some third-party authentication systems require an interaction
with the 3rd party for each authentication. In some such systems,
the 3rd party knows the relying party for each authentication
and the claims which were asserted. PA means that the 3rd party
does not get that information. The rationale for this feature
is to protect the user's privacy from the 3rd party.
I *think* this is saying that there's a requirement to separate the
identity from authentication, so that a 3rd party site doesn't learn
any details about the user at all (e.g., userid, password, name, e-
mail, etc.), but only is given the ability to act on their behalf in
certain cases.
Do I have that right, or is this something else?
That's not what I had in mind, though it's another interesting
property.
See also: http://www.w3.org/2005/Security/usability-ws/papers/32-dean-
auth-for-web-services/
What I meant was that the 3rd party doesn't find out
what sites you're visiting and what credentials you proved
to them; that way if Yahoo is my identity provider they
don't find out what kind of porn sites I visit.
Ah, so it goes both ways...
Thanks,
--
Mark Nottingham
[EMAIL PROTECTED]
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
