RE: Transferring a Session

["Levenglick, Jeff" <JLevenglick () fhlbatl com>]

I have used a few commercial products that do something like what you are 
trying to do. The popular choice right now is to :

All systems:

1) setup a daemon that runs on a port you pick.
2) setup cert on each host and run auth-ssl to each host involved.
3) create a time stamped/checked sum token to be passed to each host.
This token would have a life from 60 seconds up and have a total session time.
4) Keep the security separate from the applications. ie: the security part will
auth for you and your application will do its data part. 

Jeffrey 

-----Original Message-----
From: David Robert [mailto:drobert () djinnsoft com]
Sent: Monday, May 03, 2004 06:34 PM
To: webappsec () securityfocus com
Subject: Transferring a Session


Hello all,

I have a problem I would like some input on. I need to implement a solution
that allows one website to securely transfer 'logged in' state to another
website.

I know this problem must have been solved 100 times before but I have not
found a simple 'open' standard procedure for solving this. Maybe it's just
too simple? In any case, suggestions appreciated. Further details below.

Requirements/Constraints:
1) System A authenticates users.
2) System A needs to present a link/form to the user that brings them to a
logged in session on System B.
3) System B is written in Java and uses SSL, form based, username/password
authentication.
4) Users are created on System B from System A data that identifies the user
on System A (System A identifiers). This data is unique and unchanged over
time. System B creates a tentative user (and generates a username/password)
from this information. An administrator on System B will later authorize
this creation. The System B username/password is never changed.
5) We are looking for a system that is easy to implement and consistent with
the level of security already present - i.e. open to man in the middle
attacks, etc.

Solutions:
There are 3 solutions I have been considering. They involve ensuring that:
a) The link/POST the user uses to get to System B really came from System A.
b) System A identifiers on the request have been unchanged.

The solutions I am considering are:
1) Sign the parameters of the request generated on System A with a private
key. Use the public key on system B to verify the sender and contents.
2) Create a service on system B that will create a time-dependent token.
System A validates itself with B and gets a token. It includes it on the
generated link/POST for the user. The token is used by system B to verify
the request.
3) Like #1 but use a common secret key for both system A and B. Request
parameters will be signed by this key. Recommendations on the signing
algorithm to use?
Of course, all requests between system A, B and the user are SSL.

The 'time dependent' nature of the last two are at the request of the
client. They are concerned that the link can be read from the browser's
cache by an attacker. Is this really a problem if the page on system A is
set to not be cached?

Any input appreciated,
-David

-----Original Message-----
From: dave kleiman [mailto:dave () isecureu com]
Sent: Sunday, May 02, 2004 1:08 AM
To: webappsec () securityfocus com
Subject: ISAPI


Hello,

Is there a timeout setting anywhere for and ISAPI.dll in IIS5.

We have an issue where the ISAPI request is made, the sever is trying to
write it to the client and it is timing out.



_____________________________________
Dave Kleiman, CISSP, MCSE, CISM, CIFI
www.SecurityBreachResponse.com




-----------------------------------------
This e-mail message is private and may contain confidential or privileged information.