Ben Laurie <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> >
> > No user session that
> > is. My idea is to have the user authenticate, and then bind the user id to
> > the ssl session id. Next time around, I'll see that I have an user id
> > associated with the ssl session id and not bother with the authentication
> > mumbo jumbo. We're not doing Basic or Digest authentication. We have a
> > forms based scheme that can back-end against just about anything, RADIUS
> > challenge-response even.
>
> I understand the idea. My point is mostly that the lifetime you would
> like for this "user session" has completely different requirements from
> the SSL session.
Not sure I would say "requirement". The idea is to only bind an identity to
the SSL session id. Then policy enforcement, session management, is done
based on the identity. Like Tom can have access for only five minutes per
hour, while Ben is allowed access all day. But, yes, certainly it would be
nice if the SSL session was (guaranteed to be) longer lived in a case like
this.
>
> > I see your second point. At worst this would mean the user would have to
> > re-authenticate. And the old, non-reused, session would just timeout.
>
> Right. But the main point is that there are at least three really
> obvious ways to do this properly, so why try to bend SSL session IDs to
> a purpose they don't really fit?
Because the other two are way too spoofable.
-Tom
--
Tom Vaughan <tvaughan at aventail dot com>
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
