COMP3310 - Computer Networks (2012)

An Authentication Proxy

In this assignment, you will be writing an authentication proxy in the C programming language. This assignment is an example of an application-layer proxy.

Application-Layer Proxies

An application-layer proxy is a program that sits between some client and it's server and, generally, performs some function. To the client it appears as a server and to the server it appears as a client.

A well-known example of application-layer proxies include the web-cache, which appears to a web-browser as a web-server and, when accessed, goes to the real server, appearing as a web-browser for the content. In this case, the web-cache will also cache recently accessed pages, so that they do not need to be fetched from the real server multiple times.

Application-layer proxies can also perform some sort of protocol translation between the real client and real server. An example of this is a print-server that might "speak" Internet Printing Protocol (ipp) to it's clients, but then "speak" BSD Line Printer (lpr) protocol to the printers, or even using a completely different network-layer protocol, speaking AppleTalk Printer Access Protocol (pap) to laserwriters connected using the AppleTalk network layer.

Authentication Proxy

Authentication is the process by where a computer system confirms the identity of a person (or another computer system) using some "factor" such as a password, a "key" (or signature) or similar. In most cases, a person will supply a username and a password.

The Authentication proxy acts as a broker between an application wishing to authenticate, and one or more authentication servers.

The Authentication proxy can be thought of as having one or more "front-ends" - the authentication mechanism(s) or protocol(s) it supports for applications wishing to authenticate, and one or more "back-ends" - the authentication services it can "speak" to the actual authentication servers. The proxy can also "cache" results (positive and negative) for a period of time.

In the case of this assignment, the authentication mechanism to be supported for the application is clear-text LDAP version 2 "bind". That is, the proxy will be listening on TCP port 389 (the standard LDAP service port) for bind requests and will service those requests from it's own cache, or by querying the back-end servers. The assignment is required to support clear-text LDAP version 2 backends using both IPv4 and IPv6. It should be written in such a way that other back-end authentication protocols can be added in (ie. modular).

Other potential backends (not required to be implemented for this assignment) include Network Information Service (NIS - formerly Sun YellowPages) and RADIUS. Also, any authenticated protocol could be used as a potential backend, such as an SSH connection, a Telnet or (authentiated) FTP connection, a Post Office Protocol (POP) or Internet Mail Access Protocol (IMAP) connection or even connections to certain databases such as PostgreSQL or MySQL etc.

Research

To start with, you will need to research how LDAP version 2 bind works, in both the positive and negative cases.

One way to do this is to use Wireshark and/or TCP Dump (tcpdump) to analyse the packets between a client and an LDAP server during the binding operation - see the section on Testing below.

Configuration file

The assignment code is required to read and parse a configuration file which will provide details such as which port(s) to listen on, how long to cache entries, and the details of the backend protocols to support.

The name of the configuration file will be passed as a command-line parameter with the -f flag, eg.:

./my_proxy -f proxy.conf

The format of the configuration file is:

# anything following a hash on a line is a comment

# blank lines are ignored.
debug = 0	# how much debugging info, 0 is none, 1 is more, 2 is more still
	# setting debug to other than 0 should imply no daemon mode

ldap_port = 389	# the TCP port to listen to for LDAP v2 bind requests (default is 389)
ldap_basedn = ou=People	# an optional base distinguished name to check incoming binds against

[backend]	# this is the start of a backend definition
protocol = ldapv2 # this value is case-insensitive, so LDAPv2 is equivalent
server = liskov.anu.edu.au	# the name of the ldap server
port = 389	# optional port number (defaults to 389)
basedn = ou=People,dc=comp3310,dc=anu,dc=edu,dc=au	# the base distinguished name to use

[backend] # the start of another (optional) backend definition
protocol = ldapv2
...

An example parser is now available at parser.tgz.

Implementation

Your assignment code should start up and read it's configuration file and start listening for front-end requests. For each incoming connection, it should fork(2) a child process to process that request. The child process(es) should use the select(2) facility to multiplex communications between the client application and the backend server(s).

If more than one backend is specified, the child process can check the supplied username/password against each until a positive match is found.

The child process can use the libldap2 functions such as ldap_init(3) and ldap_bind(3) or friends - see man ldap(3), or you can simply "hand-craft" the appropriate packets to send to the LDAP back-end server.

You can also use the Basic Encoding Rules (BER) library to decode and encode the LDAP messages. See the appropriate man pages for details, for example: man lber-decode, man lber-encode etc.

Testing

An LDAP authentication server has been set up for the purposes of this assignment on the host "liskov.anu.edu.au" on port 389. This server can authenticate 10 users: "user0" through "user9". Each user's password is "network0" through "network9" respectively. The base Distinguished Name is "ou=People,dc=comp3310,dc=anu,dc=edu,dc=au".

An IPv6 LDAP authentication server will be set up in a week or so with some additional users. In the meantime, if you need to use an additional server, you can use:

• csitldap.anu.edu.au
• csitstuddc.anu.edu.au

Testing the authentication can be done with the ldapsearch command, using the -x and -W command-line flags:

ldapsearch -h liskov -x -W -D uid=user1,ou=People,dc=comp3310,dc=anu,dc=edu,dc=au \
 -b ou=People,dc=comp3310,dc=anu,dc=edu,dc=au uid=user1 1.1

See the manpage for ldapsearch(1).

Additional tasks

Only after the proxy is tested and working can one or more of the additional tasks be attempted for bonus marks.

Memory Cache - 3 marks - required for COMP6331 students

This additional task is to implement a memory cache. Two additional parameters are added to the configuration file:

cache_hit_ttl = 300	# number of seconds to cache a positive entry
cache_miss_ttl = 30	# number of seconds to cache a negative entry

Before contacting any backends, the proxy should check the supplied username/password against it's own cache. For purposes of this assignment, the cache can limit the size of usernames and passwords to 12 characters each. The time that an entry is added to the cache also needs to be checked, and if expired, then the regular contacting of the backends should occur.

The cache should contain both positive and negative results.

Some limit should be implemented on the amount of memory resources that the cache consumes.

Rate throttling - 2 marks

This extension is actually an extension of the memory cache (above). Don't attempt this until you have the memory cache extension working.

Add increasing delays for negative matches. This would frustrate a would-be password "cracker" who is attempting "brute-force" attacks on the authentication system.

Secure Socket Layer (SSL) - 2 marks

Add a new (second) front end that listens on a given port specified in the configuration file:

SSL_PORT = 3310

and expects a message in the form: "username\tpassword\n", where '\t' is a TAB character (ASCII code 9) and '\n' is a newline. It should perform the authentication steps as for an LDAP bind (if you have implemented the memory cache, use that) and respond with "SUCCESS\n" or "FAILURE\n" as appopriate, then close down the connection.

You will also need to write a little test program to send usernames/passwords over an SSL connection to your new front-end.

Marks

This assignment is to be done in groups of no more than 2.

The assignment is worth 20% of final assessment. Both members of each group will receive the same mark unless there is clear evidence of non-performance of one member of the group, in which case both members may need to explain in person their contribution to the assignment.

For COMP3310 students, the main part of the assignment is worth the full 20%. The bonus parts are worth additional marks, but the combined mark for both assignments and quizzes shall not exceed 40%.

For COMP6331 students, the main part of the assignment is worth 15% and the first memory caching part is worth 5% (of final assessment). The other additional tasks are worth the additional marks indicated, but cannot be attempted until the memory cache is implemented and tested.

Submission

This assignment is due by 5:00pm on Friday 28th May, 2010 (end of week 12).

Submission Details:

We will be using the Subversion (SVN) Source Code Management (SCM) system to develop this assignment. There will be one SVN repository set up for each group. Both members of each group are required to make "commits" to their respective SVN repository as evidence of their contribution to the assignment. I expect to see many versions (minimum 10) of each groups work by the submission date.

Clearly list in a file "versions.txt" in the top of your SVN repository the version number of the final version for the main assignment and for each of any of the additional tasks undertaken.

E-mail me (bob@cs.anu.edu.au) with the student IDs of your group members when you know them, and I will create a repository for your group and send you the name and URL etc.

In your repository there will be some skeleton files: authproxy.c and Makefile as well as the parser code. You are to edit these files and to add other files as required to your repository. You must include a README file (in plain text) with information about how your code works and how to use it.

By assignment deadline, you should be able to check out your repository into a clean area, type "make" and expect a working version of the main assignment to be compiled called "authproxy"

Subversion is well-documented at: http://svnbook.red-bean.com/en/1.5/index.html.