U4.9 Needham–Schroeder protocol

U4.9 Needham–Schroeder protocol

1. The Needham–Schroeder protocol process Simplified

   • In messages 1 and 2, Alice and Trent communicate
     • Alice gets a session key K from Trent and a copy of that session key for Bob
       • Alice and Trent make use of Alice's long-term key KA,T in this interaction
         • In message 3, Alice forwards to Bob his copy of the session key. This message is protected using Bob's long-term key KB,T.
           • In messages 4 and 5, Bob authenticates Alice using a challenge–response, encryption-based protocol. The session key K is used in this protocol.
             • At the end of the protocol, Alice and Bob have shared a session key K, and Alice is authenticated to Bob.

2. Properties of NSP

   • Trent is authenticated to Alice in messages 1 and 2 (using nonces and encryption). This assures Alice that message 2 is not a replay and contains a freshly generated session key K for her and Bob to use.
   • Trent generates the session key K. generating randomness is hard and leaving it to Trent is better than requiring users to generate their own session keys.
   • Alice is not authenticated to Trent, but Mallory gains nothing by impersonating Alice in message 1: all he gets back is a message encrypted under a key KA,T, which he does not know. At worst, Mallory can force Trent to do some cryptographic processing. This could yield a denial-of-service attack on the protocol.
   • Alice is authenticated to Bob in messages 3, 4 and 5, but Bob is not authenticated to Alice. For Mallory, pretending to be Bob in message 4, can simply send Alice a random string of bits. Alice will interpret this as an encrypted nonce and reply as usual in message 5. Of course Mallory does not learn the session key in this attack, but he does fool Alice.

3. Adding mutual authentication

   • Alice could include a nonce N'A in message 3, and Bob could respond with the encryption of this nonce in message 4
     • Alternatively, Bob could add some redundancy to message 4 allowing Alice to be sure it came from someone who knows K.

4. Pros

   • Key management: for a system with n users, there are only n keys to look after at the KDC, Trent. Of course, these keys needed to be carefully guarded at the KDC. There is only one long-term key to be looked after at each client, instead of the n–1 that would be needed in a system without a KDC.
   • Use of symmetric key cryptography: the protocol only uses symmetric key cryptography, so it is reasonably efficient to implement. The communication overheads of the protocol are low – the messages are all reasonably short.
   • Caching: Bob can be off-line in messages 1 and 2 because the KDC doesn’t forward session key K directly to Bob. Instead, Alice relays it to Bob in message 3. So K can be cached by Alice and used later, at Alice's convenience.

5. Cons

   • he KDC is a single point of failure in the system. If the KDC becomes unavailable then none of the system's users can agree session keys. If the security of the KDC is compromised then the security of the entire system is destroyed.
   • All protocol runs must involve the KDC. The KDC is therefore a potential computation/communication bottleneck in the system
   • The security of the system still relies on users looking after their long-term keys KA,T properly. If such a key is compromised, then entity A can be impersonated to any other entity.
   • The long-term keys need to be distributed securely to the users of the system.
   • And of course, the KDC must be trusted not to exploit its knowledge of the long-term keys by impersonating users to one another, or to eavesdrop on communications between users.