linker.pp.ua Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:

2G - GSM / Bulletproof Wireless Security - GSM, UMTS, 802.11, And Ad Hoc Security (2005)

3.46 Mб


Security and the

Layered Architecture

3.1 Introduction

We have now looked at the core concepts and some of the most popular protocols used in network security. There is however, an architecture question which still needs to be answered. Most network protocols are based on the concept of a layered architecture where each layer is dedicated to fulfill a certain function. The question now is: which layer is responsible for providing network security?

The answer depends on which network we are talking about. In the next few chapters we will look at three different kinds of networks: traditional wireless networks (voiceoriented), wireless local area networks (data-oriented), and wireless ad hoc networks. Since most networks in the near future are envisioned to be IP-based, we look at the layered architecture of IP networks in this section.

Figure 3.1 shows the layered architecture of IP-based networks. The IP layer is the glue layer which holds together the various link layer and transport layer protocols. Each layer implements a specific set of functionality which is used by the higher layer(s).





Figure 3.1: The OSI Layer Model

Layer 7




Telnet, FTP, NFS, NIS


Layer 6





for example, RPC


Layer 5





Sockets/Streams - TLI




Layer 4









Layer 3











Layer 2

Physical Protocol


Data Link



Layer 1

Transmission medium



Coax, Fiber, 10baseT...






Chapter 3

From a security prospective, the question is where to implement the various security algorithms. Unfortunately, there is no single correct answer to that. There is however an ideal answer—at every layer. Implementing security at every layer may appear to be redundant but a closer look would reveal the need for it.

Let’s start from the lowest layer. If the physical layer provides security, does any other layer need to implement security?

3.2 Security at Layer 1

Layer 1 deals with the physical transmission of the bits over the medium and covers topics like channel coding and modulation. Traditionally, security has not been a domain of Layer 1 protocol planners. However, in the wireless world, the advent of spread spectrum protocols does provide a certain amount of security at the physical layer. Spread spectrum protocols like Direct Sequence Spread Spectrum (DSSS) and Frequency Hopping Spread Spectrum (FHSS) were designed with the aim of minimizing the effects of interference from narrow band sources. DSSS works by using orthogonal spreading codes to spread the signal. What this means is that to transmit 1 bit of data the protocol in fact transmits 8 bits (referred to as chips). This has the effect of increasing the signal bandwidth eight times. It is this increase in the signal bandwidth transmission which protects it from narrow band interference. The chip sequence used to convert a single bit of data to 8 bits of transmission is what provides the inherent security in the protocol. Arguably, if an eavesdropper does not know the chip sequence, he cannot access the wireless signal. Similarly, FHSS spreads

the signal by continuously changing the carrier frequency (frequency hopping). The frequency hopping sequence (that determines which carrier frequencies to use next) is effectively “the code” here. If an eavesdropper does not know the frequency hopping sequence, he cannot physically access the wireless signal.

It is important to emphasize here that these protocols provide no cryptographic protection. The “security” provided by these protocols stems from keeping the codes (chip sequence/frequency hopping sequence) secret. Since the codes themselves are not cryptographically protected and are usually well known (or easy to figure out), the security is often enough only to keep out the most casual of eavesdroppers. It is therefore better to think of physical layer security as a deterrent, especially against denial of service (DoS) attacks (think frequency-jamming).


Security and the Layered Architecture

3.3 Security at Layer 2

Layer 2 is concerned with establishing link-layer connectivity; that is, connecting devices to each other. Again, Layer 2 protocols traditionally have not had any security built into them. The design objective of IP (the most dominant Layer 3 protocol today) was to bind together various Layer 2 protocols so that higher layer protocols could be designed independently of the underlying channels. It is therefore instinctive to implement security at the IP layer rather than trying to design protocols for each link layer independently. In the wired world, the biggest deterrence at Layer 2 is physical access to the media.

Consider a local area network (LAN) designed using 802.3 (Ethernet). This LAN would consist of the physical wires, switches and hubs. To connect to such a LAN, a user would typically have to physically “plug-in” his computer into a switch or a hub. In other words, a user needs physical access to the network to connect to it. This

requirement of having physical access to the network to connect to it serves as a security mechanism at Layer 2. This is not to say that there are no security protocols used in wired networks at Layer 2. We will see one such protocol in a moment. The point is that wired networks have an inherent security mechanism (physical access) which is missing in wireless networks.

3.3.1 Extensible Authentication Protocol (EAP)

Even though wired networks offer an inherent security hurdle by requiring physical access to the network, this alone is in no way a sufficient protection mechanism. Several Layer 2 security protocols have been designed, but probably the most relevant one for our purposes is EAP. To understand the design and the motivation behind EAP, a little background is necessary.

The most popular way of connecting to the internet today is to dial in over the phone line using a modem. The protocol used for this is Point to Point Protocol (PPP). From a system architecture view point, the service provider maintains a Point of Presence (PoP) in every geographical region where it wishes to provide service. The PoP acts like a network switch connecting user modems to the Internet. However, before allowing any user connection to the Internet, the service provider would like to authenticate the user. Since any user should be allowed to connect to the Internet from any geographical area and since each PoP cannot be expected to maintain the credentials of all subscribers, we have to offload the authentication process to a remote site which maintains a central repository of all user credentials. This is the authentication server. Now, we have three parties involved in the authentication process: the supplicant (the


Chapter 3

user trying to gain access), the authenticator (the PoP, which acts as the direct point of contact to the supplicant and controls access to the network) and the authentication server (which is responsible for actually authenticating the supplicant). The authentication server is therefore the decision-maker and the authenticator is the one which implements this decision. The communication protocol used between the authenticator and the authentication server is Remote Access Dial-In User Security (RADIUS). This system architecture is shown in Figure 3.2.










Dial PPP






Figure 3.2: Authentication Model for Dial-In Internet Access

The PPP protocol specifies two authentication protocols that can be used: Password Authentication Protocol (PAP) and Challenge Handshake Authentication Protocol (CHAP). The former uses a username-password-based scheme where the usernames and the passwords are transmitted in plaintext. Obviously, it is not a very secure protocol. The latter uses a challenge-response-based mechanism which is much better than PAP, but still not considered strong enough, especially given the processing power available today. The problem is that anytime someone wishes to use a different authentication method with PPP, they have to go register the authentication method with Internet Assigned Numbers Authority (IANA). This is not as easy as it sounds, since the IANA has to keep in mind the existing the PPP compliance systems. It is to get around this problem that the EAP was designed.

The EAP (RFC 2284, RFC 2284bis) is not really an authentication protocol. It is actually a transport framework which runs over link layer protocols and supports multiple authentication mechanisms. The availability of this framework means that once EAP has been implemented over the link layer in a given setup, various authentication protocols (MD5, TLS and so on) can be plugged into it dynamically without affecting the rest of the system architecture.

The EAP framework is peer-to-peer and is based on requests and responses. An EAP-based authentication usually starts with the authenticator sending an identity request to the supplicant. On receiving this request, the supplicant replies with an identity response which may contain its login, username, MAC and so on.


Security and the Layered Architecture















































































































































































































RADIUS Access-Request




































RADIUS Access-Challenge


































RADIUS Access-Request



















RADIUS Access-Accept

























Port Authorized


Port Unauthorized

Figure 3.3: The EAP Architecture

On receiving this message, the authenticator (switch) reformats this message as a RADIUS-Access-Request message and forwards it to the backend authentication server. The authentication server now starts the authentication process using an appropriate authentication protocol. The messages sent by the authentication

server are simply reformatted as EAP messages and forwarded to the supplicant by the authenticator. Note the role of the authenticator as a “pass-through” during the authentication process.

Once the authentication process completes, the RADIUS server issues a RADIUS- Access-Accept message. On receiving this message, the authenticator not only forwards it to the supplicant but also opens the “controlled port” to allow the supplicant access to the network. The network port is now said to be in authorized state. On the other hand, if the RADIUS server issues a RADIUS-Access-Reject message because of an authentication failure, the authenticator does not open the controlled port, thus restricting the supplicant from accessing the network.

The use of EAP has several advantages. First, EAP allows any arbitrary authentication protocol to be exchanged between the supplicant and the authentication server. Second, the authenticator does not have to understand each authentication method and may act as a passthrough agent for a back-end authentication server. This separation of the authenticator from the backend authentication server allows for higher flexibility and simple, low-cost authenticators. Additionally, this separation simplifies key and credentials management by concentrating this function at a back-end server. All these features make EAP ideally suited for PPP (and also for 802.11, as we shall see later).


Chapter 3

However, there are several drawbacks of EAP too. First, even though EAP is peer-to- peer and supports authentication in both directions (A may authenticate B and B may authenticate A), there is no inherent mechanism in EAP to tie the two authentications together as part of a session.

Second, EAP does not provide protection against a forged “EAP-success.” Since the success message is not cryptographically protected, it may be forged by a malicious Eve, thus nullifying any previous authentication procedure.

Third, EAP does not provide any mechanism to link the authentication procedure to the following session. It leaves this as the responsibility of the link layer stating that “…. it is necessary for the lower layer to provide per-packet integrity, authentication and replay protection that is bound to the original EAP authentication …”

3.3.2 EAPoL: EAP Over LAN

Though originally designed for PPP, EAP can also used in traditional LANs with the end-user’s computer serving as the supplicant, the switch or hub serving as the authenticator and a backend server being the authentication server. IEEE 802.1X (EAPoL) specifies how to do this.

The standard specification of IEEE 802.1X (henceforth referred to as 802.1X) states that “(it) …is a mechanism for port-based network access control that makes use of the physical access characteristics of IEEE 802 LAN infrastructure in order to provide a means of authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics, and of preventing access to that port in cases which the authentication and authorization process fails.”


– Controlled Port

802.1X Entities






File Server



Authentication Server

Figure 3.4: EAP Over LAN


Security and the Layered Architecture

In simpler terms, 802.1X specifies how to implement EAP over IEEE 802 LANs. For this reason, 802.1X is also referred to as EAP over LAN (EAPoL). In 802.1X, the supplicant requests access from an authenticator. The authenticator creates two ports for this supplicant—the controlled port and the uncontrolled port (see Figure 3.5).





Authentication Server


































Switched or






Shared Ethernet







Authorized LAN




Figure 3.5: Ports in EAP model

It is important to note that the “ports” being mentioned here are logical entities. The controlled port is initially kept in a closed state and is opened only when the authentication server instructs the authenticator to do so. The authentication process between the supplicant and the authentication server is carried out over the uncontrolled port. The uncontrolled port works by allowing only EAP packets from the supplicant to pass through into the network. The EAP packets received by the authenticator are passed through to the authentication server. If the authentication server is a physically separate device, the authenticator relays these packets using RADIUS. When the authentication server completes the authentication process, it sends an “accept” or “reject” message to the authenticator and the supplicant depending on the outcome of the authentication process. If the authentication process was successful, the authenticator opens the controlled port, thus allowing the supplicant access to the network.

Note that in Figure 3.5, the authenticator combines the use of EAPoL with addressbased authentication mechanism as mentioned in Section 2.3.1.

3.3.3 EAP-TLS: TLS Handshake Over EAP

Authentication methods may be divided into two broad categories: those which result in the establishment of a security context1 at the end of the authentication process (TLS and so on) and those which do not (MD5, SHA and so on). Since EAP in itself

1 For an explanation of the term security context, see Section 2.3.7


Chapter 3

does not provide for an establishment of the security context, it is usually prudent to use EAP with an authentication protocol which establishes a security context. EAPTLS is such an example and we look at it in more detail here.

As explained in Section 3.5, Transport Layer Security (TLS) was initially (RFC 2246) designed to be a library of wrapper functions around the socket layer. However, RFC 2716 modifies TLS to sit over EAP and calls it EAP-TLS. Using TLS as the authentication protocol has the additional advantage that Alice and Bob do not need to have a preshared secret to authenticate each other: instead, such a premaster key is established at run time since TLS is a context-establishing/key-generating authentication protocol.

Figure 3.6 shows an EAP-TLS exchange using DH where mutual authentication is successful from the perspective of the supplicant (Alice) and authenticator (Bob). The backed RADIUS operations to the authentication server are not shown for simplicity. For details of the TLS messages contained inside the EAP requests/responses refer to Section 3.5.

EAP-TLS ensures that the master secret derived from TLS is not used during the session since this secret (read key) has already been used in a previous context (that



EAP-Request: ID

EAP-Response: ID

EAP-Request: TLS_Start

EAP-Response: TLS_Client_Hello

EAP-Request: TLS_Server_Hello

TLS_Server_Cert, TLS_Server_Hello_Done

EAP-Response: TLS_Client_Key_Exchange

TLS_Client_Change_CS, TLS_Client_Finished

EAP-Request: TLS_Server_Change_CS


EAP-Response: Null Data

Figure 3.6: EAP-TLS


Security and the Layered Architecture

of the handshake session). Instead, new keys are derived from the TLS master secret as follows:

K1 (128 bytes) = PRF (master_secret, "client EAP encryption," ClientHello.random+ServerHello.random) K2 (64 bytes) = PRF ("", "client EAP encryption", ClientHello.random+ServerHello.random)


= K1 (Bytes



= K1 (Bytes

32–63) or same as Alice_to_Bob_Encryption_Key.


= K1




= K1


96–127) or same as Alice_to_Bob_Authentication_Key.


= K2




= K2



3.4 Security at Layer 3

Layer 3 is responsible for providing end-to-end connectivity. Compare this with Layer 2 which provides link-layer connectivity. Perhaps an example would make things clearer. Consider what happens when you want to connect from your office computer to a website. Layer 2 is responsible for connecting2 your computer to your office local area network (LAN) whereas Layer 3 is responsible for connecting3 your computer to the web server.

The Internet Protocol Security (IPSec) protocol works at Layer 3 of the Open Systems Interconnection (OSI) protocol stack. Since Layer 3 of the network stack sits inside the operating system itself, IPSec code is bundled in the operating system too, and is therefore transparent to all applications. The advantage of this architecture is that the responsibility of security is removed from the application developer and can be centralized at the operating system level. Proponents of this architecture argue that centralizing security is better than modifying each application.

The IPSec protocol can be understood in two parts. First, we have the Internet Key Exchange (IKE) protocol, which is responsible for authentication and session key establishment between the two communicating parties. Second, we have Authentication Header (AH) and Encapsulating Security Payload (ESP): the IP header extensions which are used for carrying information that is needed to decrypt and verify the encrypted or integrity-protected IP packet.

Before we delve into the details of IKE, AH and ESP, let us take a brief overview of how IPSec works. Remember that the aim of IPSec is to protect the communication between two IP addresses. However, one IP address might be communicating with


This includes transmission and reception of packets to and from the LAN.


This includes routing of packets to and from your computer to the web server.


Тут вы можете оставить комментарий к выбранному абзацу или сообщить об ошибке.

Оставленные комментарии видны всем.

Соседние файлы в папке 2G - GSM