Cryptography - Authentication Protocols, Kerberos

Objectives

Authentication Protocols

1. Authentication Protocols
   • have discussed hash algorithms and digital signatures in abstract
   • apart from direct use in signing messages
   • another key use is in mutual authentication
   • for convincing 2 parties of each others identity and for exchanging session keys
   • these are known as authentication protocols
2. Security Concerns with Authentication Protocols
   • key concerns are confidentiality and timeliness
   • to provide confidentiality must encrypt identification and session key info
   • which requires the use of previously shared private or public keys
   • need timeliness to prevent replay attacks
   • provided by using sequence numbers or timestamps or challenge/response

     In order to use the various cryptographic algorithms, need to have or be able to negotiate the right keys. This means knowing the identity of the parties adn performing a suitable key distribution. Have to be careful that the protocol is not subject to a "replay" attack, whereby the exchange is recorded by an attacker, and then subsequently reused to fool the recipient into believing they're communicating with someone else.

3. Timeliness Using Sequence Numbers
   • if each message is numbered in order can detect replays
   • requires maintenance of last number used with each party
   • this overhead is usually too high in this usage

     A commonly used technique in network protocols is to include a sequence number on each message. This works fine in limited time periods for a limited number of conversations, but doesn't scale well to long period many party use.

4. Timestamps
   • if each message contains a timestamp can detect replays
   • because clocks are never identical must allow a window
   • within window can't detect replay
   • keeping clocks synchronised is a major issue and overhead
   • also forms another avenue of attack (jigger clock then attack auth)

     The "obvious" way to overcome replays is to include the "time" in the message. Unfortunately time is a fluid value, and not all computer clocks are the same. Which means that some way of keeping clocks in sync is needed, and even then there must be a small window to allow for drift. So its not a perfect solution.

5. Challenge-Response
   • basic technique to validate identity
   • given a client and a server share a key
     • server sends a random challenge vector
     • client encrypts it with private key and returns this
     • server verifies response with copy of private key
   • can repeat protocol in other direction to authenticate server to client (2-way authentication)
   • in simplest form, keys are physically distributed before secure comminications is required
   • in more complex forms, keys are stored in a central trusted key server

     This is the core of many authentication protocols, its use convinces one party that the other must have the same secret info (key) it knows, without having to actually send that key, which could be snooped. If repeated the other way, both parties can be convinced that the other knows the info.

6. Needham-Schroeder Protocol
   • original third-party key distribution protocol
   • for use with private key algorithms
   • when want to use a trusted key server to negotiate session keys
   • after this protocol runs, Alice and Bob share a secret session key K_ab for secure communication
   • cf. R M Needham, M D Schroeder, "Using Encryption for Authentication in Large Networks of Computers", CACM, 21(12), Dec 1978, pp993-998

     The original, basic key exchange protocol. Used by 2 parties who both trusted a common key server, it gives one party the info needed to establish a session key with the other. Note that since the key server chooses the session key, it is capable of reading/forging any messages between A&B, which is why they need to trust it absolutely!

7. Needham-Schroeder Protocol
   • given Alice wants to communicate with Bob, and have a Key Server S, protocol is:

     Message 1	A -> S	A, B, Na 
     Message 2	S -> A	EKas{Na , B, Kab, EKbs{Kab, A} } 
     Message 3	A -> B	EKbs{Kab, A}
     Message 4	B -> A	EKab{Nb}
     Message 5	A-> B	EKab{Nb-1}
     
     nb: Na is a random value chosen by Alice,
         Nb random chosen by Bob
     

     Note that all communications is between A&S and A&B, B&S don't talk directly (though indirectly a message passes from S via A to B, encrypted in B's key so that A is unable to read or alter it). Other variations of key distribution protocols can involve direct communications between B&S.

8. Needham-Schroeder Protocol Flaw
   • unfortunately this protocol includes a fatal flaw:
   • Message3 can be subject to a replay attack with an old compromised session key by an active attacker
   • this has been corrected either by:
     • including a timestamp in messages 1 to 3, which requires synchronised clocks (Denning & Sacco 81)
     • having A ask B for a random value Jb to be sent to S for return in E_Kbs{Kab, A, Jb} (Needham & Schroeder 87)
   • many other key exchange protocols exist but care is needed .

     There is a critical flaw in the protocol, as shown. This emphasises the need to be extremely careful in codifying assumptions, and tracking the timeliness of the flow of info in protocols. Designing secure protocols is not easy, and should not be done lightly. Great care and analysis is needed.

Kerberos - An Example of a Key Server

1. Authentication Key Server
   • for private-key authentication
   • have an on-line server trusted by all clients
   • server has a unique secret key shared with each client
   • server negotiates keys on behalf of clients
   • use private key encryption

     Here use a trusted intermediary, whom all parties trust, to mediate the establishment of secure communications between them. Must trust intermediary not to abuse the knowledge of all session keys.

2. Kerberos - An Example of a Key Server
   • a trusted key server system developed by MIT
   • provides centralised third-party authentication in a distributed network
   • access control may be provided for
     • each computing resource
     • in either a local or remote network (realm)
   • has a Key Distribution Centre (KDC), containing a database of:
     • principles (customers and services)
     • encryption keys

     One of the best known and most widely implemented trusted third party key distribution systems. Still mostly limited to use within a single organisation though.

3. Kerberos Overview
   • a basic third-party authentication scheme
   • KDC provides non-corruptible authentication credentials (tickets or tokens)
   • user initially negotiates with KDC to identify self
   • can subsequently request access to other services

     

4. Kerberos - Initial User Authentication
   • user requests an initial ticket from KDC
   • used as basis for all remote access requests

     

5. Kerberos - Request for a Remote Service
   • user requests access to a remote service
   • obtains a ticket from KDC protected with remote key
   • sends ticket with request to remote server

     

6. Kerberos - in practise
   • currently have two Kerberos versions
     • 4 : restricted to a single realm
     • 5 : allows inter-realm authentication, in beta test
   • Kerberos v5 is an Internet standard
   • specified in RFC1510, and used by many utilities
   • to use Kerberos
     • need to have a KDC on your network
     • need to have Kerberised applications running on all participating systems
   • major problem - US export restrictions
     • Kerberos cannot be directly distributed outside the US in source format (& binary versions must obscure crypto routine entry points and have no encryption)
     • else crypto libraries must be reimplemented locally