view release on metacpan or  search on metacpan

README  view on Meta::CPAN

---------------------------

The fundamental security mechanism of Apache::SecSess is the issuance
of simple cryptographic proofs of identity explicitly constructed to
return to the system's various servers via HTTP(S) sessions which are 
protected with sufficient strength, despite the malicious behavior by an 
adversary.  This is achieved in a rather mundane way, namely by avoiding
all the pitfalls of the enumerated issues in Sect. 3.  

In the case of URL credentials, the current implementation requires all
URL's to be explicitly configured.  All redirects are automatic, occurring
under SSL of a specified strength.  There should be no surprises here; if
URL credentials were stolen, the adversary would have had to crack one of
a small number of SSL connections under the complete control of the security 
administrator.

In the case of Cookie credentials, *multiple* cookies are issued, one for 
each anticipated security level.  For example, a user who logs in with an 
X.509 client certificate might be issued 3 cookies: one cleartext cookie 
intended for non-sensitive data, one SSL (secure flag) cookie broadly 
distributed to .acme.com with 40-bit crypto possible, and finally one SSL 
cookie intended only for the 128-bit originating host.  An adversary who 
manages to steal either the cleartext or the 40-bit cookie cannot use it to 
acquire 128-bit level resources, because the cookies themselves have 
unforgeable assertions of security level which are checked during session 
authentication as described in the next section.


5.3  Credential Format
----------------------

Credentials in Apache::SecSess have a similar format:

    URL Credentials:
        realm=E_k(md5(hash),hash)

    Cookie Credentials: 
        realm:qop,authqop=E_k(md5(hash),hash)

(The only difference is that the quality of protection parameters 
discussed below, qop and authqop, are repeated in the clear for cookie
credentials in order to ease processing.)

The string 'realm' is any symbol (without obvious special characters 
':', '=', etc) which is used to identify cooperating security services,
thus providing a way to put credentials into their own namespace.

The 'hash' is a string representation of a Perl hash of the form:

    hash = {
        uid => string: user ID
        timestamp => integer: time stamp from time(),
        qop => integer: session quality of protection,
        authqop => integer: user authentication quality of protection
    }

See the source code of Wrapper.pm for details of how the hash is converted 
into a string.

The encryption function E_k is currently not very configurable.  It is 
Rijndael (AES) in CBC mode with IV=0.  It is well known that CBC mode is 
vulnerable to forgeries, so a cryptographic checksum is prepended to the 
plaintext, as indicated.  

The secret key k must be shared by all host or web servers which use the same
realm.  Without the secret key, it should be cryptographically infeasible to 
produce credentials in which the hash and checksum match.  It should 
therefore be cryptographically infeasible for anyone to forge credentials or 
alter them in any way.


References
----------

[RFC2109] D. Kristol, L. Montulli, HTTP State Management Mechanism, 
    RFC 2109, 1997.

[RFC2964] K. Moore and N. Freed, Use of HTTP State Management
    RFC 2964, BCP 44, October 2000.

[RFC2965] D. Kristol, L. Montulli, HTTP State Management Mechanism, 
    RFC 2965 (Obsoletes 2109), October 2000.

[W3C] World Wide Web Consortium Security FAQ,
    URL: http://www.w3.org/Security/Faq/.

[SSL] D. Wagner, B. Schneier, "Analysis of the SSL 3.0 Protocol", 
    1996, URL: http://www.counterpane.com/ssl.html.