HISTORY
-------

** CAS client 2.0.4:

 - Versions 2.0.3 and earlier of the client distributions contain code
   for mod_cas that is specific to Linux.

   This distribution adds a branch of the mod_cas code that runs
   successfully on non-Linux platforms under Apache 1.  The code bases can
   easily be merged, but this separate branch should prove useful to users
   of Solaris and other non-Linux platforms (in particular, those that
   don't have /dev/urandom or BSD-style advisory file locking) until we
   have the opportunity to test a final merged module sufficiently for
   general posting.

** CAS client 2.0.3:

 - Minor adjustment to the build process (build.xml) for the Java client

** CAS client 2.0.2:

 - Addresses a potential security issue whereby the HTTP "Host" header
   is used as the basis for determining the service URL in some high-level
   clients - particularly the Java filter and tag library.

   The potential problem is best explained as follows.  Clients that
   use a method based on the HTTP "Host" header to determine the current
   request's URL (e.g., via calls to ServletRequest.getRequestURL())
   are vulnerable to an "illicit proxy" attack.

   Like all HTTP headers, the HTTP "Host" header is under the control of
   the client.  Suppose service A, running at http://A, is contacted by
   a user that supplies "Host: B" as a header.  If the web server on which
   service A runs passes through requests for unknown "virtual hosts" to
   service A, then when service A calls getRequestURL(), the result will
   be "http://B".

   This leads to a situation where service B can conduct an illegal proxy
   authentication to service A without A's knowledge as follows:

    - User U visits service B B.
    - B can acquire a service ticket from CAS coded to user U and service
      http://B by implementing the CAS protocol correctly
    - B can then construct a client HTTP request to service A, passing
      "Host: B" as a header.  In this request, it sends the CAS ticket it
      acquired.
    - Service A will receive a request that includes a ticket, and it will
      attempt to validate the ticket with CAS by sending the ticket, along
      with http://B as its service, to CAS.  CAS will approve the
      authentication.
    - Service B can now access service A as user U.

   All of the following are solutions to this problem:

   - Use the low-level JavaBean interface provided with the CAS distribution,
     which requires you to determine your service URL yourself.  (Of course,
     this asssumes you can make this determination securely.)

   - Use the newly provided CAS filter or CAS tag library, which accept
     static configuration parameters that identify the server name.  For
     instance, for the CAS filter, you should add the following
     initialization parameter:

      <init-param>
        <param-name>edu.yale.its.tp.cas.client.filter.serverName</param-name>
        <param-value>myserver:myport</param-value>
      </init-param>

     (where ":myport" is optional). 

    - Use the Perl module from version 2.0.2 or later, which requires that
      you pass in the service URL when making the call to the
      check_login() method.

    - Use the new Apache modules from version 2.0.2 or later.

    This potential attack is not relevant for the PAM module, and the
    documentation for the ASP page has been adjusted to provide new
    information.

** CAS client 2.0.1 and earlier: initial versions