Mark Nottingham <[EMAIL PROTECTED]> writes: > Eric, > > This is excellent -- very helpful. I agree WRT the lack of a common > view of requirements. > > A few comments / questions below. > > On 2006/06/19, at 2:59 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. > 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. > FWIW, I'd leave out most of the first sentence here; protocol binding > is more implementation detail than requirement. Fair enough, but I think it needs to be inverted to make the requirement clear. >> 7. User-Friendly Names (UFN) >> The ability to prove possession of some non-random-appearing >> name. The reason to separate this out is that one natural >> way to provide CI is simply to generate some random asymmetric >> key pair and use that (or its digest) as your identity. This >> name is not user friendly. Note that this is the first requirement >> in this list that appears to require a third party (to assign >> the names). The rationale for this feature is that random names >> are hard to remember. > > Well, it requires a third party if you're trying to co-ordinate names > across multiple domains (again, there's an i-built assumption that > there will be CUC). I think mostly true, though even in single-site systems, it's annoying to have to force unique names. >> 8. Assertion of External Claims (AEC) >> The ability to demonstrate some real-world fact about the user >> (e.g., I am a certain age, this is my address, etc.) to the >> RP. The rationale for this feature is that there are contexts >> in which the relying party needs to be able to establish this >> sort of information. >> >> 10. Independent Assertion of Claims (IAC) >> The ability to assert claims independently so that the user >> could (for instance) demonstrate their age to the RP without >> without revealing their address. The rationale for this >> feature is to protect the user's privacy. > > #10 is a sub-case of #8, no? Yes. >> 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. 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. -Ekr _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
