CS4180 Network Security (Fall 2000): Homework 6

This homework is due on Monday, December 11, 2000. Note: K2.3 denotes homework problem 3 from chapter 2 of the class text.

You are to built a secure web "browser" and server using Lamport's hash for authentication, building on the web proxy server that you programmed in the first assignment. Implement OTP (RFC 2289), using the MD5 implementation from RFC 1321 or the Java implementation in JDK 1.1.7 and up. You have to support password entry in hexadecimal only (without embedded white space); do not worry about the dictionary in appendix D of the OTP draft and do not implement the alternate dictionary described in the section labeled GENERATOR ENCODING USING AN ALTERNATE DICTIONARY and following. (FYI only: See also OTP extensions, RFC 2243).
Retrieval works as follows:
1. Your web client sends a normal, unauthenticated request to the web server.
2. The web server looks for a header labeled Authorization. If it doesn't find one, it returns something like
```
  HTTP/1.0 401 Unauthorized
  WWW-Authenticate: otp-md5 487 dog2
```
  where "487" is the sequence integer and "dog2" the seed. (In a real system, the syntax would be slightly more complicated, but this format is simpler to parse.)
3. The web client retries the same request, but this time with an Authorization header:
```
  GET file HTTP/1.0
  Authorization: otp-md5 3503785b369cda8b
```
  You might be able to use 64-bit integers directly to scanf() this value.
4. If the authentication succeeds, the web server returns the document and updates its internal value of n. If the authentication fails, it returns the same 401 response as above. In that case, the client displays an error message to stderr and aborts.
Your system consists of a very basic web client, a web server and a hash generator:
Web server:
The server should accept several connections in a row (not simultaneously), but doesn't have to store the Lamport "state" on disk. The server takes the port number, the initial value n (as a decimal integer), and the hashed password (as a hexadecimal integer), as arguments:
```
server port hashⁿ(password) n seed
```
For example:
```
server 8080 hashⁿ(password) n seed
```
The server does not have to maintain connections across requests. It simply retrieves files relative to the current directory. It does not have to set the Content-Type header.
Web client:
The client uses the following command line:
```
client password url (without http://)
```
For example,
```
client stalebeer dog2 rome.clic.columbia.edu:8080/example.txt
```
The client simply displays the response body to stdout, without attempting to render HTML or other content types. The server is expected to close the connection after delivering the document. The emphasis is on the authentication system, not replicating details of a web server or client, although it may be useful to be able to test your client against a real web server.
Hash generator:
A third program is used to generate the 'hashⁿ()' value given a password and seed and prints it to standard output, in hexadecimal format, to be used by the web server:
```
lamport password n seed
```
(35 pts.)
Draw a message flow diagram for an authentication in Kerberos V5 between alice@cs.columbia.edu and bob@cs.harvard.edu, where each CS department, the University, and the Department of Education runs a hierarchy of KDCs, as explained in class and the text. Be sure to indicate whose key is being used to encrypt various quantities and what value is contained in the TRANSITED field of the tickets. Use the message names in Section 11.14. (10 pts.)
Draw the Kerberos V5 message flow for getting an initial ticket and renewing a ticket (either TGT or regular), again using the message names of Section 11.14. (10 pts.)
Generate an X.509 certificate for yourself and display it using the Certificate Viewer (or a web plugin - warning: it crashes Netscape on Solaris) and unber, the ASN.1 decoder. You also need the file oid.dat.
You can convert PEM/base-64 encoded data, as returned, for example, by Jimmie Joe Bob's Pork Products and Certificate Authority using juju (already installed on Columbia CS systems). (10 pts.)
(K10.1) Design a variant of Kerberos in which the workstation generates a TGT. The TGT will be encrypted with the user's master key rather than the KDC's master key. How does this compare with standard Kerberos in terms of efficiency, security, etc.? What happens in each scheme if the user changes her password during a login session? (10 pts.)
(K10.3) Why is the authenticator field not of security benefit when asking the KDC for a ticket for Bob, but useful when logging into Bob? (10 pts.)
(K10.5) With CBC, if one ciphertext block is lost, how many plaintext blocks are lost? With PCBC, why do things get back in sync if c_n and c_n+1 are switched? How about if a ciphertext block is lost? How about if ciphertext block n is switched with ciphertext block n+2? How about any permutation of the first n blocks? (15 pts.)

Last updated by Henning Schulzrinne