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 [EMAIL PROTECTED]