Needham-Schroeder protocol

From Wikipedia, the free encyclopedia

(Redirected from Needham-Schroeder)
Jump to: navigation, search

The term Needham-Schroeder protocol can refer to one of two communication protocols intended for use over an insecure network, both proposed by Roger Needham and Michael Schroeder in a paper in 1978. These are:

  • The Needham-Schroeder Symmetric Key Protocol is based on a symmetric encryption algorithm. It forms the basis for the Kerberos protocol. This protocol aims to establish a session key between two parties on a network, typically to protect further communication.
  • The Needham-Schroeder Public-Key Protocol, based on public-key cryptography. This is intended to provide mutual authentication between two parties communicating on a network, but in its proposed form it is insecure.

Contents

Here, Alice (A) initiates the communication to Bob (B). Also,

  • S is a server trusted by both parties
  • KAS is a symmetric key known only to A and S
  • KBS is a symmetric key known only to B and S
  • NA and NB are nonces

The protocol can be specified as follows in security protocol notation:

A \rightarrow S: A,B,N_A

Alice sends a message to the server identifying herself and Bob, telling the server she wants to communicate with Bob.

S \rightarrow A: \{N_A, K_{AB}, B, \{K_{AB}, A\}_{K_{BS}}\}_{K_{AS}}

The server generates KAB and sends back to Alice a copy encrypted under KBS for Alice to forward to Bob and also a copy for Alice. Since Alice may be requesting keys for several different people, the nonce assures Alice that the message is fresh and that the server is replying to that particular message and the inclusion of Bob's name tells Alice who she is to share this key with.

A \rightarrow B: \{K_{AB}, A\}_{K_{BS}}

Alice forwards the key to Bob who can decrypt it with the key he shares with the server, thus authenticating the data.

B \rightarrow A: \{N_B\}_{K_{AB}}

Bob sends Alice a nonce encrypted under KAB to show that he has the key.

A \rightarrow B: \{N_B-1\}_{K_{AB}}

Alice performs a simple operation on the nonce, re-encrypts it and sends it back verifying that she is still alive and that she holds the key.

The protocol is vulnerable to a replay attack. If an attacker records one run of this protocol, then subsequently learns the value KAB used, she can then replay the message \{K_{AB}, A\}_{K_{BS}} to Bob, who will accept it, being unable to tell that the key is not fresh. This flaw is fixed in the Kerberos protocol by the inclusion of a timestamp.

This assumes the use of a public-key encryption algorithm.

Here, Alice (A) and Bob (B) use a trusted server (S) to distribute public keys on request. These keys are:

  • KPA and KSA, respectively public and private halves of an encryption key-pair belonging to A
  • KPB and KSB, similar belonging to B
  • KPS and KSS, similar belonging to S. (Note this has the property that KSS is used to encrypt and KPS to decrypt).

The protocol runs as follows:

A \rightarrow S: A, B

A requests B's public keys from S

S \rightarrow A: \{K_{PB}, B\}_{K_{SS}}

S responds. B's identity is placed alongside KPB for confirmation.

A \rightarrow B: \{N_A, A\}_{K_{PB}}

A invents NA and sends it to B.

B \rightarrow S: B, A

B requests A's public keys.

S \rightarrow B: \{K_{PA}, A\}_{K_{SS}}

Server responds.

B \rightarrow A: \{N_A, N_B\}_{K_{PA}}

B invents NB, and sends it to A along with NA to prove ability to decrypt with KSB.

A \rightarrow B: \{N_B\}_{K_{PB}}

A confirms NB to B, to prove ability to decrypt with KSA

At the end of the protocol, A and B know each other's identities, and know both NA and NB. These nonces are not known to eavesdroppers.

Unfortunately, this protocol is vulnerable to a man-in-the-middle attack. If an impostor I can persuade A to initiate a session with him, he can relay the messages to B and convince B that he is communicating with A.

Ignoring the traffic to and from S, which is unchanged, the attack runs as follows:

A \rightarrow I: \{N_A, A\}_{K_{PI}}

A sends NA to I, who decrypts the message with KSI

I \rightarrow B: \{N_A, A\}_{K_{PB}}

I relays the message to B, pretending that A is communicating

B \rightarrow I: \{N_A, N_B\}_{K_{PA}}

B sends NB

I \rightarrow A: \{N_A, N_B\}_{K_{PA}}

I relays it to A

A \rightarrow I: \{N_B\}_{K_{PI}}

A decrypts NB and confirms it to I, who learns it

I \rightarrow B: \{N_B\}_{K_{PB}}

I re-encrypts NB, and convinces B that he's decrypted it

At the end of the attack, B falsely believes that A is communicating with him, and that NA and NB are known only to A and B.

The attack was first described in a 1995 paper by Gavin Lowe.[1] The paper also describes a fixed version of the scheme, referred to as the Needham-Schroeder-Lowe protocol. The fix involves the modification of message six, that is we replace:

B \rightarrow A: \{N_A, N_B\}_{K_{PA}}

with the fixed version:

B \rightarrow A: \{N_A, N_B, B\}_{K_{PA}}

  • Roger Needham and Michael Schroeder. Using encryption for authentication in large networks of computers. Communications of the ACM, 21(12), December 1978.
  • Gavin Lowe. An attack on the Needham-Schroeder public key authentication protocol. Information Processing Letters, 56(3):131--136, November 1995.
Retrieved from "http://en.wikipedia.org/wiki/Needham-Schroeder_protocol"
Advanced Search
Included Web Search Engines


Safe Search

close

Top Matching Results

Occasionally Search.com will highlight specialized results that are based on the context of your query. Examples of specialized results include specific links to news, images, or video.

Top Matching Results may highlight information from other Search.com pages, content from the CNET Network of sites, or third party content. The listings are based purely on relevance. Search.com does not receive payment for listings in this section but our partners that provide this data may get paid for listing these products.

Sponsored Links

This section contains paid listings which have been purchased by companies that want to have their sites appear for specific search terms and related content. These listings are administered, sorted and maintained by a third party and are not endorsed by Search.com.

Search Results

Search.com sends your search query to several search engines at one time and integrates the results into one list which has been sorted by relevance using Search.com's proprietary algorithm. You can customize the list of search engines included in your metasearch from the preferences.

The search engines that are used in your metasearch may allow companies to pay to have their Web sites included within the results. To view the Paid Inclusion policy for a specific search engine, please visit their Web site. Search.com does not accept payment or share revenue with any search engine partner for listings in this section.