CS513 Homework 3: A Small Design Exercise

General Instructions. You are expected to work alone on this assignment.

Due Oct. 12, 2005. Submit your solution on paper in class. No late assignments will be accepted.

To facilitate grading, format your solutions as follows.

Solutions that do not satisfy the formatting guidelines will be returned, ungraded.

Problem Overview

At Corinth University (CU), the user community has access to a wide variety of web-based services, including services involving confidential information such as student grades, medical data, and billing or salary information. The services are run by various departments and student organizations.

Currently, each service maintains its own authentication database. Users are expected to maintain a separate password for each service so that incompetently designed or malicious services are unable to learn and possibly disclose information that others could use to access confidential information. The community, however, is unhappy with this arrangement:

Services administered by the CU Information Technology group (CIT) use a Kerberos KDC (managed by CU) to authenticate users. Services not administered by CIT may also use this KDC for authentication. However, CU policy prohibits these other departments from deploying on the network a service that prompts a user for this CU-administered Kerberos password; services that prompt users for a CU-administered Kerberos password must be under the administrative control of CIT. Fortunately for CIT (which is already short of staff), virtually no department is willing to cede control of its service to CIT just to take advantage of the (superior) authentication structure that CIT manages.

This homework exercise invites a redesign for the authentication protocols used by services at CU such that:

Your redesign should resist Dolev-Yao attackers as well as compromised clients and services. Do not be concerned with handling compromised keys.

Primitives for HTTP Communication

HTTP is a standard protocol that allows a client to issue requests to a server and receive responses from that server. HTTP is a stateless protocol: each HTTP request must include any client state required by the server to process that request. To allow a client to convey client state to a server, clients provide parameters and cookies as part of their requests.

For the purposes of this assignment, it suffices to consider only a formalized and idealized subset of the full HTTP protocol.

Sending HTTP Messages Securely

The Secure Sockets Layer (SSL) protocol is often used to establish a cryptographically secure connection, where the server is authenticated by the client, but not vice-versa. SSL is the standard protocol for sending web traffic securely; it guarantees that when a client sends information to a server named by a particular IP address or URL, the information can be read only by the destination server named by the client. This ensures the confidentiality of the information sent over the connection and precludes man-in-the-middle attacks.

Example of a Protocol to be Replaced by the Redesign

Using the HTTP commands defined above, we now describe a protocol that might be used by a service B at CU to authenticate a user A in response to an attempt by A to access some page BURL residing on B. This protocol assumes that B has a local database of (user, password) pairs, the need for which your redesign is intended to eliminate.

If nothing else, the example protocol below illustrates:

Here is the protocol: 

(1) A => B: GET( BURL, [], [] )

(2) B => A: REDIRECT( BAUTH, [source=BURL], [] )

(3) A => B: GET( BAUTH, [source=BURL], [] )

(4) B => A: SUCCESS( [], AuthenticationForm )

(5) A => B: GET( BAUTH2, [source=BURL, user=A, password=APASS], [] )

(6) B => A: REDIRECT( BURL, [], [session=SID] )

(7) A => B: GET( BURL, [], [session=SID] )

(8) B => A: SUCCESS( [], Contents of BURL )

The Redesign Problem Statement

Your new protocol should resemble the protocol given above, but the redesign should allow users to be authenticated for any CU web-based service using the single CIT Kerberos KDC username and password maintained for each user. The redesign must satisfy all of the restrictions outlined above in Problem Overview, so no service B is able to learn information that could be used to impersonate an authenticated user to another service B'.

Your redesign must also satisfy the following constraints.

Your redesign may (i) involve changes to the implementation of those servers B that require authentication of clients and (ii) may involve additional server-side software that constitutes a front end to those servers.

Finally, note the above problem description does not require a single authentication of a user A to be valid for multiple services; it is perfectly fine to require that A enter a username and password every time a new service B is being accessed.

What To Submit: Give a description of your protocol in terms of a sequence of steps having the format used above. Each step should start with an HTTP request or response or with some other message transmission (e.g., a Kerberos message, such as sending of a TGT or a TickB message).

For extra credit, modify your solution so that a client A can access multiple services during a given browser session by entering a username and password only a single time. Do not attempt the extra-credit version of the problem until you have written up a solution to the basic problem! No extra points will be awarded if the solution to the basic design is found to be inadequate.