 |
From "Security in Computing": read Sections 7.1--7.4.
From "Security in Computing": read Sections 6.1--6.4.
Design a combined packet-filter and proxy firewall for Friendly Research Inc., a generic research laboratory. The laboratory owns a class C network (12.34.56.0). As the company name suggests, this company prefers a relatively open environment. Your design document should include:
Obviously, the filtering rules, combined with the configuration of proxies, should implement the given security policies. Auditing should also be coordinated with those policies.
From "Security in Computing": read Section 9.5.
Read RCF 2401.
Read RCF 2246, focusing on Section 6 and Section 7.
Implement a pair of programs: sslc and ssls that together realize a secure tunnel based on SSL. sslc is the `entrance' of the tunnel, while ssls is the `remote endpoint' of the tunnel. The synopsis of sslc and ssls are as follows:
sslc local-port ssls-host ssls-port remote-host remote-port [certificate priv-key]
ssls ssls-port [subject . . . ]
the parameters are:
The architecture of the tunnel is shown below:
|
It is not required that sslc and ssls handle multiple tunnels at the same time.
The authentication of clients is performed on the basis of their names (i.e., their subject name as shown in their certificate). ssls will accept (SSL) connections from those clients whose subject name `matches' at least one of the subject parameters. For simplicity, a subject name matches a subject parameter if that parameter appears as a substring of that subject name. Remember that subject names are usually strings of the form /C=. . . /ST=. . . /\dots.
For example: a client presenting a certificate with the following subject name:
/C=US/ST=Colorado/L=Boulder/O=University of Colorado/OU=Dept. of Computer Science/CN=Antonio Carzaniga/[email protected]
would be correctly authenticated by a subject parameter such as Anto or Colorado.
A client will be set up to send its certificate whenever both certificate priv-key parameters are given.
Obviously you should use a third-party implementation of SSL. If you use C/C++, please use the OpenSSL library. If you use Java then you may use any implementation, provided that it is compatible with Sun's JDK 1.3.x.
You must turn in your assignment in a single package, in the form of a TAR file (possibly compressed with gzip) or a ZIP file. Please include the following in your package:
Please send the package as a MIME-compatible attachment to [email protected].
Set yourself up to communicate using PGP and SSL.
Set up public/private key pair for use with PGP. Set up a public/private key pair for use with SSL. Also obtain certificates for all your keys. For your convenience, I (the instructor) will act as a certification authority, so send your certification requests by e-mail to [email protected], or for better security, hand them to be personally on a floppy (during office hours).
Note: complete this part of the assignment before Friday October 19.
After Oct 19, I will distribute certificates to the class. At that point, add everybody else's public key to your PGP key ring.
Implement a program mac that creates and verifies message authentication codes (MAC) for existing documents. The synopsis of mac is the following:
mac -c|-v filename
The first parameter determines whether the program works in create mode or verify mode.
In create mode, the program reads file filename from disk, reads the necessary key(s) from direct user input (keyboard input), and writes a message authentication code for the given file into another file. The name of the output file is obtained by appending the suffix .mac to the original file name. The following is a usage example:
> ls foo.txt > mac -c foo.txt Password: xxxxxxxxxx > ls foo.txt foo.txt.mac >
In verify mode, the program reads filename and filename.mac from disk. The program also reads the necessary key(s) from user's input, and verifies the integrity and authenticity of filename, printing an appropriate success or failure message. Example:
> ls foo.txt foo.txt.mac > mac -v foo.txt Password: xxxxxxxxxx Ok! >
Use whatever (secure) message authentication method you prefer. Use either C/C++ or Java for your implementation. Do not implement any hash, symmetric, or public-key encryption function yourself. Instead, find the necessary implementations on the net. Also, write a README file (an ASCII text file) with a brief description of your program and with references to the external libraries you used.
Package the complete source code, including your source files, the README file, sources or binaries for the cryptographic functions you used, and any other necessary file (makefile, config files, etc.) into a ZIP or TAR archive file, and send that archive file as a MIME attachment to [email protected] before 11:00am on October 2 2001.
From "Security in Computing": read Section 3.4, finish reading Chapter 4 (pp. 144-172), and read Section 9.3.
You may also want to consult the following reading material:
foo.txt,
a file bar.txt, an executable prog.exe,
and a special output device /dev/special, that can
not be represented within the Unix-style user/profile
access control model. In doing that, feel free to make all the
necessary assumptions about the functionality of
prog.exe and /dev/special and the
potential relations to files foo.txt and
bar.txt. For example, you may assume that
prog.exe needs write access on
/dev/special and read access on a file.
sudo tool, and write
a configuration file for sudo that realizes the
access control policy you specified for the previous exercise.
sudo documentation: web page, sudo manual page, and configuration file manual page
From "Security in Computing": read intro to Chapter 2, sections 2.1, 2.2 up to page 48, 2.7, 2.8, 2.9, intro to Chapter 3, sections 3.1, 3.3, 3.7, 3.8, 3.9, 3.11, and Chapter 4 up to page 144.
Due date: Thursday, August 30th, at 10:00 MDT.
this page is maintained by Antonio Carzaniga,
$Date: 2002/02/01 16:30:05 $