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.
- Put your name and net id on each page of your solution.
- Typeset your solution, using 10 point or larger font and use 8.5 x 11 inch paper.
- Use at most 3 pages (single sided) for the solution
(plus an additional 2 pages for the extra credit, if you undertake that).
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:
-
Application administrators dislike having to maintain
authentication databases and to administer the distribution of
userids and passwords.
-
Users dislike having to remember multiple passwords.
-
Security is eroded when
users (as they invariably do) employ the same password for multiple services.
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:
-
User authentication for all services---including those not under
administrative control of CIT---is performed with CIT-maintained
protocols, services (possibly including some new ones), and
the existing Kerberos KDC.
-
The security guarantees of the old protocols are maintained.
-
If a user A is authenticated to a service B
then B cannot subsequently impersonate A to any other
service B'.
(This precludes the CIT infrastructure from revealing user A's
password information to another service B' and it
precludes the CIT infrastructure from creating for A
a single session ID that is valid for all services B'.)
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.
- HTTP Request:
-
- GET( SomeURL,
[p1=v1, ..., pn=vn],
[c1=cv1, ..., cn=cvn] )
- A GET request is employed to fetch the content associated with
URL SomeURL.
- A GET request is issued when a user opens a web browser and
types URL SomeURL. In this case, parameter list
[p1=v1, ..., pn=vn] will
be empty. If the client has not previously interacted with the
server hosting SomeURL, then cookie list
[c1=cv1, ..., cn=cvn]
will be empty too. If
the client has previously interacted with the server
(determined by some prefix of SomeURL) then any cookies set
by that server and stored by the client's browser will be included
by the client browser in the request that is sent.
- Clicking a link within a web page causes a GET request
for the URL of the linked page to be issued. The link might encode parameters
to be passed in the GET request. Again, which cookies are sent by the browser
depends on previous interaction between that user and the server.
- Forms are web pages with specially designated input
fields and a submit button.
Each field has a parameter name associated with it, and the
form submit button has a URL FormURL associated with it.
If a user has entered value vi in a form field having
parameter name fi
then clicking the submit button causes the browser to issue a GET
request for FormURL, passing a parameter fi=vi.
If the user has not entered a value for a field before clicking submit,
then a default value associated with that field is sent.
A form field may be hidden,
allowing the website issuing that form to transmit information to
FormURL when the user clicks the submit button.
Cookie transmission behavior is the same when a user submits a form as with
a regular HTML link.
- HTTP Responses:
-
- SUCCESS([c1=cv1, ..., cn=cvn], DATA )
- A SUCCESS response allows the server to return data (such as HTML content) to
the client. It includes a (possibly null) set of cookies
[c1=cv1, ..., cn=cvn]
to be stored by
the client as well as the data DATA itself.
If the name of a cookie is the same as the name of a previous cookie sent by a given
server, then the older cookie is replaced by the newer one in browser storage.
Until the web browser is closed,
the client will send the newest versions of all cookies that the
server has included in previous responses.
- REDIRECT( SomeOtherURL,
[p1=v1, ..., pn=vn],
[c1=cv1, ..., cn=cvn] )
- A redirect response includes a URL SomeOtherURL
and some set of parameters
[p1=v1, ..., pn=vn]
and cookies
[c1=cv1, ..., cn=cvn].
A client receiving such a
response stores the cookies and then issues a GET request
for SomeOtherURL passing parameters
[p1=v1, ..., pn=vn] and whatever
cookies would normally be sent along with a GET for
SomeOtherURL.
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:
- how to use HTTP requests and responses,
- one way to integrate an authentication step into the usual interaction
between a web browser and a service to which it provides access, and
- a stylized notation (which you are expected to use in
your redesign) for describing such a protocol:
-
The protocol is specified as a sequence of numbered steps.
-
Each step includes a number and a command denoting a message transmission
(e.g., GET, SUCCESS, or REDIRECT) followed by an English text that
discusses the purpose of the command as well as any local processing
and/or state saving performed by the recipient of the command.
-
The notation
"A => B" (rather than "A -> B")
is used to indicate HTTP
requests and responses conducted over a secure SSL channel.
Here is the protocol:
(1) A => B: GET( BURL, [], [] )
With (1), A requests page BURL from B.
Since the user has typed (only) BURL into a web browser,
neither cookies nor parameters are passed to BURL.
When B receives the request for BURL---a resource requiring
authentication---without any
information authenticating A,
B sends the following message rather than delivering the
content at BURL:
(2) B => A: REDIRECT( BAUTH, [source=BURL], [] )
Message (2) is a redirect to some authentication page on
B, where the REDIRECT request includes original source page BURL
as a parameter.
(The source parameter is included so that A,
after being authenticated, can be redirected to
BURL in a subsequent step.)
A, in processing message (2),
fetches BAUTH with the following message (3):
(3) A => B: GET( BAUTH, [source=BURL], [] )
Message (3) is generated automatically by the browser at A
in accordance with the semantics of a REDIRECT response.
(4) B => A: SUCCESS( [], AuthenticationForm )
With (4), B supplies an authentication form
AuthenticationForm to A.
This form contains
(i) a text field for the username,
(ii) a password field for the password, and
(iii) a hidden field, source, whose default value is BURL.
When the submit button on this form is clicked,
the username and password are transmitted
to another authentication page BAUTH2.
(5) A => B: GET( BAUTH2, [source=BURL, user=A, password=APASS], [] )
With (5), A submits the form to B.
(Note BURL is included as a parameter
because BURL was a hidden value on AuthenticationForm.)
Upon receipt of this GET request,
B checks the user and password parameter
values it contains (using logic defined in BAUTH2).
If the authentication information is valid,
then B
(i) generates a (fresh) session ID SID,
(ii) locally stores a record of the binding between A and SID
along with an expiration time, and
(iii) then issues the following REDIRECT to A:
(6) B => A: REDIRECT( BURL, [], [session=SID] )
With (6), A is directed to fetch the original page it requested in (1).
However, now a
session ID SID provided by B is included so that B can
authenticate the request.
(7) A => B: GET( BURL, [], [session=SID] )
Message (7) is like original request (1), except that it includes a cookie
containing a session ID.
Upon receipt of this request, B would look-up SID
(which it stored in step (5)) and check that SID corresponds to a
valid session.
If it does, then the origin of the request A is
considered authenticated and the response originally sought by A
is sent as message (8).
(8) B => A: SUCCESS( [], Contents of BURL )
Thereafter, every request that A makes to B
includes a cookie with session ID SID so B
can authenticate A.
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.
- Use only the abstracted HTTP commands listed above for HTTP protocol messages.
- Because users will access CU web services using standard browsers, assume:
- Browsers do cryptographic operations only through SSL.
- Browsers store data only using the cookie mechanism.
- Client machines are restricted to standard responses to HTTP
messages, as discussed above. In particular, client machines and browsers
cannot do "client-side" computation (including no client-side scripting).
- The implementation of Kerberos and KDC may not be changed.
Specifically, the KDC must continue to operate exactly as was
described
in class and may not be modified in any way.
Assume that Kerberos shares a key KB
with every service
B that needs to authenticate clients.
However, feel free to define and add a small number of new
CIT-administered servers,
which work in conjunction with the current Kerberos KDC deployment and assist
in authenticating users for non CIT-supported services.
- Any cryptographic key needed for operation in the redesign
(not including those keys used by SSL) must be obtained from the Kerberos service.
- Clocks on processors
that run the services B needing to authenticate clients
are not necessarily synchronized.
(Clocks on Kerberos servers satisfy whatever assumptions are needed
for Kerberos to work correctly.)
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.