A1 - CS 596 Network Security			due at the start of the midterm

The SSKP Protocol (Symmetric Session-Key Protocol) Assignment overview
-------------------------------------------------------------------------

Using C,  TCP-based sockets, UNIX, and the client-server mechanism a la
the second assignment in my CS 594 TCP/IP Internetworking class, the
goal is to design a secure ("less-insecure") session-key based protocol
using only symmetric key-based algorithms.  The primary goal here is
the design of a secure cryptographic protocol that provides minimally
the following properties:

1. encryption of data
2. authentication of data
3. integrity of data

4. In addition the protocol design should be done in such a way
that shared symmetric secrets (possibly barring authentication)
are minimally exposed.  In general, you want to produce a session
key or session-keys and use those keys instead.  (Note for 
crypto-nuts: PFS is not a requirement). 

5. The protocol should be designed so that the "current" algorithms
used (DES and MD5) can in the future be replaced with new better
algorithms (say AES and HMAC-SHA) or even less good algorithms like
ROT13 and a mere checksum algorithm (add the bytes together).

Symmetric-key algorithms:

For the sake of simplicity we will assume that students will use
only the DES encryption algorithm, and the MD5 (or HMAC-MD5) algorithms.
Our goal is to take symmetric key algorithms (not public-key...)
and produce a session-key based protocol.  Put another way,
these functions are easy to understand and easy to use -- our goal
is not to get bogged down in cryptography.  You can easily find
DES and MD5 algorithms on the Internet (e.g., in the openssl library in
libcrypto in particular).  Or in the middle of any open-source 
operating system for that matter (related to/in the IPSEC code).

IMPORTANT NOTE: We want to learn how to design this protocol.
Crypto is not the goal.   Real-world security is not the goal.
Cryptographic protocol design that deals with issues of future
change is the goal.  Learning how to use keys in a software design and network 
protocol is the real goal.  Note the recent text from an interesting
IETF draft appended to this document.

Key management:

Thus you may assume that you have two users (a client and a server)
each of which has an a-priori (using briefcase man ...) distributed
MD5 shared secret, and a DES shared secret.   These keys should
be stored in a file, and read at application boot-time.  The keys
need not be encrypted though.

Deliverables:

Using both email, and paper (i.e., turn the assignment in twice,
once on printed paper at class time, and once via a shar archive or tar blob
attachment) turn in the following documents.

1. a well written design and protocol description.  This should 
outline how your protocol works in terms of the header design, 
any key management issues, protocol key exchange, and secure packet exchange.  
This document should be done in ASCII.  Let's call it protocol.txt.
This document will be read first and will be a major input for
any possible grade you receive.

2. C code and Makefile.  There should also be a system.txt file
that states what Operating System you build this on (acceptable
O.S. include solaris, Linux, FreeBSD, OpenBSD).

The "key" to this assignment is a good protocol design.
The protocol design should allow for easy change of the underlying
algorithms; i.e., the design of the fields in the packets should
allow for this.

------------------------------------------------------------------------
... quoting from

IETF draft-hoffman-hash-attacks-00.txt
 
   One of us (Bruce) believes that everyone should start migrating to
   SHA-256 [SHA-256] now, due to the weaknesses that have already been
   demonstrated in both MD5 and SHA-1.  There is an old saying inside
   the US National Security Agency (NSA: "Attacks always get better;
   they never get worse." The current collision attacks against MD5 are
   easily done on a single computer; the collision attacks against SHA-1
   are at the far edge of feasibility today, but will only improve with
   time.  It is preferable to migrate to the new hash standard before
   there is a panic, instead of after.  Just as we all migrated from SHA
   to SHA-1 based on some unknown vulnerability discovered inside the
   NSA, we need to migrate from SHA-1 to SHA-256 based on these most
   recent attacks.  SHA-256 has a 256-bit hash length.  This length will
   give us a much larger security margin in the event of newly
   discovered attacks.  Meanwhile, further research inside the
   cryptographic community over the next several years should point to
   further improvements in hash algorithm design, and potentially an
   even more secure hash algorithm.

   The other of us (Paul) believes that this may not be wise for two
   reasons.  First, the collision attacks on current protocols have not
   been shown to have any discernible real-world effects.  Further, it
   is not yet clear which stronger hash algorithm will be a good choice
   for the long term.  Moving from one algorithm to another leads to
   inevitable lack of interoperability and confusion for typical crypto
   users.  (Of course, if any practical attacks are formulated before
   there is community consensus of the properties of the cipher-based
   hash algorithms, Paul would change his opinion to "move to SHA-256
   now".)

   Both authors agree that work should be done to make all Internet
   protocols able to use different hash algorithms with longer hash
   values.  Fortunately, most protocols today already are capable of
   this; those that are not should be fixed soon.