CSSE10-06 - Auburn University

5 downloads 22053 Views 312KB Size Report
accept signatures from those principals who have had their certificates ... This is a very easy and cheap scheme .... provide the basis of digital signatures. Say we ...
Technical Report Number CSSE10-06

Authentication Protocols, Their Issues and Our Solutions Brandon Maharrey Computer Science & Software Engineering Shelby Center for Engineering Technology Suite 3103 Auburn University, AL 36849

[email protected] ABSTRACT Since the beginning of communication over computer networks, there has been the need to authenticate end users, computers or processes, known as principals, before any trustworthy or confidential exchange of information can ever take place. Authentication is the process of proving that claims made by or about a principal are authentic and that no forgery has been made regarding the principal’s claims. Authentication supports privacy protection by ensuring principals verify and validate one another before disclosing any secret information [1]. In computer networks, this refers to proving and/or verifying the identity of a remote principal before giving it any privilege on the system or allowing it usage of any resource. Two end processes exchange authentication factors, pieces of information used to authenticate and/or verify processes’ identity. Generally speaking, there are three different classifiers of authentication factors: 1) Ownership factor, or something the principal has. These can be anything from a cell phone to an ID card to a software/hardware token. If a principal can prove it physically has something in its possession that no one else is assumed to have, the principal can be authenticated. This type of authentication assumes there is some agency involved to keep track of these physical authentication factors at all times. An example could be a company keeping track of which employees have specific hardware tokens and employing the policy that any lost/stolen tokens be reported so that usage of that token on the system is revoked. 2) Knowledge factors, or something the principal knows. These can be anything from a password to a PIN to simple things like a person’s date of birth, city of birth, mother’s maiden name etc. Authentication schemes using knowledge factors assume the principal knows a secret of some sort such that when the principal submits the secret to the authenticating system, the principal is given rights to access or use the system. 3) Inherence factors, or something the principal is or does. These can take on many forms of biometric identifier including but not limited to fingerprint or retinal patterns, DNA sequences and signature or voice information. Other less common authentication factors could include who you know, such as those

which are used in PGP. The basic idea is that principals should accept signatures from those principals who have had their certificates previously signed by other verified and trusted principals. In today’s world of fast-moving technology and explosive growth in numbers of computers on the internet, there has never been a better opportunity for an attacking principal to take advantage of these resources, making authentication protocols more important than ever before. In this paper, I talk about authentication protocols, their issues and some of the solutions computer scientists have discovered to solve their various problems.

General Terms Algorithms, Management, Performance, Design, Reliability, Experimentation, Security, Human Factors, Theory, Verification.

Keywords Authentication, authentication protocols, authentication protocol issues and attacks, knowledge factors, basic cryptography, symmetric and public key cryptography.

1. INTRODUCTION The explosion of the internet has brought more electronic communication than any other time in history. We use the internet for a variety of reasons, each requiring its own degree of privacy and integrity. Less sensitive online activities that generally do not require a high degree of privacy and integrity include playing games, chatting with friends and sharing pictures and videos. There are, however, other situations in which users have the need to feel they have more assurance when it comes to using certain sensitive online services. These more sensitive activities may include online banking or bill paying, secure email and more. How can a user be sure that when she connects to an online service, she is actually connected to exactly who the service says it is? This is where authentication protocols come into play! Authentication is the process of proving that claims made by or about a principal are authentic and that no forgery has been made. Authentication also supports privacy protection by ensuring principals verify and validate one another before any sensitive information is communicated. Authentication protocols can also be used to control access to resources. A company that provides certain services to paying customers wants assurance that no unauthorized (non-paying) customer is able to obtain access to the services it provides. In other words, before the company grants a user access to its

Technical Report Number CSSE10-06 services, the company needs to verify or authenticate the identity of the user. In this type of situation, the company usually assigns some type of identifier, i.e. a username, account number etc, to each user and grants each user a number of privileges. These privileges are linked to individual identifiers. When a user attempts to gain access to the company’s services, the company’s computer systems must verify the authenticity of the claim made by the user that he is authorized to gain access to the system. Once this authentication process takes place, the user is allowed access.

Of the three different widely used authentication factors mentioned so far, the least widely used authentication factor in use today is the inherence factor. Its little use is not due, however, to its authenticating strength. It is one of the most reliable methods of authentication known. Inherence-based authentication relies on something the user is. More specifically, a principal’s finger print, retinal scan or a unique hardware token are examples of inherence factors. It is believed that inherence factors are impossible to forge, and a system that relies on this type of authentication relies on this fact.

1.1 Basic Definitions

A more conservative view of authentication is strong authentication. Strong authentication requires the presentation of two or more authentication factors to the authenticating principal. It is thought that authenticating a principal through the use of multiple authentication factors gives the authenticating principal more assurance the other is actually who he claims to be.

Authentication can be accomplished in many different ways. The most common methods involve the use of authentication factors, pieces of information used to authenticate or verify the identity of an entity or principal. Generally speaking, there are three categories of authentication factors: 

Ownership factor – something the principal has



Knowledge factors – something the principal knows



Inherence factors – something the principal is

The most widely used authentication factor on the internet is, by far, the use of knowledge factors. This is a very easy and cheap scheme to implement as it does not involve costly distribution of secrets by non-electronic means or expensive pieces of hardware. When a principal first creates an account on some internet site, she is asked to present a password. The system stores this password, and the user enters this password on subsequent visits to the site. From the viewpoint of the system, only the actual owner of the account is in possession of the password and so the system authenticates the user based on her knowledge of the correct password. Most systems have a feature that allows the user to change her password in accordance with her wishes. If a password is lost, or the user has some other reason to believe her password has become compromised, she can change her password so that no other user, malicious or otherwise, may gain access to the system under her credentials. Knowledge factors, however, are also the easiest to forge. It only requires the knowledge of the secret. In some cases, it may even be easy to guess the information required for this type of authentication. Undoubtedly the second most widely used authentication factor in use today is ownership factors. Schemes using ownership factors for authentication are considerably more difficult to forge than knowledge-based authentication. Because ownership-based authentication requires something physical a principal has, a system that authenticates based on ownership factors believes only the actual owner is in possession of the object. An example is an ATM card. When you walk up to the ATM machine, you are partly authenticated by the physical card you place into the slot. You are further authenticated with a knowledge factor, your personal identification number (PIN). This is known as twofactor or multi-factor authentication and is considered to be a stronger form of authentication than single-factor authentication. However, this type of authentication factor is generally more expensive than a knowledge-based authentication factor. It requires something special, something not easily produced or duplicated or something specially manufactured for this purpose.

1.2 A Model of Authentication Authentication is the primary means of guarding resources. Without authentication, a system should not grant a user access to its resources. The most basic model of authentication can be seen in Figure 1 below. In Figure 1, a principal sends a request to a guard or mediator on a remote server. The guard, after checking and verifying certain credentials specific to different authentication protocols, either accepts or rejects the principal’s request to access certain services on the server.

Figure 1. Model of authentication

1.3 Intruders in the Network A general assumption made when dealing with networks of computers is that these networks are often insecure. That is, any intruder that has access to the network has the ability to deliver messages out of order and to unintended recipients. An intruder can also concoct messages of her own choosing.

1.4 Authentication and Cryptography From the highest viewpoint of cryptography, there are two basic categories of cryptography, symmetric and public key cryptography. The basic idea of cryptography can be seen in Figure 2. In Figure 2, principal A wishes to send a message M to principal B. A wants to be sure that no one else on the network between herself and B can read, alter or forge the message M in any way. First, A encrypts the message M with her key, K1,to produce the ciphertext C. The encryption occurs on A’s computer before it is sent out onto the network. When B receives C from the network, he decrypts it on his machine with his key K2 to recover the plaintext message M. The main difference between symmetric and public key cryptography is in K1 and K2. Symmetric key cryptography generally means K1 = K2 whereas K1 ≠ K2 in public key cryptography.

Technical Report Number CSSE10-06

Figure 2. Basic view of cryptography

Cryptographic mechanisms are fundamental to authentication protocols [2]. The most basic cryptography depends on the use and knowledge of certain pieces of information, generally known as keys or passwords. Authentication can occur when two communicating principals disclose, in a confidential and secure manner, the key information that is assumed known only to the other principal. In this way, the principals can be assured that communication is taking place between himself and the other verified principal. Certain number-theoretic principals are thought of, by cryptographers, as being very difficult to perform in practice. Such a principal is the seeming intractability of reducing a number into its prime factors. Take for instance, the number 1,600. It is trivial for a human to calculate the prime factors of this number. The prime factorization is thus 2 .2.2.2.2.2.5.5. This is no small feat for a computer, as trivial as it may seem. For a computer to factor numbers to their most basic form requires a divide and test to determine if the number is truly divisible by a given divisor. Factorization resumes with the next divisor, until there are no more divisors to check. Clearly, for a very large number, many divisions must be performed. This is the problem. For larger and larger numbers, it takes more and more time to compute prime factors. As an example of the length of time it would take to exhaustively search a key space of 1024 bits, a common key length used in today’s cryptography, it would take about 10 300 years for 1000 3ghz machines working 24 hours per day, 7 days per week to exhaustively search the whole key space, assuming 3ghz ≈ 3 billion instructions per second and each key requires half a millisecond to generate and test. The idea is that by the time a useful result is ascertained, the actual transaction has been completed for some time, rendering the data calculated useless. Cryptography, especially public key cryptography, relies on “interesting” numbers. Here, “interesting” usually means very large prime numbers. One form of public key cryptography that relies on this idea is the RSA algorithm, further explained later. RSA relies on the idea that it is very difficult to calculate the two factors of the product of two very large prime numbers. Thus, anyone in possession of the private key of a public/private key pair is assumed to be the genuine owner of the key, since it is computationally very difficult to calculate the private key from a given public key.

multiple different types of authentication factors is a multi-factor authentication system. For instance, a website that only requires a password and any other knowledge-based factor is not an example of multi-factor authentication. An excellent example, however, would include a website that requires a password and a biometric identifier or a USB token. The password involves “something the principal knows” and “something the principal is or has.” This is true multi-factor authentication, the use of categorically different authentication factors for authentication. Multifactor authentication is also said to be a form of strong authentication. Multifactor authentication has also been recognized by the United States government through the Federal Financial Institutions Examination Council (FFIEC). The website states that “authentication methods that depend on more than one factor are more difficult to compromise than single-factor methods. Accordingly, properly designed and implemented multifactor authentication methods are more reliable and stronger fraud deterrents” [15]. This is a strong argument for multifactor authentication systems.

2. CRYPTROGRAPHIC BASICS This review of cryptography is attributed to [2].

2.1 Definitions and Notation Assume there is some message text M that we want to transmit over an unsecure network. M is generally referred to as plaintext in the literature. A cryptographic algorithm takes M as input and converts it to a form that is unreadable to anyone monitoring the network. This conversion process is called encryption. The unreadable form is known as ciphertext, C. An additional parameter K, known as a key, aids in encryption. Secrecy depends only on this key K. It is generally assumed the encryption algorithm is public with secrecy dependent only on the key. The intended receiver of the ciphertext, through the use of a second key K-1, can recover C using a reversed form of encryption. This plaintext recovery process is known as decryption. Encryption and decryption are depicted in Figure 3. Figure 3 shows plaintext M being encrypted by the sender’s key on the left into ciphertext. This ciphertext C is transmitted over some network and received at the receiver. The receiver uses his key to decrypt the ciphertext to recover the plaintext.

I cover the fundamentals of cryptography that are needed to understand the rest of this paper in section 2.

1.5 Multi-Factor Authentication Historically only one authentication factor is used to authenticate principals. The fact is generally due to the cost of producing authentication factors. An authenticating system that requires

Figure 3. Encryption and Decryption [2]

Technical Report Number CSSE10-06 By restricting who has access to keys we can limit the ability to form ciphertexts and the ability to determine the plaintexts corresponding to ciphertexts. In short, this protects confidentiality.

2.2 Hash Functions When we receive a message off the wire, how do we know it has not been tampered with? Hash functions! A hash function, or one-way function, is a function that is easy to compute and maps a variable-length input to a fixed-length output. The output of a hash algorithm is known as a message digest, and the algorithm itself is assumed to be public knowledge. A good hash function has the property that, given a message M, it is computationally infeasible to find another message M` such that Hash(M) = Hash(M`). Hashes can also be combined with cryptography to provide the basis of digital signatures.

the message provides secrecy of messages destined for principal A. Some public key algorithms allow the private key to be used to encrypt plaintext while the public key is used to decrypt the corresponding ciphertext. If a ciphertext C decrypts (using Ka) to a meaningful plaintext message M, then it is assumed that the ciphertext must have been created by principal A using the key Ka-1. This can be used to guarantee the authenticity of the message. The most widely known public key algorithm that allows such use was developed by Rivest, Shamir and Adleman [3] and is known as RSA. Such algorithms are said to provide a digital signature capability. The RSA algorithm works as follows: (1) pick two large primes p and q and let n = p . q

Say we have a message M we wish to send over the wire from A to B. First, A could calculate Hash(M), append it to M and encrypt it in some way before sending it to B. B decrypts the message and checks to see if the hash of the message he received matches the hash sent to him by A. If so, B can be sure M is the intended message.

(2) choose e relatively prime to Ф(n) = (p – 1) . (q – 1)

2.3 Symmetric Key Cryptography

(5) a message block M is now encrypted by calculating C = Me mod n

-1

The encryption key K and the decryption key K are usually identical in symmetric key cryptography and are used to encrypt/decrypt messages between principals. Before any private communication can take place, the two principals must first choose a suitable key in a private enough manner such that both believe no other entity is in possession of the secret key except the intended recipient. To ensure security of communication, this key is kept secret between the communicating principals. For the sake of notation, I will use Kab to denote a key intended for communication between principals A and B using a symmetric key cryptosystem. There is no distinction between Kab and Kba.

(3) use Euclid’s algorithm to generate a d such that e . d = 1 mod Ф(n) (4) make the pair (n, e) publicly available – this is the public key. The private key is d.

(6) the encrypted block C is decrypted by calculating M = Cd mod n Therefore, a sending principal A can communicate with principal B preserving secrecy and ensuring authenticity by first signing a message using his own private key Ka-1 and then encrypting the result using principal B’s public key Kb. Principal B uses his private key to decrypt and then uses principal A’s public key to obtain the original message.

An example of the way symmetric key cryptography can be used to verify authenticity is as follows: a message sent together with some cryptographic hash or message digest calculated using a hash function using a shared key can be used to verify authenticity. The sending principal prepares a message and calculates its hash and sends both the message and the hash to the receiving principal. The receiving principal, since it assumes only the sender has access to the key used to produce the hash, after verifying the hash of the received message is the same as the hash sent to him, believes the message to be from the sender and accepts the message as being authentic.

Public key algorithms rely heavily on the intractability of factoring large prime numbers. The idea is that, given a product of two very large prime numbers, it is computationally difficult to factor the two prime numbers into their products. Key length is an issue because computing power doubles roughly every two years. The larger the key length, the more computation it takes to exhaustively search the key space. Because computing power is growing so rapidly, exhaustive search of the key space is becoming more feasible. This causes us to have the need for larger and larger prime numbers to offset the yearly gains in computing power. Sheer processing capability affects the usability of keys in public key encryption [2].

2.4 Public Key Cryptography

3. NOTATION

There is no shared secret between communicating principals in public key cryptography. In public, or asymmetric, key encryption, each principal A is associated with some key pair (Ka, Ka-1) which will be used to encrypted and decrypt messages and prove its owner’s identity. The public key Ka is made publicly available while the private key Ka-1 is private and only known to its owner. Any principal can encrypt a message M using Ka, but only principal A can decrypt it using her private key Ka-1. This ensures no eavesdropper on the network can read

In this paper, the notation E(K : M) shall be used to denote the result of encrypting message M with key K. A protocol run consists of a sequence of messages sent between principals. Principals are generally denoted by capitals such as A, B and S (for server). The sequence of messages (1) A → B : M1 (2) B → S : M2

Technical Report Number CSSE10-06 (3) S → B : M3 denotes a protocol in which principal A sends M1 to principal B, principal B then sends M2 to S who then sends M3 to principal B. Attacks on protocols often involve some attacking principal pretending to be another. We denote this principal by Z. The notation Z(A) denotes the principal Z acting in the role of principal A. Principal Z has unlimited access to the network medium and may intercept, modify and resend messages sent on the network. Principal Z can also fabricate messages at will claiming to be some other principal. A number generated at random or by some other method by a principal A is denoted by Na. Such numbers are intended to be used only once for the purposes of the current run of the protocol and are usually called nonces. A message may have several components, possibly some plaintext and possibly some encrypted text. Message components will be separated by commas. Thus, the following example (1) A → B : A, E(Kab : Na) denotes that in the first message of the protocol, principal A sends to principal B the message whose components are a principal identifier A together with an encrypted nonce E(Kab : Na).

4. PROTOCOL TYPES In this section I give an overview of the many forms of authentication protocols in use. I will use the same categorization methodology used in [2]. In [2], Clark and Jacob categorize authentication protocols according to the cryptographic approach taken, i.e. symmetric or public key. They also distinguish between those that use (one or more) trusted third parties to take care of some function and those that operate only between two communicating principals that wish to achieve some mode of authentication. Further distinctions include number of messages involved in the protocols (e.g. one-pass, two-pass, three-pass etc.) and whether one principal wishes to convince the second of something (one-way or unilateral) or whether both parties wish to convince each other of something (two-way or mutual authentication).

4.1 Symmetric Key Without Trusted Third Party The following protocol is an example of a symmetric key protocol that does not use a trusted third party. Notice that protocols of this type require that a secret be shared between the two principals prior to runs of the protocol. (1) A → B : E(Kab : [Ta | Na], B) Here, principal A wishes to be verified (authenticated) by principal B. Principal A sends an encrypted message containing a nonce and the identifier of the authenticating principal B. The

nonce may be a timestamp Ta or a sequence number Na. On receiving this message, principal B, who believes that the key Kab is known only to himself and principal A, may deduce that principal A has recently sent this message if the sequence number is appropriate or if the timestamp has a recent value. If a malicious principal has access to the network medium then use of sequence numbers will be insufficient (since he can record message (1), prevent principal B from receiving it, and replay it to principal B at a later time). If the nonce were a sequence number or otherwise predictable, a malicious principal could issue the next nonce value to principal B and record the response. When principal A genuinely issued the same nonce value at a later date, the intruder could replay principal B’s earlier response to complete the protocol. Principal A could conclude only that the message he receives was created at some time by principal B (but not necessarily in response to his most recent challenge).

4.2 Symmetric Key With Trusted Third Party The following protocol is an example of a symmetric key protocol that uses the services of a trusted third party to distribute a secret key between two principals A and B. Notice that protocols of this type require that a secret be shared between each principal and the trusted third party prior to runs of the protocol. (1) A → S : A, B, Na (2) S → A : E(Kas : Na, B, Kab, E(Kbs : Kab, A)) (3) A → B : E(Kbs : Kab, A) (4) B → A : E(Kab : Nb) (5) A → B : E(Kab : Nb – 1) In this protocol, the Needham Schroeder Symmetric Key Authentication protocol [4], principal A requests from the server principal S a key to communicate with principal B. A includes a random nonce Na generated specially for this run of the protocol. This nonce will be used by principal A to ensure that message (2) is timely. Principal S creates a key Kab and creates message (2). Only principal A can decrypt this message successfully since he possesses the key Kas . In doing so, he will obtain the key Kab and check that the message contains the nonce Na. Principal A passes on to principal B the encrypted message component E(Kbs : Kab, A) as message (3). Principal B decrypts this message to discover the key Kab and that it is to be used for communication with principal A. He then generates a nonce Nb, encrypts it (using the newly obtained key), and sends the result to A as message (4). Principal A, who possesses the appropriate key Kab, decrypts it, forms Nb – 1, encrypts it and sends the result back to principal B as message (5). Principal B decrypts this and checks that the result is correct. The purpose of this exchange is to convince principal B that principal A is operational (and that message (3) was not simply the replay of an old message).

Technical Report Number CSSE10-06 At the end of a correct run of the protocol, both principals should be in possession of the secret key Kab newly generated by the server S and should believe that the other principal has the key.

denote a random public/private key pair and random secret key, respectively, used only for this protocol run.

4.3 Public Key

(1) A → B : E(Kab : Krand)

Because public key cryptography relies on both a user’s public and private key, schemes have been developed for authentication that rely on these same keys. Consider a message that principal A wishes to send to principal B. Assume principal A encrypts this message with her private key and sends it to principal B. If principal B can decrypt principal A’s message into something readable, then he can be reasonably sure that principal A actually sent the message.

(2) B → A : E(Kab : E(Krand : R))

Needham and Schroeder proposed the following protocol in their work that provides signed communication in which the origin of a communication and the integrity of the content can be authenticated to a third party [4]: (1) A → S : A, B (2) S → A : E(Ks -1 : Kb, B) (3) A → B : E(Kb : Na, A) (4) B → S : B, A (5) S → B : E(Ks -1 : Ka, A)

Here, we must first assume principal A and B share a secret Kab. To initialize the protocol, principal A generates a random public/private key pair (Krand, Krand-1). She then sends the freshly generated public key Krand to principal B encrypted under their pre-shared symmetric key Kab. Principal B now knows principal A’s public key. It is assumed no eavesdropper has principal A’s public key because she encrypted it with a shared key Kab. Principal B then generates a random symmetric session key R and encrypts it with principal A’s public key and then encrypts that information with their shared key Kab and sends it to principal A. Since principal A has in her possession the private key Krand-1 and the shared key Kab, she can now recover the session key R that is to be used for this session of communication with principal B. In the future, when principal A wishes to communicate with principal B again, they can reuse the key R or they can run the protocol again to determine the value of a new symmetric key R.

(6) B → A : E(Ka : Na, Nb)

5. PROTOCOL ATTACKS

(7) A → B : E(Kb : Nb)

This section presents various authentication protocol attacks.

5.1 Elementary Flaws This protocol makes use of a trusted server S, usually called a certification authority, that stores the public keys of various principals and distributes them on request encrypted under its own private key Ks -1. The certification authority’s public key is known to the principals. Message (1), (2) and (5), (6) are used by principal A and B to obtain each other’s public keys. Message (3) is encrypted under principal B’s public key and so can only be decrypted successfully by principal B. It contains a challenge Na together with principal A’s identifier. Principal B decrypts this to obtain the challenge, forms a challenge of his own Nb and encrypts both challenges under principal A’s public key and sends the result as message (6). Principal A then decrypts message (6). Since only principal B could have obtained the information necessary to send this message, principal A knows that principal B is operational and has just responded to her recent challenge. Principal A then encrypts principal B’s challenge Nb using principal B’s public key Kb and sends message (7). Principal B then decrypts and checks that it contains his challenge and concludes that principal A is operational and actually initiated the protocol.

4.4 Hybrid Protocols Hybrid protocols usually involve a principal’s public/private key system providing the secure sharing or distribution of a symmetric key for the duration of a session of communication or for a specified duration. Consider the Encrypted Key Exchange (EKE) protocol developed by Bellovin and Merritt [2]. Assume (Krand, Krand-1) and R

As Carlson describes in [6], an elementary flaw provides only marginal protection against hostile activity. An environment that ignores protecting sensitive data transmitted on the network has an elementary flaw that may be exploited by an adversary with network access. Consider the following toy protocol example to illustrate an elementary flaw: (1) A → B : A, B, Kab Here, principal A wants to prove to principal B that she has the secret key Kab in her possession. A simple solution would be to just send the shared key to principal B along with identifiers so that principal B can perform a look-up of the key that matches the received identifier. When principal B receives this message from principal A, he checks to see if he has a shared key that matches the key sent to him by principal A. If it matches his copy of the shared key, and he assumes no malicious activity has occurred on the network, then he can be sure that principal A is in possession of the secret key. However, what if an intruder were listening in on the network? The intruder could capture the shared key Kab preventing it from ever reaching principal B. This type of protocol, one in which a password or other is sent in the clear over the network, is an authentication protocol with an elementary flaw. An intruder could masquerade as principal A as follows: (1) A → Z(B) : A, B, Kab

Technical Report Number CSSE10-06 (2) Z(B) → B : A, B, Kab The intruder could drop message (2), making sure it never gets to principal B. A more malicious attack includes the intruder also replaying the message to principal B at a later time. This type of attack is known as a replay attack and will be discussed later. Even though the protocol has a specific non-trivial purpose in mind, allowing the verification of a secret between two principals A and B, it reveals secret information about secret keys between principals A and B. This elementary flaw could be prevented simply by encrypting the information using the shared key. Another elementary flaw has been found in the CCITT X.509 [7] authentication protocol. The flaw is due to the fact that messages are encrypted before they are signed (instead of the other way around). This has the effect of allowing an intruder to impersonate the originator of the message by substituting the original signature for his own [6].

5.2 Freshness or Replay Attack A freshness or replay attack occurs when a message from a previous run of a protocol is recorded by an intruder and replayed as a message in the current run of the protocol. As a real-world example, consider the Needham Schroeder Symmetric Key protocol discussed in section 4.2 above. At the end of a correct run of the protocol, each principal should be in possession of the secret key Kab newly generated by the server S and believe that the other has this same key. This is the intention of the protocol. Consider message (3). Although principal B decrypts this message and assumes legitimately that it was created by the server S, there is nothing in the message to indicate that it was actually created by S as part of the current protocol run. Suppose a previously distributed key Kab` has been compromised and is known to an intruder Z. Principal Z might have monitored the network when the corresponding protocol run was executed and recorded message (3) consisting of E(Kbs : Kab`, A). The intruder can now fool principal B into accepting the key as new by the following protocol (with lines (1) and (2) omitted):

As an example, consider the Andrew Secure RPC protocol shown below: (1) A → B : A, E(Kab : Na) (2) B → A : E(Kab : Na + 1, Nb) (3) A → B : E(Kab : Nb + 1) (4) B → A : E(Kab : Kab`, Nb`) Principal A indicates to principal B that she wishes to communicate with him and sends an encrypted nonce E(Kab : Na) as a challenge in message (1). Principal B replies to principal A’s challenge by decrypting and incrementing the received nonce and issues a challenge of his own by sending the message E(Kab : Na + 1, Nb). Since principals A and B share the key Kab, principal B can successfully decrypt and increment principal A’s initial challenge. Principal A replies to principal B’s challenge by forming and sending E(Kab : Nb + 1) to principal B. Principal B now creates a session key Kab` and distributes it (encrypted) together with a sequence number identifier Nb` for future communication. However, if nonces and keys are both represented as bit sequences of the same length, then an intruder could record message (2), intercept message (3) and replay message (2) as message (4). The attack would look like this: (1) A → B : A, E(Kab : Na) (2) B → A : E(Kab : Na + 1, Nb) (3) A → Z(B) : E(Kab : Nb + 1) (4) Z(B) → A : E(Kab : Na + 1, Nb) Here, principal A may be fooled into accepting the nonce value Na + 1 as the new session key. In this case, principal A will have been fooled into accepting a key whose value may be known to an observant intruder.

5.4 Parallel Session or Oracle Attack (3) Z(A) → B : E(Kbs : Kab`, A) (4) B → Z(A) : E(Kab` : Nb) (5) Z(A) → B : E(Kab` : Nb – 1) Principal B believes he is following the correct protocol. Principal Z is able to form the correct response in (5) because he knows the compromised key Kab` He can now engage in communication with principal B using the compromised key and masquerade as principal A.

5.3 Type Flaw Attack A message consists of a sequence of components each with some value and each value represented as a sequence of bits. A type flaw arises when the recipient of a message accepts that message as valid but imposes a different interpretation on the bit sequence than the principal who created it.

A parallel session attack occurs when two or more protocol runs are executed concurrently and messages from one are used to form messages in the other. As a simple example, consider the following one-way authentication protocol: (1) A → B : E(Kab : Na) (2) B → A : E(Kab : Na + 1) This protocol should convince principals A that B is operational since only principal B could have formed the appropriate response to the challenge issued in message (1). The attack works by starting another protocol run in response to the initial challenge:

Technical Report Number CSSE10-06

(1.1) A → Z(B) : E(Kab : Na) (2.1) Z(B) → A : E(Kab : Na) (2.2) A → Z(B) : E(Kab : Na + 1) (1.2) Z(B) → A : E(Kab : Na + 1) Principal A initiates the first protocol with message (1.1). Principal Z now pretends to be principal B and starts the second protocol run with message (2.1), which is only a replay of message (1.1). Principal A now replies to this challenge with message (2.2). But this is the exact value which principal A expects to receive back in the first protocol run. Principal Z therefore replays this as message (1.2). After this protocol run, principal A believes principal B is operational, but principal B may no longer exist. In this attack, principal Z uses principal A to do some work on his behalf. He needed to form an appropriate response to the encrypted challenge but could not perform the operation himself. He “asks” principal A to perform the operation instead who willingly provides the answer. This is why this attack is also known as an oracle attack, because some principal uses another principal and the other principal’s knowledge to calculate or give some result on his behalf.

5.5 Man-In-The-Middle Attack According to Wikipedia.org, the man-in-the-middle attack is a form of active eavesdropping in which the attack makes independent connections with the victims and relays messages between them, making them both believe they are talking directly to each other over a private connection when in fact the entire conversation is controlled by the attacker. The attacker usually must be able to intercept all messages going between the two victims and possibly inject new ones. A man-in-the-middle attack can only be successful if the attacker can impersonate each endpoint to the satisfaction of the other. Consider the following example in which principal A wishes to communicate with principal B. Here is the attack:

of the supposedly secure messages sent from principal A to principal B. Various defenses against man-in-the-middle attacks include the use of strong mutual authentication and the use of strong passwords.

5.6 Binding Attack In public key cryptosystems, it is very important for the binding between a public key and its owner’s identity to be correct. This binding is usually verified by referencing a trusted third party either in the form of a certificate authority or a web of trust scheme as explained in the introduction as used in PGP. A binding attack is when an intruder has, in some way, convinced a principal that he is the owner of a particular public key when, in fact, he is not the owner. When a principal wishes to ascertain the public key of another principal B, the following example protocol could be used between the principal A and a certificate authority CA:

(1) A → CA : A, B, Na (2) CA → A : CA, E(Kca-1 : CA, A, Na, Kb)

In message (1), principal A sends to the certificate authority her indentifying information, the fact she wishes to communicate with principal B and a nonce for freshness. The certificate authority CA responds with message (2). The CA sends its identifier in the clear so that principal A knows which public key to use to decrypt the next part of the message. The encrypted message contains the certificate authority’s identifier to signify the message came from that certificate authority, the requesting principal’s identifier and nonce so that principal A knows the response was sent in response to his request and the requested public key. An attacker could attack this system as follows by masquerading as the certificate authority:

(1.1)A → Z(B) : A, B

(1.1) A → Z(CA) : A, B, Na

(2.1)Z(B) → B : A, B

(2.1)Z(A) → CA : A, Z, Na

(2.2)B → Z(A) : Kb (1.2)Z(B) → A : Kz In message (1.1), principal A requests principal B’s public key, but an intruder Z masquerades as principal B intercepting the message. In messages (2.1) and (2.2), principal Z replays principal A’s response to principal B obtaining principal B’s public key. In the final message (1.2), principal Z, pretending to be principal B, sends his own public key instead of principal B’s public key. From now on, when principal A encrypts messages destined for principal B with the key she believes belongs to principal B, the intruder Z will be able to intercept and read all

(2.2)CA → Z(A) : CA, E(Kca-1 : CA, A, Na, Kz) (1.2)Z(CA) → A : CA, E(Kca-1 : CA, A, Na, Kz)

An intruder Z intercepts the initial message (1.1) from principal A to the certificate authority and replaces the identifier of the intended server B with his own identifier Z and sends the result to the certificate authority. The certificate authority believes principal A has requested principal Z’s public key and replies to principal Z with principal Z’s public key. Principal Z then forwards the certificate authority’s response back to principal A, but principal A believes this response to be from the certificate authority. Principal Z has successfully masqueraded as the

Technical Report Number CSSE10-06 certificate authority. Principal A performs the decryption on the received information and concludes that he has received principal B’s public key when, in fact, he has received principal Z’s public key. By masquerading as the certificate authority, principal Z has altered the binding between principal B and principal B’s actual public key. No longer does the public key given to principal A by the certificate authority provide security of message exchange between principals A and B. Now, when principal A attempts to send messages she believes she has encrypted with principal B’s public key, she has actually encrypted with principal Z’s public key. At this point, principal Z can read all of the information sent from principal A destined for principal B because of the compromised public key binding. This is known as a binding attack.

6. SPECIFIC PROTOCOLS, THEIR VULNERABILITIES AND FIXES 6.1 Needham-Schroeder Protocol There are two versions that Needham and Schroeder outline in [4]. One version relies on the use of a pre-shared key between the two principals and the other relies on public key cryptography. Since they mostly only differ in the use of their key system, I will omit the protocol that relies on public key cryptography. The two protocols are largely identical in form and function. The following protocol developed by Needham and Schroeder in [4] relies on the use of a pre-shared key and a trusted server S and works as follows: (1) A → S : A, B, Na (2) S → A : E(Kas :Na, B, Krand, E(Ksb : Krand, A)) (3) A → B : E(Ksb : Krand, A) (4) B → A : E(Krand : Nb) (5) A → B : E(Krand : Nb – 1) The protocol begins with principal A sending her identifier and nonce to the server S, indicating to the server she wishes to securely communicate with principal B. Principal S prepares a random key Krand for communication between principals A and B at a later time and sends principal A’s nonce, the randomly generated key and the identifier of who the key is for, principal B in this case. The server also encrypts the random key with a key shared between himself and principal B and sends it to principal A as well. Principal A forwards the encrypted portion of the message received from principal S to principal B, essentially sharing the random key with principal B. Since only principal B has the shared key shared between the server S and himself, only he has the ability to open the message from principal A. Principal B forms a challenge, the nonce Nb, encrypts it with the random key and sends it to principal A. This is done so that principal B can be sure principal A actually initiated the process of attempting to securely communicate with principal B. If principal A is active, she answers the challenge sent by principal B by decrementing the nonce Nb, encrypting it with principal A

and principal B’s established secret Krand and communication can continue using the shared secret Krand that has been distributed by the trusted server. In [8], Denning and Sacco point out that if an intruder Z has intercepted and recorded all the messages between principals A and B and that principal Z also has a copy of the communication key Krand, then the protocol may be susceptible to a replay attack. First, principal Z replays the message E(Ksb : Krand, A) to principal B. Thinking that principal A has initiated a new conversation, principal B requests a handshake from principal A and sends E(Krand : Nb`), another nonce created for this run of the protocol. Principal Z intercepts this message, deciphers it, and impersonates principal A’s response as E(Krand : Nb – 1). Thereafter, principal Z can send bogus messages to principal B that appear to be from principal A, intercepting and deciphering principal B’s replies. This problem can be easily solved through the use of timestamps and a timeliness function which determines if a timestamp is “timely” given the current time on the authenticating system. The new protocol involves a new symbol for the current time T and goes something like this: (1) A → S : A, B (2) S → A : E(Ksa : B, Krand, T, E(Ksb : A, Krand, T)) (3) A → S : E(Ksb : A, Krand, T) Principals A and B can verify their messages are not replays by checking that |current time – T| is less than or equal to some acceptable threshold value.

6.2 Otway-Rees Protocol The Otway-Rees protocol was designed for use over insecure networks. It allows principals communicating over such networks to prove their identity to each other while preventing eavesdropping or replay attacks and allowing for the detection of modified messages. The protocol is shown here: (1) A → B : M, A, B, E(Kas : Na, M, A, B) (2) B → S : M, A, B, E(Kas : Na, M, A, B), E(Kbs : Nb, M, A, B) (3) S → B : M, E(Kas : Na, Kab), E(Kbs : Nb, Kab) (4) B → A : M, E(Kas : Na, Kab) In this protocol, M is a special nonce used as a run identifier. In message (1), principal A sends to principal B the plaintext M, A, B and an encrypted message readable only by the server S. Principal B forwards the message to principal S together with a similar component sent in message (1). The server decrypts the messages and checks that the components M, A, and B are the same in both messages. If so, it generates a key Kab and sends message (3) to principal B who forwards part of the message to principal A. Principals A and B will use the key Kab only if the

Technical Report Number CSSE10-06 message components generated by the server S contain correct nonces Na and Nb respectively. An attack on the protocol can be seen here: (1) A → Z(B) : M, A, B, E(Kas : Na, M, A, B) (2) Z(B) → A : M, E(Kas : Na, M, A, B) In this attack, principal A is fooled into believing that the triple M, A, B is actually the new key. This protocol has a type flaw and this example protocol run shows how an attacker who has this knowledge can take advantage of this example of a type flaw. It is also possible to wait until message (2) of the original protocol has been sent and then both principal A and principal B can be fooled into believing their conversation is secure. This other attack is shown thus: (1) A → B : M, A, B, E(Kas : Na, M, A, B) (2) B → Z(S) : M, A, B, E(Kas : Na, M, A, B), E(Kbs : Nb, M, A, B) (3) Z(S) → B : M, E(Kas : Na, M, A, B), E(Kbs : Nb, M, A, B) (4) B → A : M, E(Kas : Na, M, A, B) The above attack involves an attacker Z masquerading as the authentication server S taking advantage of this protocol’s type flaw. Message (1) is sent out as per the original protocol prescription. However, when principal B sends the authentication information to the server S, the attacker Z intercepts the message. Since the protocol is assumed to be public knowledge, the attacker knows how to strip the message of the identifiers A and B. Principal Z replays the message minus the two identifiers A and B. When principal B receives this message from the attacker, he thinks he has just received information from the authentication server S. He is tricked into believing [M, A, B] is the shared key between himself and principal A. Unknowing that this message has been spoofed by the attacker Z, principal B forwards the correct message component to principal A. At this point, principal A has no idea of the lapse in security and accepts principal B’s message as authentic. Principal Z has tricked principals A and B into believing their session key should be the public message component [M, A, B], thus making confidentiality and integrity moot. A simple fix for this protocol could be to get rid of the vulnerability of a replaying type flaw attack. It could be a requirement of the server that when it decrypts the information from principal B, it should perform some transform on the nonces before replying to principal B’s request. This way, assuming no intruder has the server’s key, the server can be verified as having produced the session key to be used between principals A and B.

6.3 Password Authentication Protocol According to RFC 1134 [10], Password Authentication Protocol (PAP) is a simple protocol used to establish a principal’s identity using a two-way handshaking procedure. PAP is generally invoked after the initial link establishment phase of a point-topoint protocol (PPP), and the protocol is as follows where P A is principal A’s password for use on the system: (1) A → S : A, PA (2) S → S` : S, Ns , PA XOR hash(Ns , Kas`) (3) S` → S : S`, hash(Ns , Kas`) (4) S → A : [“accept” | “reject”] After link establishment is complete, an id/password pair is repeatedly sent as in message (1) by the principal to the authenticator until the principal receives an authentication acknowledgment or the connection is terminated. The authenticator could contact some other password authenticator as in (2). The password authenticator, which could be the same as the original authenticating server (i.e. S = S`), checks to see if the hash he calculates matches the hash he receives. If this checks out, principal S sends back an “accept” message and principal A is authenticated. The RFC states that PAP is not a strong authentication method because passwords are sent over the network in the clear, and there is no protection from playback or repeated trial and error attacks. The principal is in full control of the frequency and timing of the authentication attempts. PAP transmits unencrypted ASCII usernames and passwords over the network and is therefore considered insecure. Any eavesdropper Z can record and store the unencrypted information and use it to gain access to the system at a later time. This protocol has an elementary flaw. The fact that this protocol sends information over the wire unencrypted and in the clear is a major issue. A fix for this simple protocol could include hashing the password before sending it over the wire with a special nondecreasing nonce to prevent replay attacks. The authenticator, after receiving a principal’s username and hashed password and nonce, checks its records to see if the received hash matches that hash stored for the supplied username. Further, the authenticator could guard against brute force password-guessing attacks by keeping track of the number of failed authentication attempts (i.e. password guesses by a malicious principal) and lock the account of the principal for a length of time. In [11], Kim proposes a fix to the protocol by encrypting the first message using the server’s public encryption key. Thus, the fixed protocol becomes: (1) A → S : E(Ks : A, PA) (2) S → A : [“accept” | “reject”]

Technical Report Number CSSE10-06 Thus, the protocol now maintains confidentiality of the originating message.

principal can be sure the server is who it says it is, thus thwarting the attack.

6.4 Challenge-Handshake Authentication Protocol

6.5 Extensible Authentication Protocol

Another protocol used to authenticate a user after the link establishment phase of PPP is the Challenge-Handshake Authentication Protocol (CHAP). CHAP is formally defined in RFC 1994. CHAP is used to periodically verify the identity of a principal using a 3-way handshake. This is done after the link establishment phase of PPP and may be repeated any time after the link has been established [9]. In the protocol, the authenticator sends a challenge message to the principal wishing to be authenticated. The principal responds to the challenge message with a value calculated using a one-way function, or hash function. The authenticator checks the principal’s response against the expected hash value. If the values match, the authenticator sends an authentication acknowledgement; otherwise, the link is terminated. The standard also states that the authenticator sends new challenges at random intervals and the process repeats. This protocol provides protection against replay attacks by malicious users through the use of an incrementally changing identifier, the nonce Ns and the use of a variable challenge value. One negative aspect of CHAP is that it requires that both the principal and the authenticator know the value of the plaintext password, making a compromised system or principal a source of worry. However, withstanding this type of attack, a replay attack is not a worry. So, the CHAP protocol is thus: (1) S → A : C, Ns (2) A → S : hash(C, Ns , P) (3) S → A : [“accept” | “reject”] However, CHAP has a flaw that allows an intruder to masquerade as the server. Here is the attack: (1) Z(S) → A : C, Nz (2) A → Z(S) : hash(C, Nz, P) (3) Z(S) → A : “accept” An attacker always “accepts” in message (3) because he will assume the principal A will never lie about his calculated hash. Now principal A thinks she is talking to a server S, but she is actually talking to an adversary. Although the authentication of this protocol is one-way, i.e. authentication only takes place for one principal, at the end of message (3), the principal could invoke the protocol again to authenticate the server. This is a fix for the attack mentioned above. After the principal sends a random challenge and nonce to the authenticator and receives the correct response, the

This section explains two members of a family of related protocols which are all encompassed under the Extensible Authentication Protocol (EAP) framework. EAP is a set of multiple authentication methods that can be used over both wired and wireless mediums. According to RFC 3748, EAP is used to select a specific authentication mechanism [12].

6.5.1 EAP-MD5 EAP-MD5 is an authentication protocol that is largely identical to CHAP as discussed above, with the hash function of CHAP being the MD5 hash algorithm. EAP-MD5 has the same issues as CHAP including the vulnerability of a man-in-the-middle attack.

6.5.2 EAP-PSK EAP-Pre-Shared Key, defined in RFC 4764, is an EAP method for mutual authentication and session key derivation using a preshared key. It provides a protected communication channel when mutual authentication is successful for both principals and is designed for authentication over insecure networks such as IEEE 802.11. EAP-PSK relies on a single cryptographic primitive, AES-128 [13]. Restricting the use of cryptographic primitives makes the use of this protocol simpler to understand and implement. The authors state this also makes it lightweight and well suited for generally any type of device, especially those with little processing power and memory. EAP-PSK assumes that the pre-shared key is known to the principal wishing to be authenticated and the authenticator, generally an 802.11 access point. This pre-shared key is used to derive two 16-byte static long-lived subkeys called the authentication key and the key-derivation key. Then, the authenticator and principal use the authentication key to mutually authenticate each other. EAP-PSK uses the key-derivation key to derive session keys shared by the principal and authenticator. EAP-PSK uses the MAP1 protocol developed by Bellare and Rogaway in [14]. In [14], Bellare and Rogaway present a protocol for mutual authentication of two principals thus shown: (1) A → B : Ra (2) B → A : E(Kab : B, A, Ra, Rb) (3) A → B : E(Kab : A, Rb) In this protocol, principal A begins by sending principal B a random challenge Ra. Principal B responds by making up a random challenge Rb, encrypting it and returning it in message (2) with identifiers. Principal A checks that this message is correctly tagged as coming from principal B. She does this by verifying her random challenge is contained in the response from principal B encrypted under their shared secret. If the response is correct, principal A sends principal B a response in message

Technical Report Number CSSE10-06 (3). Principal B checks that this message is correctly tagged as coming from principal A and accepts the message if his challenge is contained in the encrypted message (3). Bellare and Rogaway state in their paper that the security of this protocol hinges on the ability of each principal to generate the random challenges. They note that the challenges must be unpredictable and further state that a predictable nonce (like a sequence number) will not work. An attack of the MAP1 protocol follows: (1.1) A → Z(B) : Ra (2.1) Z(B) → A : Ra (2.2) A → Z(B) : Ra`, E(Kab : B, A, Ra, Ra`) (1.2) Z(B) → A : Ra`, E(Kab : B, A, Ra, Ra`) (1.3) A → Z(B) : E(Kab : A, Ra`) In this attack, intruder Z masquerades as principal B in a run of the MAP1 protocol started by principal A. In parallel, principal Z starts a run of the protocol while masquerading as principal B. In this attack, principal A first sends a random challenge as message (1.1). Principal Z intercepts this message and opens a parallel protocol run with principal A. In message (2.1), the first step of the new session principal Z begins with principal A, principal Z replays the message (1.1) to principal A. In message (2.2), principal A responds with the answer it expects to receive from principal B. When principal A receives the message from principal Z in message (1.2), she checks to be sure the plaintext Ra` is the same as that Ra` that she decrypts in the encrypted component of the message. Principal Z simply replays this message to principal A, completing the second step of the protocol run. In message (1.3), principal A sends her verification message to principal Z and the attack has completed with principal Z successfully masquerading as principal B. A simple fix for this protocol would be to use public key cryptography for encryption/decryption. Principal A would have known an attacker had compromised this authentication protocol in message (1.2) before authentication had taken place, preventing principal Z from masquerading as principal B.

6.6 Yahalom Protocol Given below is the Yahalom protocol:

himself and the server along with message (1) and sends it to the trusted server. The server is the only principal able to decrypt message (2). The server creates a key Kab for principals A and B to use for further communication and encrypts it with its shared key with principal A along with both nonces and principal B’s identifier. The server also appends another component onto message (3), A’s identifier along with the created key encrypted under server S’s and principal B’s shared key. Principal A will later forward this component to principal B to complete the protocol. When principal A receives message (3), she checks to see if B’s identifier is present. If it is, she grabs the last encrypted component from message (3), appends it to principal B’s nonce encrypted with their new shared key and sends it to principal B. Principal B checks this message to be sure A’s identifier is in the first encrypted message component. If it is, he decrypts the second encrypted component with the key distributed from the server. He then checks to be sure his original nonce is carried in this message. If it is, the protocol ends with success. An attack of the protocol is thus shown: (1) Z(A) → B : A, Na (2) B → Z(S) : B, Nb, E(Kbs : A, Na,) (3) Z(S) → Z(A) : any/nothing (4) Z(A) → B : E(Kbs : A, Na), E(Na : Nb) As the reader can see from the above protocol, the intruder Z masquerades as both principal A and as the trusted server S. The protocol is the same as its original version except for the last message. Principal Z needs to convince principal B that principal A’s identifier is contained in the first encrypted component. The intruder Z knows that a replay of message (2), along with a concocted second component will fool B into believing the message was from the trusted server S and the other principal A. So, when principal B receives this message from principal Z, he believes the nonce Na, is the key produced by the trusted server. All principal Z must do is encrypt B’s nonce with A’s nonce as the key and intruder Z now has full accessibility to B’s personal messages. A fix for this protocol could include using public key cryptography instead of symmetric key cryptography. Consider the following altered Yahalom protocol which uses public key cryptography:

(1) A → B : A, Na (2) B → S : B, Nb, E(Kbs : A, Na)

(1) A → B : A, Na

(3) S → A : E(Kas : B, Kab, Na, Nb), E(Kbs : A, Kab)

(2) B → S : B, Nb, E(Ks : A, Na)

(4) A → B : E(Kbs : A, Kab), E(Kab : Nb)

(3) S → A : E(Ka : B, Kab, Na, Nb), E(Kb : A, Kab) (4) A → B : E(Kb : A, Kab), E(Kab : Nb)

We must first assume that principals A and B both share secret keys Kas and Kbs , respectively, with a trusted server S. In message (1), principal A sends a request for authentication to principal B along with a nonce. Principal B creates a nonce of his own and encrypts it with the secret key shared between

We must first assume that principal B knows the server S’s public key, the server S knows principal A’s public key, and that principal A knows principal B’s public key. The fix to this protocol begins with the same message (1) as the original

Technical Report Number CSSE10-06 Yahalom protocol. After principal B receives message (1), he prepares a nonce and sends the request to the server S encrypted with the server’s public key. Since only the server S knows his own private key, only he can decrypt message (2). The server prepares a symmetric key and encrypts it under both principals’ public keys and forwards the response to principal A. Principal A checks to be sure her own nonce and principal B’s identifier is contained in message (3). If this information is found, she forwards the second message component to principal B along with his nonce encrypted under the distributed secret key Kab. After principal B verifies principal A’s identifier is in the first encrypted message component of message (4) and that his nonce is encrypted with the distributed key, he can be sure that no other principal except principal A could have composed the message.

7. CONCLUSION With numbers of computers on the internet growing literally every moment of every day, it has become increasingly important for users to protect their identities and confidential information from attack by malicious principals. Authentication protocols ensure a means of protecting confidential information from those principals unauthorized to view it. By controlling the flow of secrets, authentication protocols attempt to ensure this secret information is not used to gain unauthorized access to network resources.

8. ACKNOWLEDGMENTS

[4] Needham, R. and Schroeder, M. Using Encryption for Authentication in Large Networks of Computers. Communications of the ACM, 21(12), December 1978. [5] Bellovin, S. and Merritt, M. Encrypted Key Exchange: Password-Based Protocols Secure Against Dictionary Attacks. IEEE. 1999. [6] Carlsen, U. Cryptographic Protocol Flaws: Know Your Enemy. IEEE. 1994. [7] CCITT X.509. The Directory – An Authentication Framework. November 1988. [8] Denning, D. and Sacco, G. Timestamps in Key Distribution Protocols. ACM. 1981. [9] Simpson, W. “PPP Challenge Handshake Authentication Protocol (CHAP)”. RFC 1994. August 1996. [10] Lloyd, B. and Simpson, W. “PPP Authentication Protocols”. RFC 1334. October 1992. [11] Kim, I. and Choi, J. “Formal verification of PAP and EAPMD5 protocols in wireless networks: FDR model checking”. Proceedings of the 18th International Conference on Advanced Information Networking and Applications AINA 2004. March 2004. [12] Aboba, B., Blunk L., Vollbrecht, J., Carlson, J., Levkowetz, H. “Extensible Authentication Protocol (EAP)”. RFC 3748. June 2004.

Thanks to Dr. John A. Hamilton, Jr., for a great fall 2009 semester of COMP 6370 – Information Security!

[13] Bersani, F., Tschofenig, H. “The EAP-PSK Protocol: A PreShared Key Extensible Authentication Protocol (EAP) Method”. RFC 4764. January 2007.

9. REFERENCES

[14] Bellare, M. and Rogaway, P. “Entity authentication and key distribution”. In Advances in Cryptology – Crypto 93 Proceedings, pages 232-249, 1993.

[1] Aboudagga, N., Refaei, M.T., Eltoweissy, M., DaSilva, L.A., Quisquater, J.J. 2005. Authentication Protocols for Ad Hoc Networks: Taxonomy and Research Issues. ACM. Q2SWinet, October 13, 2005. [2] Clark, J. and Jacob, J. 1997. A Survey of Authentication Protocol Literature: Version 1.0. Technical Report. [3] Rivest, R., Shamir, A., Adleman, L. A Method for Obtaining Digital Signatures and Public Key Cryptosystems. Communications of the ACM, 21(2):120-126, February 1978.

[15] “Board of Governors of the Federal Reserve System.” Federal Financial Institutions Examination Council online, 2009. Web. http://www.ffiec.gov/ffiecinfobase/resources/info_sec/2006/f rb-sr-05-19.pdf. [16] Burrows, M. and Abadi, M. “A Logic of Authentication”. ACM Transactions on Computer Systems, Vol. 8, No. 1, February 1990, Pages 18-16.