Another entry in the internet security hall of shame....

Anne & Lynn Wheeler lynn at garlic.com
Tue Sep 13 12:55:52 EDT 2005


Paul Hoffman wrote:
> In many deployments of "SSL first, then authenticate the user with a
> password", the "site" consists of two or more machines. Many or most
> high-traffic secure sites use SSL front-end systems to terminate the SSL
> connection, then pass the raw HTTP back to one or more web servers
> inside the network.
> 
> The reason I bring this up is that the SSL server generally does not
> have access to the users' credentials. It could, of course, but in
> today's environments, it doesn't. Changing to TLS-PSK involves not only
> changing all the client SSL software and server SSL software, but also
> the what the SSL server's role in the transaction is.

this is relatively straight-forward on the server side ... most
webservers have stub-code for client authentication. frequently you see
places writing roll-your-own code for accessing a password flat file
(and comparing passwords for authentication).

 another approach is to have the webserver client authentication
stub-code call kerberos or radius interface
http://www.garlic.com/~lynn/subpubkey.html#kerberos
http://www.garlic.com/~lynn/subpubkey.html#radius

where the clients credentials are managed and administrated ...
including authentication, authorizations and also potentially accounting
information.

the original pk-init draft for kerberos had public keys registered in
lieu of passwords ... and kerberos doing digital signature verification
with the on-file public key. similar implementations have existed for
radius.
http://www.garlic.com/~lynn/subtopic.html#certless

basically use the extensive real-time administrative and operational
support for integrated authentication, authorization and even accounting
across the whole infrastructure. ISPs and/or corporations that currently
use something like radius for their boundary authentication in places
like dial-in routers ... could use the same exact administrative and
operational facilities for providing client authentication,
authorization and accounting for any webhosted services they might
provide (aka ... the integrated administrative and operational support
could include very dynamic and fine-grain authorization information ...
like which set of servers during what portions of the day).

the other advantage of the integrated real-time business,
administrative, and operational of a radius type approach is that it can
select the authentication technology used on a client-by-client basis
... it doesn't have to be a total system-wide conversion. the
radius/kerberos solution could be rolled out on all the servers ... and
then technology selectively rolled on a client-by-client basis ...
continueing to use the same exact integrated business, admnistrative,
and management real-time characteristics with large co-existance of
different client technologies (for instance ... when clients setup their
dial-in PPP connection to their server ... they may be offered a number
of different authentication options ... a server-side radius operation
can concurrently support all possible authentication technologies ...
appropriantly specified technology on a client by client basis.

kerbersos and radius are extensively used for doing real-time integrated
administrative and management of authentication, authorization and even
accounting information. registering public keys in lieu of passwords is
a straight-forward technology operation upgraded ... preserving the
existing business, management, and administrative real-time integrated
characteristics.

it wouldn't introduce new business, management, and/or administrative
operations ... like frequently occurs with pki-based operations.

with the use of the appropriate business, management, and administrative
real-time infrastructure ... straight-forward new technology roll-outs
addressing various authentication, authorization, and/or accounting
requirements doesn't have to be a syncronized, serialized, system-wide
change-out ... all the servers could be upgraded to a real-time
business, management, and administrative infrastructure that is
relatively technology agnostic as to the specific technology used by any
specific client.

then the specific technology used by any client then becomes an
individual client decision coupled with possible infrastructure overall
risk management requirements for that specific client when doing
specific operations.

one could imagine a wide-variety of clients ... all accessing the same
identical infrastructure ... possibly concurrently using password,
challenge/response, digital signature with and w/o hardware token
protected private keys.

specific authorization features might only be made available when the
digital signature is believe to have originated from a private key that
has been certified to exist in a hardware token with certified integrity
charactistics (keys generated on the token, private key never leaves the
token, token evaluated at EAL5, etc). Certain fine-grain entitlement
permissions might conceivably even require options like authentication
operation is digitally co-signed by a known terminal ... somewhat the
finread side-subject which also has known, certified integrity
characteristics ... possibly even including fixed physical location.
recent finread related posting:
http://www.garlic.com/~lynn/aadsm21.htm#1 Is there any future for smartcards

not such an integrated real-time operation can leverage the same
business, administrative and management infrastructure for not only
deploying fine-grain session-based operations ... but also fine-grain
transaction operations (supporting real-time distribution of client
credential authentication, authorization, and accounting information
across the operational  environment).

in the past, i've periodically commented that when you have been freed
from having to worry about all the extraneous and distracting vagueries
of PKI-related issues ... you can start concentrating on the fundemental
requirements that a large, complex institution might have for
authentication, authorization, and accounting .... including being able
to support multiple different concurrent technologies meeting a broad
range of risk management and integrity requirements.

Given a suffiently robust real-time administrative and management
infrasturcutre ... then specific technology roll-outs should be much
less tramatic since they should be do'able piece meal on a server by
server and client by client basis ... w/o resorting to a whole scale
infrastructure syncronized conversion (while still retaining integrated,
real-time overall administration of the operation).

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list