Lab2Prfc

Lab 2 PRFC: Secure Layer PRFC

Assigned	4/15/2019
Due	4/17/2019
Points	70

Overview

For this assignment, you need to create a PRFC (Playground RFC) to specify a protocol that provides a secure authenticated channel between endpoints.

Requirements:

1. Create a PRFC source file in XML that is renderable with xml2prfc.tcl
2. Your document must identify a name for the protocol (in years past, we've had KISS and other fun acronyms)
3. Describe all the necessary cryptography to establish a "secure authenticated channel."

In other words, two nodes that use the proposed protocol should be assured that

1. They know the identity of the other party (mutual authentication)
2. Once authenticated, subsequent transmissions can be proved to have come from the two parties (authenticity of data)
3. Once authenticated, only the two parties can read the transmitted data (confidentiality of data)
4. Once authenticated, the communications cannot be undetectably altered, dropped, or reordered (message integrity of data)

We discussed in class two basic ways to do this: TLS and Kerberos. You may use either of these protocols for inspiration, or you may try something simpler, more complicated, or completely different.

As a reminder, the basic approach to TLS is this (I'll describe a mutual authentication approach):

1. Both sides exchange some random numbers and some certificates
2. Both sides confirm that the certificate is trusted or signed by a trusted authority
3. Both sides prove ownership of the private key by signing data (typically including the random number to prevent replay)
4. Both sides either agree on a base key using Diffie Hellman or the client transports a base key using the server's RSA public key to encrypt it
5. Both sides derive all necessary keys, IV's, etc using this base key using a Key Derivation Function (KDF)
6. Both sides can now communicate using something like AESCTR + HMAC or AESGCM providing all other necessary guarantees.

Alternatively, Kerberos uses a trusted authority which must be online.

1. Alice contacts the KDC with her identity ('alice')
2. The KDC shares a secret with Alice and sends her data encrypted by the shared secret
3. The data sent to Alice includes data encrypted for a "Ticket Granting Service" (Alice can't decrypt it)
4. Alice forwards this encrypted data to the TGS along with her own data (including that she wants to talk to Bob)
5. The TGS decrypts the data and confirms that it matches expected values
6. The TGS sends back data encrypted for Alice and data encrypted for Bob to Alice. The data includes a session key for using AESCTR+HMAC or AESGCM, etc
7. Alice sends the encrypted data to Bob
8. Bob decrypts the data and now both Alice and Bob have session keys

Please note that almost all of the effort in all of these steps is in authentication. The rest of the properties (confidentiality, authenticity, and message integrity) are relatively easy by comparison. AESGCM provides for confidentiality, authenticity, and message integrity assuming you trust the session key!

In short, both TLS and Kerberos are focused on getting a session key to both parties that enable both parties to trust it.

As you write up your PRFC, your primary job is explaining how both sides get the session key using assymetric authentication (such as TLS) or symmetric shared secrets using a trusted third party (like Kereberos). Or, you might propose something completely different!

Important Note 1: Key Derivation and Session Keys

Although we talk about getting each side a "key", the truth is we usually get each side a base key, or master key, that other keys are derived from using a Key Derivation Function. Remember that in TLS, both sides need a read key and a write key and an IV. If a separate MAC function is being used (e.g., HMAC), both sides also need a read MAC key and a write MAC key.

All of these keys are derived from one master key. TLS uses a TLS-specific Key Derivation Function, but if you search for Key Derivation Function, you'll see that there are many standard ones, including ones available in the python cryptography module we'll be using.

Important Note 2: Python Cryptography Module

If you remember, to use the bank, you had to import a cryptography module. You can find documentation here:

https://cryptography.io/en/latest/

You probably won't need much of this in the PRFC, but if you wanted to write sample code, please us this. For example, here's some sample code from the cryptography module about doing diffie hellman

https://cryptography.io/en/latest/hazmat/primitives/asymmetric/dh/

If you write sample code, please use this module

Important Note 3: Identities

Whether you create something like TLS, something like KErberos, or something entirely different, a secure authenticated channel requires identities.

For purposes of this class, the only identity we'll be using are Playground Addresses. So, for example, 20191.0.1.1 is an identity for purposes of your algorithm. On the real Internet, this wouldn't be super helpful. But on Playground, each group has an assigned block of addresses. If somebody "attacks" somebody else from an address, that group can be held responsible!

If you chose to use certificates (for a TLS-like algorithm), each group will get an intermediate authority CA. So, if your group is group 1, you'll get the cert for 20191.1. That CA can sign certificates for any 20191.1.* certificates.

If you chose to use something like Kerberos, you can choose a number of different approaches, but the easiest one is just to do like real Kerberos and have an actual login name, but only certain login names are allowed to use certain source addresses (e.g., if Alice logs in, and Alice is part of group 1, Kerberos requires that Alice be using a 20191.1.* address). When the data is sent to the server, it includes alice's allowed playground address.

Background reading

You should probably review my slides about TLS and Kerberos. Also, the Wikipedia pages are pretty helpful.

Grading

Your Lab #2 PRFC will be graded out of 70 points according to the following schedule:

50 Points for addressing all necessary issues. You MUST address the following:

• Authentication
  • How are identities established?
  • How are identities verified?
  • How is trust established?
  • How does a party prove identity to another?
• Key exchange or key transport
• Parameters such as crypto parameters
• Error handling
• Crypto teardown (this one is optional... may not be required)
• SECURITY CONSIDERATIONS (e.g., not reusing a key, etc)

10 Points for thoroughness. We (the grading staff) will make a judgement as to how well someone could use your PRFC to implement a compliant protocol.

10 Points for grammar, correct punctuation, etc.