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.
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.
FWIW, I'd leave out most of the first sentence here; protocol binding is more implementation detail than requirement.
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).
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?
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?
Overall, that's quite an ambitious list, and I'm very curious to see how much any effort will attempt to bite off.
One other thing;
CARRIED NONCRYPTOGRAPHICALLY INSIDE HTTP
One approach that comes up quite a bit is to just embed
authentication tokens (typically generated by an IdP) in
the HTTP messages that go from the user to the RP (DIX is
an example of such a scheme). In this system, the tokens
themselves are "bearer"--they enable any holder to impersonate
the user. In order to protect against token capture, the tokens
are generally made specific to the RP, so that one RP can't
use them to impersonate the user to another.
An additional issue is hijacking: without cryptographic
binding, an attacker who observes a request can make future
requests in the name of the user via a cut-and-paste attack
(remember, the token is bearer). If you take the threat of
this type of attack seriously, you need to run the traffic
over SSL/TLS. [1]
The primary attraction of this kind of design is that it
may be implementable without changing the client software
at all (again, see DIX). Many people see that as important
for deployment.
It sounds like one interesting discussion would surround what people's tolerance for these attacks is, and ways to mitigate them.
