Password Deployment Issues and Attribute Certificates

1.	Deployment Issues of Having Shared Secret Authentication in
	TLS Versus Certificate-Based Authentication

In message <>, Eric Murray writes:
> Similarly, the deployment and administration will, at least in
> the short to medium term, be more complicated, not less.  With
> TLS-autheitication passwords there's now one more password database
> that will need to be maintained, checked for weak passwords etc.
> Arguably, most installations will want to support the non-TLS versions
> of the above services, for service inside the "secure" LAN.

Why are we second guessing deployment complexity / costs here?  John
Macko of Compuserve, presumably, knows better, and he's made his (or
his company's) opinion known.

Now, I'm not a systems analyst / economist / whatever, but it seems to
me that the obvious thing to do for Compuserve and others like them
(say ``Company X'') is to take the existing database of customer
passwords and hook that into their web servers, using
ODBC/COM/CORBA/acronym-of-the-day.  No new database -- just interfaces
to existing ones.  If/when the customers upgrade their web browsers
(floppy in magazine, anonymous ftp, whatever), the switch to
TLS-provided, strong-crypto-protected shared secret authentication is
largely transparent to the user.  And you've successfully transitioned
to better protection for the user authentication, since after a few
years only an acceptably small percentage of people will not have

You don't lose customers because you don't have to tell them that they
have to upgrade and obtain a client certificate.  Granted, this can be
automated if you bundle extra software with the web browser to
automatically obtain a class 1 verisign cert (and btw have the user
shell out six bucks [assuming here that its out of beta]), this is not
really acceptable since people grab free browsers from many sources,
not just company X.  (And recent studies show that people on the
Internet are pretty cheap.)  On the other hand, if you allow users
with the new browsers to just fall back to the old, form-based
authentication, you're much less likely to make the transition to
better cryptographic protection.

What's the transition picture like for going to certs?  BTW, *here* is
where a new database is needed, since you need to map certified IDs to
existing accounts.  Can the value-added ISPs eat the cost of the
certs?  Can a consortium of v.a.ISPs get together and eat the cost?
Maybe (but it makes it easier for users to go from one v.a.ISP to
another).  Anyway, these are -business- issues and not technical ones.
And definitely not crypto/security ones, so I leave it here.

Actually, my bet is that the biggest problem with the transition to
TLS-mediated authentication for the value-added ISPs will be the
-scalability- issue.  With current server boxes, company X can handle
N users per machine on average.  With authenticated/encrypted/MAC'd
connections, how many new machines will company X have to buy in order
to maintain reasonable response times?  How many new staff is needed
to run these machines?  Training?  etc, etc.  Replicating software is
cheap (if it's freeware or home-grown, anyway); replicating
hardware/wetware is expensive.


2.	Authorization via Attribute Certificates

While I believe attribute certificates are wonderful and useful, I
believe that protocols to access them should be layered on top of TLS.
By crossing the layer boundary, we only further confound
authentication and authorization with no real gain (in conceptual
clarity, in efficiency, or in any other metric that I can think of).

One thing that we -should- do to make layering easier is to expose
(hem) a mechanism (or suggest/recommend minimal API) whereby upper
layer code can send records, so an upper protocol layer may send a
message to its peer without messing up user data.  Yes, this can be
encapsulated as another record format embedded in the
user-data-stream; it's probably better, however, to use the the
underlying record format to do the encapsulation into
max-size-from-next-lower-layer record, with a thin layer just below
the user which encapsulates the user data into the appropriate record
sizes.  This would be just like how IP header/trailer is handled.

[Aside: this is actually a bug in the current SSLv3 design.  The
assumption is that the compression transform applies to user data
records, and thus there's the extra 1k growth problem since
compression can grow the data in rare cases.  The compression layer
should be the just-below-the-user layer, and it should always get a
data stream as user-side input (output).  Thus, it should be able to
accept exactly enough user-side data to fill up the record (size as
indicated by layer immediately below) and no more, and there is no 1K
compression-expansion problem.  And in the more common case where the
compression is -working-well-, we would not have the current problem
that the compressed record having a smaller-than-necessary size.
(Even if we wanted to provide users with a record abstraction, we
should always pass up maximum record sizes after subtracting the
current layer's overhead.)]

Anyway, from a security viewpoint, authentication and authorization
are very different ideas.  As Phil correctly pointed out, the request
for attribute certificates must be optional, since some services will
want to use local authorization databases (indexed by authenticated
identities) instead of the distributed authorization database that the
attribute certificates comprise.  There is certainly no reason why the
attribute certificate request must occur as part of the initial
handshake: with a ``keepalive'' connection which handles multiple HTTP
requests, different authorizations may be required for the different
HTTP requests, and tying the attribute certificate request/reply to
the initial handshake is wrong.  The proof of -authorization- for the
operations being performed must be requested when it's clear what
those operations are, not before in a willy-nilly fashion.


Bennet S. Yee		Phone: +1 619 534 4614	    Email:

USPS:	Dept of Comp Sci and Eng, 0114, UC San Diego, La Jolla, CA 92093-0114

Received on Thursday, 1 August 1996 00:52:42 UTC