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:
- Your web client sends a normal, unauthenticated request to the web
- 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.)
- The web client retries the same request, but this time with an
GET file HTTP/1.0
Authorization: otp-md5 3503785b369cda8b
You might be able to use 64-bit integers directly to scanf() this value.
- 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
- 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
server port hashn(password) n seed
server 8080 hashn(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://)
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 'hashn()' 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
- Draw a message flow diagram for an authentication in Kerberos V5
between email@example.com and firstname.lastname@example.org, 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
- 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
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).
- (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?
- (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?
- (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
cn and cn+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?
by Henning Schulzrinne