[26] in WWW Security List Archive
Re: GSS API...
daemon@ATHENA.MIT.EDU (Jeff Hostetler)
Tue Aug 16 13:56:47 1994
From: jeff@spyglass.com (Jeff Hostetler)
To: John Ludeman <johnl@microsoft.com>
Cc: www-security@ns1.rutgers.edu, jeff@fido.spyglass.com
In-Reply-To: (Your message of Mon, 15 Aug 94 13:15:45 T.)
<9408152020.AA25980@netmail2.microsoft.com>
Date: Tue, 16 Aug 94 10:24:19 -0600
> 1) A model for pluggable security providers in Web servers and clients
>
> 2) The age old question of how to add support in HTTP (i.e.,
> Secure-HTTP etc.) for any random provider.
>
> [...]
>
> So, what holes are there? Why won't this work? What needs to be
> changed/added so this will work for your particular implementation?
[Perhaps this is being implicitly said in the last few messages
in this thread, perhaps not. I'd like to raise it now.]
I think we need to separate the encryption protocols from the
authentication/payment protocols. We should add support in HTTP
for encryption (i.e., multiple drop-in encryption modules) with
encryption technology negotiation similar to that discussed in
S-HTTP or the "Accept:" and "Accept-Encoding:" headers in HTTP.
Authentication/payment should be done outside of HTTP via
third-party service providers. This allows a specific
authentication/payment protocol to do whatever (possibly
proprietary) challenge/response as is deemed necessary to
ensure security. HTTP would only need to provide a few
standardized 'generic' messages:
from the server, an i-accept-authorization-via message
from the client, an i-have-authorizaiton-from message
where these messages would be like the "Authorization:" header
in HTTP where an authorization-domain is specified followed by
domain-specific parameters.
The authentication/payment protocol should be able to demand
a minimum acceptable encryption technology.
> A transaction from the client perspective may look like:
> [...]
> From a server perspective:
> [...]
[Ignoring for now the DLL implementation details,] a transaction
might go something like this: [This is a bit brief/informal as
I am still working out the details.]
1) client to http server:
get url
2) server response:
402 payment required
Authorization-Accept: visa ... c=US, v=$4.50
Authorization-Accept: amex ... c=US, v=$4.50
3) If the user wanted to pay, the client would contact a 'payment
service provider' and arrange for payment via the 'visa'
protocol (or the 'amex' protocol). As part of the
transaction the client would be given an authorization
token.
4) client to http server:
get url
Authorization-From: visa ...
5) At this point the http server would ask the 'payment service
provider' if it issued the token. If it did, the http
server sends the requested document to the client. If
not, it repeats the response in step 2.
This method, I believe, has the following advantages:
1) The HTTP server remains stateless.
2) It still follows the HTTP/1.0 connect/request/response/close
model.
3) Public (non-secure) documents can still be retrieved
as in HTTP/1.0.
4) Administration of the HTTP server is simplified since only
the authorization/payment service providers need to
have the ultra-high security.
5) For payment schemes, someone would need to contact the
bank or credit card company's host anyway. This should
be done under the user's control; credit card and account
information should be a secret between the client and
the payment service provider -- the http server should
not receive any of this information.
Here are a few open issues:
1) In step 5 the server verifies the authorization, could the
server do this without asking the service provider?
Could the server use a different service provider (within
the same protocol) than the client used?
2) The server may also need to issue an "Authorization-Receipt:"
> I realize this is perhaps more work in the short term then what people
> may be willing to implement but in the long term we'll be better off if
> we get this right.
Agreed. Spyglass is willing to commit/donate time/effort/code
long-term to help get this right.
jeff
