This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
From the beginning of the 20th century until now, there has been very great development, with the main driver being the needs of people that are continuously changing over time. To follow this high demand developers are constantly trying to design and fabricate new devices with the highest possible specifications and at minimum cost.
The preparation of this dissertation has been inspired by several objectives:
Understanding of the basic principles of IEEE 802.1X
Commissioning computer simulator for ion implantation.
Carry out simulation of implantation of ions into various metal-semiconductor structures.
Determination of the intermixing at each metal-semiconductor interface.
Optimization of the process by determination of the conditions for maximum intermixing with minimum ion dosage for a wide range of ionic species.
Overview of the dissertation
This dissertation investigates issues related to the introduction of ions into metal semiconductor structures:
Chapter 3, contains a description of the basics of semiconductor processing and more specifically it describes the metallization effects. A brief description of an ion implantation technique is also included.
Chapter 4, introduces the simulator SRIM and provides a brief description of the program. Calculations are presented for the different substrates used with the aid of graphs and tables as well as a number of concluding remarks from the analysis performed.
Chapter 5, presents conclusions from the overall work undertaken. Additionally this chapter provides recommendations for future work that needs to be undertaken.
overview of the ieee 802.1x protocol
IEEE 802.1X layering
Primary components of a port-based authentication system are divided into 3 categories:
Supplicant is a client device such as laptop, PC, mobile or IP phone. Prior to network access, authentication of the supplicant needs to take place. Supplicant usually refers to as unknown user(s). The identity is unknown until production of valid credentials to the authentication server.
In order to be considered as a valid supplicant, a typical client device, would need to implement 802.1X and a specific EAP-Method. For example, windows XP comes with 802.1X built in with a variety of EAP-Methods, such as EAP-TLS. The supplicant communicates with the authentication server using EAP as the transport and a specific EAP-Method that provides the actual authentication mechanism. The actual communication between the supplicant and the authenticator is accomplished via EAPOL, which is defined by 802.1X. EAPOL delivers the EAP and EAP-Method frames as data.
Authenticator is a Layer II network device, like an Ethernet switch or a wireless LAN access point. The authenticator plays the role of the security gate between the supplicants and the protected network. It implements authentication before allowing access to services that are accessible via that port. The gate (port) remains closed until the authentication system verifies the credentials of the supplicant and judge that the supplicant is authorised to access the protected network. Once the system authenticates the supplicant, the authenticator will open a port so that access to the protected network can be granted for the supplicant. It is noted that the authenticator's functionality is independent of the actual authentication method; this effectively acts as a pass-through for the authentication exchange.
The authenticator also acts as a translator between the supplicant and the authentication server. During the communication between the supplicant and the authentication server communicate, everything goes through the authenticator. For example, the supplicant will send its credentials to the authentication server by encapsulating the credentials (based on specific EAP-Method) in EAP frame, which is all encapsulated in an EAPOL frame. The EAPOL frame is send to the authenticator, which then removes the EAP-Method data from EAPOL frame. The authenticator sends the EAP-Method data encapsulated in a RADIUS frame directly to the authentication server. Thus, the conversation between the supplicant and the authentication server is based on a common language.
Authentication Server or backend server receives RADIUS messages which are used to check and authenticate the credentials provided by supplicant(s). The authentication server, for instance, will at some point request the credentials from the supplicant. The supplicant will then offer the credentials to the authentication server. Port-based authentication standards and specifications don't make any particular type of authentication server mandatory, but nearly all implementations utilize RADIUS. As result, RADIUS is the de facto standard recognised by the networking industry.
In an enterprise system, the authentication server may be embedded in the authenticators. This distributed authentication server model significantly reduces authentication traffic over the network, which is desirable for wireless networks where roaming frequently occurs. This improves performance for all clients. In addition, smaller networks may seriously benefit from using a switch or access point that also provides authentication server function. This is a cost effective solution for smaller networks because it reduces the hardware costs.
Wireless Station Access Point Authentication Sever
EAP method (EAP-TLS/MD5/TTLS/PEAP)
802.1X standard uses Extensible Authentication Protocol encapsulation over LANs (EAPOL). Its communication operates in number of steps as outlined below:
The authenticator sends an EAP request/Identity packet to the supplicant as soon as it detects that the network link is active (device connected to switch or access point). It is noted that in this state, only 802.1X traffic is allowed. Other traffic, such as DHCP and HTTP, is blocked at the data link layer.
The supplicant sends an EAP response/Identity packet with its identity in it to the authenticator.
The EAP response/Identity packet is then passed on to the authentication (RADIUS) server by the authenticator which is encapsulated in RADIUS protocol.
The authentication server sends back a challenge to the authenticator, such as with a token password system.
The authenticator unpacks this from IP and repackages it into EAPOL and sends it to the supplicant. Different authentication methods will vary this message and the total number of messages. EAP supports client-only authentication and strong mutual authentication.
The supplicant responds to the challenge via the authenticator.
The authenticator passes the response to the challenge onto the authentication server.
If the supplicant provides proper identity, the authentication server responds with a success message to the authenticator.
The success message is then passed onto the supplicant by the authenticator. The authenticator now allows access of the supplicant to the LAN, possibly restricted based on attributes that came back from the authentication server. For example, the authenticator might switch the supplicant to a particular virtual LAN or install a set of firewall rules.
EAP Identity Request
EAP Identity Response
RADIUS Access Challenge
EAP Identity Response
RADIUS Access Request
RADIUS Access Request
RADIUS Access Accept
: Data Flowing
: Authentication method
analysis and design using radius protocol
RADIUS is a widely used protocol in network environments and a key part of the 802.1X mechanism for carrying out authentication information between an access point and a back-end authentication server. It's usually used for embedded network devices such as routers, switches and being deployed by most ISP's. Furthermore enterprise wireless networks are deploying RADIUS protocol for managing scalable large networks with large number of subscribers (users) which facilitate centralised (operational requirement) user administration.
As main key features of a RADIUS could analysed further on:
Network access server will work as a client for RADIUS server.
RADIUS server is responsible for getting user connection requests, authenticating the user and then returning all configuration information necessary for the client to deliver service to the user.
A RADIUS server can act as a proxy client to other RADIUS servers.
Transactions between client and server are authenticated through the use of a shared key and this key is never sent over the network.
Password is encrypted before sending it over network.
Flexible authentication mechanisms:
RADIUS supports following protocols for authentication purpose:
Point-to-Point Protocol - PPP
Password authentication protocol - PAP
Challenge-handshake authentication protocol - CHAP
Simple UNIX Login
RADIUS is extensible; most vendors of RADIUS hardware and software implement their own dialects.
And thus, RADIUS is stateless protocol using UDP (on port1812).
Dial PPP User
RADIUS provides some level of security for instance against sniffing or active attackers. Other authentication protocols provide either intermittent protection or inadequate protection or even no protection at all. RADIUS's primary authentication is TACACS+ and LDAP. LDAP by default provides no protection against sniffing or active attackers. TACACS+ is flawed (discussed by Solar Designer), it's still usable as it offers multiprotocol support such as IP and AppleTalk. Also a slight difference is that TACACS+ uses TCP while RADIUS uses UDP because TCP is a more reliable protocol and it is recommended by many administrators.
RADIUS hardware consistent support from its vendors is yet another reason that makes it more popular because the platforms on which RADIUS is implemented on are often embedded systems with limited opportunities to support additional protocols. Thus RADIUS is currently the de-facto standard for remote authentication and common for both new and legacy systems.
RADIUS protocol has a set of vulnerabilities which either caused by the protocol itself or by poor client implementation. Exploring furthermore RADIUS protocol vulnerabilities, it is giving us the ability to analyse each attack scenario with respect to our network and thus be more successful in defending it.
Hence, attacks regarding RADIUS protocol can be summarized into the following categories:
Brute-forcing user credentials
Denial of service
Spoofed packet injection
RADIUS installation and configuration
Installation took part using ubuntu linux distribution.
Identifying running version:
root@Zeus:~# cat /etc/lsb-release
Installing freeradius packet:
root@Zeus:~# apt-get install freedadius
Installing LDAP support:
root@Zeus:~# apt-get install freeradius-ldap
Reloading freeradius and making sure that it is running on our system:
root@Zeus:~# freeradius reload && ps x | grep freerad
1381 ? Ssl 0:00 /usr/sbin/freeradius
6686 pts/0 S+ 0:00 grep freera
investigation and implementation of types of threats
Sniffing RADIUS packets
By "sniffing" RADIUS Accounting packets, it might be possible for an eavesdropper to perform a passive analysis of tunnel connections.
raddump interprets captured RADIUS packets to print a timestamp, packet length, RADIUS packet type, source and destination hosts and ports, and included attribute names and values for each packet.
The method of entering illegally into a password protected computer or server by trying with a specific system as password every word that could be found in a dictionary is called a dictionary attack. The same method can be potentially used in attempting to find the key necessary toÂ decryptÂ anÂ encrypted message or document.
The vulnerability to dictionary attacks is on the fact that many computer users and businesses are using everyday words as passwords. The vulnerability to dictionary attacks is significantly minimised when multiple-word phrases or random combinations of uppercase and lowercase letters mixed up with numerals are employed. The more sophisticated brute-forceÂ method of attack which tries every possible combination of characters and spaces for a certain maximum length can increases vulnerability but also requires longer time to produce results.
A way to almost remove vulnerability to password or decryption-key assaults is to put a limit on the number of attempts allowed within a given period of time, and to choose a more sophisticated password or key.
Spammers are commonly using a type of dictionary attack. In this kind of attacks a message is sent to all e-mail addresses consisting of a ordinary word, and followed by theÂ symbolÂ (@), followed by the name of a particular domain. Lists of peoples' names return many results. Equally effective could be single letters of the alphabet followed by surnames. This risk once more could be minimised by adopting usernames that are long, they do not have a logical meaning or sequences of letters interspersed with numbers.
A design flaw in the RADIUS specification allows an attacker with access to network traffic to intercept an MD5 hash containing only the shared secret and known data. This allows a brute force dictionary attack to be launched against the shared secret.
Man in the middle attack
A general type of attack is called Man-in-the-Middle attack. It is commonly refered as "TCP (session) hijacking attack". The idea behind, is that the intruder aims to gain access to a genuine user's session in order to tamper it. The attack usually starts with sniffing and eavesdropping on a network stream, and ends with trying to alter, forge or reroute the intercepted data.
A common MITM attack scenario occurs when the attacker gets into the communication between a client and a server. In such scenarios, the attacker often transmits fraudulent messages between the client and the server to make them feel safe in communicating with each other. Technically, the attacker can use a program which appears like a server to the client and a client to the server.
The client/server scenario can be simply illustrated and demonstrated in fig. 2.
Client requests Http://my.bank.co.uk/, man in the middle then acts as a client and parses the request to the server which server now recognizes man in the middle as client and requests to switch to SSL (Secure Socket Layer) and yet man in the middle switches to Https://my.bank.co.uk/. Server response with secure content and man in the middle passes it on to the Client without SSL Http://my.bank.co.uk/. Client then enters his login credentials or private information and parses it on. Client's credentials are then captured by man in the middle (in plain text) which then parses data to the server.
Request passed to server
Server asks to switch to:
Attacker connects to:
Attacker passes it on as response of:
Client sends unencrypted
Login credentials or
Attacker passes data as nothing happened
Attacker now has login
Credentials or private data
In MITM attacks, the attacker tries to get between two target network endpoints, and proxies all the communication between them. Once the trial is successful, further attacks to be launched may include sniffing the passing packets, hijacking already authenticated sessions, injecting packets or commands to the server, and sending the forged responses to the victim client.
MITM attacks are mainly intended for sensitive and valuable information. MITM attacks are usually selected to intercept both HTTP and HTTPS communications. However, for a MITM attacker to be successful needs to direct the target endpoint (i.e., the victim) to the attacker's proxy server avoiding the real server.
Usual objectives for MITM attacks are to be granted access to the client's messages and alter them before finally transmitting them to the server end or to mislead the communicators at the client or server end, to intercept relevant information and also manipulate transactions.
According to year 2008, wireless local area networks have already pervaded 47% of enterprises. With the growth of such WLAN usage and without adequate safeguards, wireless brings corporate networks facing new attacks and furthermore results of unpleasant situations.
Such attack categorised into 5 sections:
Access control attacks
These attacks attempt to penetrate a network by using wireless or evading WLAN access control measures, like AP MAC filters and 802.1X port access controls.Â
These attacks attempt to intercept private information sent over wireless associations, whether sent in the clear or encrypted by 802.11 or higher layer protocols.
These attacks send forged control, management or data frames over wireless to mislead the recipient or facilitate another type of attack (e.g., DoS).
Intruders use these attacks to steal legitimate user identities and credentials to access otherwise private networks and services.
These attacks impede delivery of wireless services to legitimate users, either by denying them access to WLAN resources or by crippling those resources.
authentication mechanisms and protocols
EAP was originally anticipated for Point-to-Point Protocol (PPP, IETF RFC 1661) as an optional authentication phase after the PPP link has been established.
Different authentication mechanisms can be in the Authentication layer as Fig TADE describes which are based upon EAP authentication method.
Extensible Authentication Protocol (EAP)
EAP over LAN (EAPOL)
Data Link Layer
One of the most essential factors of an 802.1X implementation is the authentication method used to authorize user access to the network. These methods control how user credentials are passed across the network and how the RADIUS server and clients are validated using digital certificates.
The authentication dialog between the supplicant and access point must be negotiated between them as part of the EAP dialog. Mutual authentication and the creation of a shared session key as part of the authentication method is essential in terms of both parties to have cryptographic evidence of each other's identity.
A number of EAP methods that are suitable for wireless authentication have been submitted to the Internet Draft library of IETF and furthermore discussed above.
EAP-MD5 (IETF RFC 1321) authenticates LAN stations through a RADIUS server by verifying an MD5 hash of each user's password. It's one of the most popular EAP types because it's easy to use. This method sends passwords in clear text, which allows an attacker to sniff the password hashes and station identities. Attackers can also masquerade as an access point in order to trick stations (supplicants) into authenticating through them. There is no certificate required for this method. A simple implementation of EAP-MD5 message flow described in Fig.
RADIUS Access Request
RADIUS Access Challenge
RADIUS Access Request
RADIUS Access Accept
RADIUS Access Reject
EAP-TLS (IETF RFC 2716) is an authentication method that requires the validation of the authentication server (RADIUS) and the machine (supplicant) via a digital certificate (based on X.509) or smart card. This handshake is encrypted over a TLS tunnel which makes passwords and other data transmitted less vulnerable to attacks. This method requires both RADIUS server and machine certificates. A CA that supports auto enrolment can dramatically minimize the administrative overhead on this implementation. Authentication process and message exchanges of EAP-TLS in a WLAN illustrated in Fig
RADIUS Access Request
Thus, it is tough to man-in-the-middle attacks as we do not really care if an attacker is intercepting the exchange. Its proper implementation resists on such attacks.
After the certificate exchange, there is a shared session secret between the authentication server and the supplicant. Once the authentication server supplies this to the authenticator system (access point or switch) via their secure link, the authenticator system and the supplicant can then use it to bootstrap their per-packet authenticated, secure communication.
EAP-TLS requires the complexity of a PKI to support supplicant authentication. This may be acceptable in large corporate deployments, but is likely to be burdensome for SOHO and small and medium enterprise deployments. A strong password authentication method with User ID and Password is a more practical authentication for many public deployments.
EAP-TTLS is designed to be as strong as EAP-TLS but it does not require the use of client certificates. Only the authenticating RADIUS servers are issued certificates in this protocol which can save substantial deployment time if the organization does not currently have a Certificate Authority infrastructure. User authentication is achieved by passwords but the credentials are transported over a secure, encrypted tunnel that is established using the server certificates.
TTLS avoids much, but not all of the PKI complexity of TLS. Authentication servers must have Certificates and supplicants must be configured with the root certificate of the authentication server to validate the authentication server's name within the authentication server certificate in order to avoid the SSL man-in-the-middle attack from a rogue access points. Supplicants must also use form of certificate validation to be sure that the authentication server's certificate has not been revoked. A solution for that would be CRLs or OCSP which are both protocols for checking Certificate Revocation.
PEAP uses TLS to create a tunnelled, encrypted channel between a PEAP client and a RADIUS server. It does not specify an authentication method; instead, it provides additional security for other EAP methods such as Microsoft Challenge Handshake Authentication Protocol version 2 (MSCHAPv2, IETF RFC 2759), which functions through the TLS tunnel. PEAP supports the fragmentation and re-assembly of messages, giving us the ability to use EAP types that do not support this over the PEAP tunnel.
To mitigate the complexity and cost of deploying the user certificates required to support EAP-TLS, two methods have been proposed that use a server side certificate to allow authentication of the server and creation of an EAP-TLS tunnel that then carries other authentication methods over the tunnel. The two methods that have been proposed are EAP-PEAP (Protected EAP) and EAP-TTLS (Tunnelled TLS). Same as in EAP-TTLS in order to avoid the SSL man-in-the-middle attack from a rogue access points, supplicants must also use form of certificate validation to be sure that the authentication server's certificate has not been revoked. A solution for that would be CRLs or OCSP which are both protocols for checking Certificate Revocation.