After a number of hallway conversations I came to the
following view
on the breaking down the problem and the desirable features:
(I reference Ekr's labels where applicable for sake of
brevity,
included below for convenience)
1A) Phishing of Account credentials - bad guy getting
account name
and password
Desirable solution features are:
Ekr’s CRC, HRA, PC?, CUC, CI? (I am not certain on PC and
CI)
1B) Phishing of Identity attributes - bad guy getting
personal
identifying information
Desirable solution features are:
i) Certainty of website identity (a factor in above, but
since the
user may not have authenticated, it is different)
ii) Secure channel to prevent eavesdropping (solved today
with SSL/TLS)
2) Software Assisted Attribute Exchange - this is having
software
assist the user in the acquisition and presentation of
identity
attributes. The messages to do this include: request,
response, store.
Desirable solution features are:
Ekr’s FPI, CI?, UFN?, AEC, IAC, PA
-- Dick
----------------
From: ekr networkresonance.com
Subject: [Ietf-http-auth] Notes on Web authentication
enhancements
Date: June 19, 2006 2:59:29 PM PDT (CA)
To: dixietf.org, ietf-http-authlists.osafoundation.org
There's obviously a lot of interest in working on various
enhancements
to Web and Web Services applications. Unfortunately, after
reading
the various drafts and mailing list postings produced by the
proponents
of various technologies, I don't come away with the sense
that people
have a common view of what is needed. This message is a
first cut
at a taxonomy of requirements/features and technical
options.
BACKGROUND: THE CURRENT STATE OF HTTP AUTHENTICATION
----------------------------------------------------
HTTP has two native authentication mechanisms, Basic
Authentication
(passwords in the clear in an HTTP header) and Digest
Authentication
(a challenge-response handshake also in the HTTP header).
Both
mechanisms depend on the client proving the possession of a
shared
secret string (a password in all real cases) to the server.
The
server is unauthenticated.
For a variety of reasons, including bad UI on the clients,
nearly
all real-world Web applications use neither mechanism but
rather
use an HTML form to prompt the user for his password. This
password is then sent in the clear over the HTTP connection.
The standard security advice for how to secure this data is
to
use HTTPS (HTTP over SSL/TLS) to encrypt the entire channel
and use the server's certificate to authenticate the
server.
Practical difficulties with checking the certificate have
led
to phishing attacks, in which the attacker gathers the
user's
password and can then impersonate the user. An additional
problem
is that it's hard for Web Services apps (e.g., DAV) to use
this
kind of mechanism because HTML may not be involved and so if
it works at all you end up resorting to screen-scraping.
In principle, if you run HTTPS, you can leverage HTTPS's
client authentication mechanisms (client certificates and
"pre-shared keys") to authenticate the client,
but in practice
this is not done, probably due to UI reasons and lack of
familiarity with the TLS mechanisms (this applies in
particular
to PSK).
DESIRABLE FUNCTIONALITY
-----------------------
As I mentioned above, a lot of different types of
functionality
have been discussed. In this section, I try to break these
down
into a set of somewhat independent functions, with the
intention
that we can end up saying that we want a system that
provides
function X and not Y. These all have sort of lame names that
I
thought of on the spot.
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.
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.
3. Portable Credentials (PC)
The nice thing about passwords is that you can memorize your
password and then use it anywhere. The rationale for this is
to make it easy for people to use credentials on multiple
computers.
4. Fill-in of Personal Information (FPI)
One of the common complaints about Web form registration
systems
is the need to repeatedly type in your user information.
Think of this
as automatic form fill-in on steroids. The rationale for
this
feature is to avoid repeated typing of this kind of
information.
5. Common User Credentials (CUC)
One way to limit the damage from credential compromise is to
have each RP use a separate credential and force the user
to make them independent (e.g., a separate password for each
RP.) This is inconvenient, of course. CUC means that at
the number of separate credentials that the user handles is
small (if not 1). The rationale for this feature is to
minimize
user attention and storage overhead.
6. Continuity of Identity (CI)
The ability to prove to some RP that you are the same
user as was involved in some other transaction. The
rationale
for this feature is to have a cheap form of personal
"account" for systems like blog comments,
message boards,
etc.
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.
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.
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.
ARCHITECTURAL CHOICES
---------------------
In this section, we survey a number of potential
architectural options.
This list isn't exhaustive, but is just intended to give a
flavor
of the major available choices beyond the simple two-party
username-password schemes we have now. Note that I use a lot
of PKIX-type terminology below, but the concepts are generic
and can be extended to something more SAML-oid or
something-else-oid.
BARE CRYPTOGRAPHIC IDENTIFIER
After username/password, probably the most familiar sort of
remote identifier is a bare public key. The way this is
used is familiar from SSH: the user generates a public key
and provides the key (or fingerprint) to the relying party
(or parties). He can then sign with the private key to
prove possession.
User RP
---- --
[Personal Info], K_pub -> \
Registration
<- OK /
Phase
Sign(K_priv, Something) -> \ Use
<- Service /
Phase
In the Registration phase, the user provides his
registration info
to the relying party (site) along with the public key. The
RP stores the data somewhere. In the Use phase the user
signs
something with his key to prove his identity.
Properties:
If properly embedded in a protocol (it's easy to get this
wrong),
this scheme can provide:
CRC -- the RP only has K_pub
HRA -- you can cryptographically bind the requests to the
key
CUC -- you can use the same K_pub, K_priv pair over and over
CI -- you use the same identity every time even if nobody
knows who you are.
PA -- there's no third-party to know anything about the
exchange
With an automated form fillin scheme like that specified in
DIX,
you could also provide FPI.
IDENTITY CERTIFICATES
One of the major inconveniences in dealing with bare
cryptographic
identifiers is that that names look basically random:
they're
just public keys or hashes of public keys. This is a
particular
problem if two RPs want to communicate about a user through
some human-based protocol, i.e., "Don't trust bobexample.com"
The natural way to deal with this problem is to have
certificate
authorities which are responsible for sections of the
namespace and
can issue certificates with user-friendly names.
These certificates can come in two flavors:
1. Real-world identity certificates.
2. Unique-identity certificates
Real-world identity certificates are familiar from the HTTPS
world: an SSL certificate from VeriSign is an assertion that
the certificate holder is the actual owner/operator of a
given domain. A unique-identity certificate is just a
promise
from a CA not to issue any other certificates with the same
username.
Either form of identity certificate allows you to have nice
userfriendly names (or at least more userfriendly than
random
numbers). The protocol looks something like this:
User CA
---- --
[Personal Info], K_pub -> \
Certificate
<- OK /
Issuance
The user gets a certificate (possibly covering some personal
info) from the CA. They can then use this certificate much
in the same way they used a bare key, by registering with
the RP and then getting service.
User RP
---- --
[Personal Info], Cert -> \
Registration
<- OK /
Phase
Sign(K_priv, Something) -> \ Use
<- Service /
Phase
Note that some people also think of the mere possession of a
credential, even if it has no underlying AEC semantics as
worth something. I.e., this person registered *somewhere*
and I know that about them. This makes sense in contexts
like
blog comment authentication where you are just trying to
erect
a minimal registration barrier.
Properties:
This scheme has most of the same properties as the bare
cryptographic
identifiers, but also has at minimum User Friendly Naming
(UFN).
In addition, if the certificates are real-world identity
certificates,
it provides a very limited form of AEC, namely "this
person has
the right to this e-mail address, domain name, etc."
SIGNATURE + KEY SERVER
Both bare cryptographic identifiers and identity
certificates suffer
from portability problems. The part of your identifier that
you need
available to you at authentication time is a fairly long
random number
that most people won't be willing to memorize. [0] The
natural
approach is to carry the data around on a token (USB key,
PCMCIA
card, etc.) but this seems unattractive to many. Another
option is
to use a SACRED-type server to store the key and then let
the user
fetch it at whatever computer they are at. SIP is also
considering
a similar technique for moving keys between handsets (see
(draft-ietf-sip-certs)
Properties:
Same as underlying authentication scheme + Portable
Credentials.
ATTRIBUTE CERTIFICATES
The clear problem with all the schemes mentioned so far is
that
they only provide very limited AEC, which a lot of people
clearly
want. The standard solution for combining AEC with
public-key-based
authentication systems is to use attribute certificates:
certificates that assert a certain fact about the holder of
key
K, such as:
"The person who holds key K is an American
citizen."
In PKIX these are often (always?) tied to some actual
3rd-party
certificate but from an architectural perspective, they
could be tied
to a bare key. Attribute certificates can also be used to
provide
IAC: you have a bundle of attribute certs with one for each
claim
you wish to assert and you simply provide the relevant certs
to the RP.
The basic protocol looks like this:
User CA
---- --
[Personal Info], K_pub -> \
Certificate
<- AC1 (Over 21) >
Issuance
<- AC2 (US Citizen) /
In the Certificate Issuance phase, the user proves to the
CA the claims that he wants the CA to vouch for and the
CA gives him ACs for those claims.
User RP
---- --
Sell me beer -> \
<- Prove you're 21 \ Use
Sign(K_priv, Something), AC -> / Phase
<- Service /
In the use phase, the RP indicates which claims he wants the
user to demonstrate and the user provides the appropriate
ACs and demonstrates that he has the corresponding key.
Of course, for any attributes for which you have ACs, you
also get some FPI for free as part of the authentication.
Properties:
CRC, HRA, FPI (Some), PC (if used with key server), CUC, CI,
UFN, AEC, IAC, PA
IDENTITY PROVIDERS
A lot of the designs that people seem interested in involve
Identity Providers (IdP). An IdP is a server that offers
interactive identity claims. (One way to think of this is
as a real-time CA). There are a bunch of different
topologies, but the basic idea is as below:
User IdP
---- ---
[Personal Info], Auth Info -> \ Registration
<- OK / Phase
The user registers with the IdP and (optionally) proves
the claims that he wishes the IdP to assert later. The
user needs to establish some sort of authentication
credential with the IdP so that he can authenticate
later. This can be a password or a public key pair (as
above).
Later, when he wants to actually use his identity, we
get an exchange like this:
User RP IdP
---- -- ---
Sell me beer ->
<- Prove you're 21
IdP, help me! ->
<---------- Auth exchange ------------->
<- Credential
Credential ->
<- OK
When the user requests service, the RP prompts them for
their
identity (or in the case above, to prove some claims). The
User then contacts the IdP and proves their identity
(authenticates as the person who previously registered)
and gets a credential. He Then provides the credential to
the
RP, who provides the service.
There are a lot of ways to implement this general
architecture
and they all have different properties.
Properties:
At minimum, IdP based schemes provide:
PC -- you can contact the IdP from anywhere
CUC -- you only need to authenticate to the IdP and then can
leverage that to authenticate everywhere
CI -- you use the same IdP acct over and over
UFN -- the IdP can issue you some easy name
If the IdP makes claims about you, then you can also have
FPI, AEC and
IAC. In general, because the IdP knows which claims you're
asserting
for a given RP, you do not get PA. There are, however, ways
to provide
this feature, but often the contrary is part of the design
of the
system.
A lot of the variation in IdP schemes is the implementation
of
the authentication, both from the user to the IdP and from
the
IdP (and user) to the RP. There's too much variation to
discuss
here, but I'll cover a few high points.
Authentication to the IdP:
Part of the point of an IdP scheme is that you authenticate
to
the IdP in order to get your credentials. Obviously, this
authentication can be done in a lot of ways. Some of them
allow phishing, credential capture, etc. It's clearly
desirable to couple an IdP scheme with some sort of
auth scheme that provides CRC and probably HRA.
Binding of credentials to requests:
In an IdP scheme, the IdP provides some token to the user
that is then
provided to the RP. This token may or may not be
cryptographically
bound to the messages that the user is sending to the RP. If
this
is not done, then the user<->RP protocol is
potentially susceptible
to hijacking.
Note that it's well understood how to design both of these
protocols
securely. However, it involves more changes to the current
implementations of Web and WS protocols.
TRANSPORTING/BINDING CREDENTIALS
--------------------------------
The discussion above has focused primarily on dataflow, but
from the perspective of implementation/deployment, how you
transport and bind the credentials to the PDUs they're
authenticating matters. Note that to some extent this is
orthogonal to the type of authentication architecture
you're
using. You can, for instance, use public key signatures
with multiple binding/transport mechanisms.
There are three commonly proposed transport/binding methods:
CRYPTOGRAPHIC BINDING INSIDE HTTP
If you're using public key for authentication, the natural
approach is
to simply have the credentials bound directly to the HTTP
PDUs they
vouch for. So, the PDU would contain a signature line that
covered the
request itself. This is what, for example, S-HTTP does.
In systems like this, additional credentials (ACs, SAML
assertions,
etc.) are just carried in the message and the whole thing is
bound
together with the signature. Something like this:
POST / HTTP/1.0
X-Attribute-Cert: <insert A-C here>
X-Signature: XXX
Post arguments
The signature is computed over the entire message and
headers (except
for the signature itself, of course), or part of it
(hopefully enough
to block cut-and-paste attacks). This kind of technique, if
performed
correctly, provides both CRC and HRA for the messages
between the user
and the RP.
Similar techniques can be use with symmetric keys and MACs
over
the PDUs. In such schemes, if you're using an IdP, then
you'll
probably also have to carry around a ticket that gives the
RP the symmetric key needed to verify the message.
Implementing this kind of scheme would generally require a
fair
amount of modification to the browser and server at least to
protect the messages.
SSL/TLS CLIENT AUTHENTICATION
Another approach is to do things at a layer below HTTP,
typically
using SSL/TLS client authentication. Currently, SSL/TLS
supports
client authentication using pre-shared keys and certificates
(you can
use self-signed certs as bare keys).
draft-housley-tls-authz-extns
defines how to carry X.509 ACs and SAML assertions inside of
TLS, so
these could be used as well. This technique automatically
provides CRC
and HRA.
In principle, TLS clients and servers already support at
least
cert-based client auth. In practice, the UI on the client
is so bad that you would almost certainly need to clean it
up
quite a bit in order to make this kind of system usable.
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.
-Ekr
[0] You can use asymmetric key pairs generated from
passwords,
but even with the application of key stretching techniques,
this
makes a lot of people uncomfortable.
[1] Note that if you're worried about this class of attack,
you need
*every* PDU to be cryptographically bound to the credential
with
all designs. If, for instance, you use cert-based auth but
then
transition to cookies over HTTP for state management,
there's a
cut-and-paste attack there.
_______________________________________________
Ietf-http-auth mailing list
Ietf-http-authosafoundation.org
http://lists.osafoundation.org/cgi-bin/mai
lman/listinfo/ietf-http-auth
|