[EMAIL PROTECTED] wrote:
>
> 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.
And this is precisely the point: it would be nice from a user session
point of view, and totally nasty from a security point of view. That's
what I mean about requirements.
> > > 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.
Not if correctly implemented.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]