CS687 - Network Security V5.5 - Spring 2013

CS687 Information Systems Security
Network & Application Security
HiLCoE School of Computer Science & Technology
Course objectives
Professional Career Research orientation Certification Technical security (Main focus) Managerial security
Text Book
William Stallings & Lawrie Brown, Computer Security: Principles and Practice, Pearson, 2008
References
Bruice Schneier, Applied Cryptography Protocols, Algorithms, [], Second Edition, Wiley Student Edition, 2006 Stuart McClure et al, Hacking Exposed, McGraw Hill, 2009
Approaches to Network Security

o Architectural:
Preventive Security o Organizational: Defensive Security (Topic for next chapter)
Organizational
Design of secure network layout for an organization Firewalls Perimeter security DMZ Bastion Hosts Intrusion detection system Security policy and management
Architectural
The role of trust in Multi-Layer Security Integrating security in OSI RM Layer 2 Security: Switches, Vlan, ... Layer 3 Security: IPSec Layer 4 Security: SSL Application Security
The OSI RM
The Role of Trust

in the design of Multi-layer security
The OSI RM layer boundary does not necessarily imply trust boundary.
Where shall security services be integrated?

Application layer only? Physical layer only? Network layer only? At all layers?
Where shall security services be integrated ...
Does layer boundary implies trust boundary? Is security an all time need? What is the implication of encryption based security to the architecture? Would a non-encryption based (if any) security change the architecture?
Trust and Security
Service User Service Provider Definition
A Service Provider (SP) can be an application program, a router, a firewall, a communication link or any process or device providing a certain service.
A Service User (SU) is a subject that gets a service from a service provider. An SU can be an end user, a LAN, a router, a firewall or any process or device as far it is in the role of getting a service from a particular SP.
SU vs SP Examples

A user using a login program. A LAN using an Internet facing router. The upper three layers (Layer 7, 6, 5) using the reliable data transfer service of the underlying Transport Layer Entity. A host using the communication link to download file from a local FTP site. A Transport Layer entity using the routing service of the underlying Network Layer entity.
Service User vs Service Provider Scenario 1
Service User 1
Service User 2
Service Provider
Service User vs Service Provider Scenario 2
Service User
Service Provider
Threats Re-classified
Service Users vs Service Provider
When two SUs communicate using an SP:

Attacks can be mounted by the service users themselves because they may not trust each other.
Attacks can be mounted within the service provider because the SP may not be trusted by the SUs
Threats by the service users

Masquerade/Impersonation Sender repudiation Receiver repudiation
Threats within the service provider

Illegal data disclosure Illegal data modification Traffic analysis Denial of service
Trust Relationship
Service User to Service User
Horizontal Trust: This is a trust relationship between the communicating service users. An absence of this trust leads service users to apply one-way or mutual authentication and nonrepudiation. Note, however, that data protection (such as confidentiality, integrity, etc) is not needed because of an absence of horizontal trust.
Trust Relationship
Service User to Service Provider
Vertical Trust: This is a trust relationship between a service user and its underlying service provider. Absence of vertical trust is assumed because of the following reasons:
1. 2. 3.
SP is itself a threat agent (ie. Not trusted). Service provider do not provide protection measures. Protection measures provided by the service provider may not be adequate.
Trust Relationship
Service User to Service Provider
An absence of vertical trust leads peer service users to protect their data against illegal disclosure, illegal modification, traffic analysis and denial of service. Interestingly, if there is no vertical trust, horizontal trust can not be asserted. Reason being masquerade threat can be mounted with the assistance of the SP. Absence of vertical trust is the characteristics of many large networks and Internet.
Trust and Multi-layer security

Different Scenarios
Scenario 1: A security policy that enforces all communication on an Ethernet LAN to be confidential due to the fact that the cables are exposed to different eavesdropping attacks. Scenario 2: A branch of an organization connected to the HQ thru an (obviously) untrusted Internet. Scenario 3: A client working on a trusted LAN of a branch of an organization trying to get connected to a Linux machine on a distant trusted LAN of the HQ over an Internet. Scenario 4: A user checking his bank account status connecting from an internet caf.
Scenario 1: Enforcing all communication on an Ethernet LAN to be confidential.
FTP Server
Client Machine
Scenario 1
In this scenario, the communication link is un-trusted Service Provider. A host, being a service user with respect to the communication link, should apply protection before the data leaves the host.
Host A
Host B
Un-trusted SP
Scenario 1

Protection measures can be applied at any layer but mainly at lower layers. Which particular layer is more appropriate? However, since Ethernet is a broadcasting medium, it is more appropriate to incorporate the measures at Layer 2. In this scenario, the protection measures can be dictated by the security policy and it is appropriate to activate them irrespective of whether or not a particular host requested for.
Scenario 2: A branch of an organization connected to HQ.
I n t e r n e t
HQ LAN
Branch LAN
Scenario 2
Branch Gateway
SU1 Service Provider
HQ Gateway
SU2
Internet
Scenario 2
The trust boundary is at Internet facing gateway on both ends. Any protection measures applied at the two routers is sufficient for the protection of the whole communication. This is Layer 3 protection. This protection is to be activated/deactivated by the system management. Individual hosts may incorporate additional measures (if they need to) at upper layers but not at Layer 2 or 1.
Scenario 3: A client working on a trusted LAN of a branch of an organization trying to get connected to a Linux machine on a distant trusted LAN of the HQ over an Internet.
Client Machine
I n t e r n e t
Linux Machine
HQ LAN
Branch LAN
Scenario 3
Users Machine Linux Machine
Service Provider Internet
Scenario 3
Note that Scenario 3 is similar to Scenario 2 except that user authentication is required on top of other data protection measures already seen in Scenario 2. As far as data protection is concerned, the trust boundary remains at the Internet facing gateway on both ends. User authentication, however, can not be delegated to the gateway or the authentication provided at the gateway is not adequate for the User-to-Linux communication. Authentication shall not be delegated due to auditing as well. Since the upper four layers are in Users Space, the authentication can be enforced there. Hence, the Login Application, for instance, may use SSL to do that.
Scenario 3
In addition to user authentication, if the Linux security policy requires that the users machine shall also be authenticated, we will have the following situation:
Linux Machine Users Authentication
Users Machine
Router Protection Host Authentication && Data protection Service Provider Internet
Scenario 3
If a particular user in the branch LAN has a reason not to trust the LAN, he has to use data protection measures at the Upper Layers in addition to authentication.
Users Authentication & data protection Linux Machine
Users Machine
Router Protection Host Authentication R Service Provider Internet

Scenario 4: A user checking his bank account status connecting from an internet caf.
In this case, the assumption is that not only the network but also the host itself can not be trusted. The host can not be delegated to do the authentication or data protection measures (using users private key). Smartcard is the appropriate solution in such cases. The above scenario is also valid for ATM.
Security Redefined
Service User vs Service Provider
The authentication of service users and protection of the data, exchanged through the medium (ie. intervention) of an untrusted service provider.
Security Redefined
Service User vs Service Provider
Security services provided are to the benefit of service users. Consequently, encryption based security services use security parameters of the beneficiary. Security services, however, can be delegated to a trusted lower entity within the trust boundary as in the case where LAN security is delegated to Internet facing router.
Trust and Security FU

Authentication
Authentication and repudiation shall be implemented as closest as possible to the beneficiary. Authentication, however, can also be implemented at one of the bottom layer for two reasons: To accept lower layer entity authentication (eg. Host authentication at Network Layer) as sufficient for upper layer entity authentication (eg. End user authentication).
To enforce two level authentication (eg. End user and host authentication at the same time).
Trust and Security FU

Data Protection
Data protection services (confidentiality, integrity, etc) shall be implemented at the bottom most layer in the trust boundary.
To address different beneficiaries, data protection could, however, be integrated at different layers of the OSI RM.
Four Layers of Security
Link level Security: Layer 2 & 1 (Port security, Vlan, EAP, RADIUS, ECP, etc) Network Layer Security (IPSec) Transport Layer Security (SSL)
Application Layer Security (PGP, Ssh, etc)
Four Layers of Security Link Layer Security
Data link layer controls are applied to all communications on a specific physical link, such as a dedicated circuit between two buildings or a dial-up modem connection to an Internet Service Provider (ISP). It is not appropriate for end-to-end protection since this forces the intermediate nodes to be in the trust domain. It can be used to protect both IP and non IP networks. It provides a limited traffic confidentiality but not from the intermediate nodes. It can be provided both as a hardware and a software.

Network Layer Security
This protection is not application specific. Hence, it can be deployed without affecting the existing applications. Bulk protection can be applied rather than individual protection. It provides end-to-end (host) protection but not userlevel protection.
It allows to set and enforce security policies because it runs under the control of network administrators (unlike security measures integrated at Transport and Application Layers). However, it can not be used to secure selective applications which might be taken as a serious shortcoming because of the performance overhead of encryption based security services.

Transport Layer Security

It can provide user level protection. It can be used to protect the data in a single communication session between two hosts (not bulk protection). Hence, it can be used to protect selective applications or even selective data within an application. It is not (and should not be) tuned to particular applications. It is the applications that tune to it in order to exploit the capabilities provided. It provides a tested and standard security utilities for the applications to use. It can not be used to conceal IP address because IP is added at the Network Layer.

Application Layer Security
Provides a high degree of control and flexibility over application security but it has to be done application per application. Application layer security is also needed simply because the underlying security provisions may not be trusted by the application users (& developers). Some standards, however, are tried for different applications: Secure Electronic Transaction (SET) Secure Mail Handling System (Secure SMTP, PGP) PCI DSS (Payment Card Industry ...) etc It may require a large resource investment to add and properly configure controls for each application. HiLCoE School of Computer Science &
Technology
Security in OSI RM
Functional Unit
Protocol Element
An FU is a specific capability of a layer. Connection establishment, data transfer, multiplexing, expedited data transfer are typical examples. Common FU (to all layers): connection establishment, data transfer, etc. Specific FU (to a layer): synchronization & dialog management are specific to Session Layer.
Functional Unit
Protocol Element
Indirectly active: not requested directly but invoked as a result of other FUs. Multiplexing is serviced only when data transfer is activated. Directly active: Activated on request basis. The request is made either by the user/application or by the system management.
FU Activation
FU activation is achieved in two ways:
Thru the QoS parameters
Thru service primitives
FU Activation
Thru QoS
An upper layer entity requests a FU to be provided at a lower layer (not necessarily immediate). The requested FU is serviced at the lower layer without the involvement of the requesting upper layer entity. The servicing entity usually collaborates with the corresponding entity on the other end of the communication to carryout the requested FU. The requesting upper layer entity is not involved in the servicing of the FU whether it is successfully carried out or not. Any necessary decision is taken by the servicing layer (entity).
FU Activation
Thru QoS
E1 E2
The requested QoS (FU) is served at this layer
FU Activation Thru QoS

To summarize, the QoS approach is a kind of delegation to the lower layer (by an upper entity) of both the servicing and the management aspect of the requested FU.
FU Activation

An N-Service is defined as a set of FUs offered to an (N+1) entity by the N Layer. An N-Service is provided by a collaboration of two peer (N) entities. It is not possible for an N+1-Entity to invoke services provided below the N Layer although the N-Service can, in turn, invoke the corresponding N-1 Service and so on. The outcome from the attempt to service the FU will be communicated to the requesting upper entity.
FU Activation
E1
E2
N-Service is served at this layer possibly in collaboration with lower layers
FU Activation
Confirmed N-Service
A confirmed service is one that involves a handshake between the requesting entity and the responding entity. Confirmed services do have four primitives:
Service.Request Service.Indication Service.Response Service.Confirmation
Confirmed Service
E1 E2
Req
.Conf
.Rep
.Ind
N-Service is served at this layer
FU Activation
Unconfirmed N-Service
An unconfirmed service involves no handshake. It consists of two service primitives:

Service.Request Service.Indication
Unconfirmed Service
E1
E2
Req
.Ind
N-Service is served at this layer
N-Service
Semantic
The semantic in OSI RM is that the corresponding entities on each layer collaborates to provide services to the upper entities. For instance, N-Connect is available in each layer. Consequently, corresponding entities are said to be connected to provide further services to their upper entities.
Security Functional Unit (SFU)

Security Services Use model
SFU List
Authentication Data origin authentication Confidentiality Data Integrity Access control Digital Signature Sender/Receiver non-repudiation Traffic confidentiality
SFU Use Model

Directly or indirectly active User activation or management activation QoS or N-Services
SFU Activation: How

Indirectly
active
versus
Directly
active
SFU Activation: How

Indirectly Active SFUs
Most SFUs are not to be invoked on their own. Rather they are often linked with some other basic services such as connection establishment, data transfer and the like. Consequently, most SFU shall not be Directly Active. An indirectly active SFUs are serviced only when certain services are requested. A single SFU may be associated to a combination of ORed or ANDed functional units.
SFU Activation: How

Indirectly Active SFUs
Authentication SFU can be associated to Connection Establishment. Data confidentiality, integrity and traffic confidentiality may be associated to nonexpedited data transfer.
SFU Activation: How

Directly Active SFUs
An SFU is said to be direct when it is invoked for its own sake. A good example is authentication, especially when it has to be invoked multiple times within a connection session.
SFU Activation: Who

Security shall be activated both by the user as well as by the system management.
SFU Activation: Who

User Activation
The ultimate beneficiary of an FU (including SFU) is the user. The user knows the particular circumstances that calls for protections. User must activate appropriate security on appropriate connections and sensitive data.
SFU Activation: Who

Management Activation
Security is optional and its activation depends on particular circumstances: sensitive data, insecure communication link, alarming conditions, etc Security posture is best managed by the management (than the user): Intrusion detection, firewall, log management, etc Management shall interfere in the activation: Enforce policy thru a number of ways including activation. Activating the appropriate SFU at the appropriate layer at the appropriate moment.
SFU: QoS or N Services
SFU thru QoS

Actual SFU can be integrated at a lower layer. Upper layer entities could simply invoke the SFU thru QoS. Security association parameters (eg. Keys) used are those of the service providing layer. The semantic of SFU is also within the service providing layer. For instance, the semantic of invoking the Transport Layer confidentiality SFU by an application entity is that the communicating Transport entities are to secure their communication using their own security parameters..
SFU thru QoS
Data protection services such as confidentiality, integrity, data-origin authentication and limited traffic confidentiality are appropriate candidates for QoS invocation.
A full-fledged traffic confidentiality, however, is assured not by separate invocation of individual entities or users. It is rather a matter to be enforced centrally by a system management.
SFU thru QoS
Authentication can not be delegated to lower layer entities. After all, auditing should reveal the real authenticated entities. For that reason, invocation of Authentication thru QoS may not be appropriate. However, lower layer authentication (eg. Host authentication at Network Layer) could be taken as sufficient by the application entity or else their authentication is required in addition to the authentication of the application entity. In such circumstances, invoking the lower layer authentication thru QoS makes perfect sense. Similarly, a digitally signed document at lower layer can not be taken as signed by an application entity or an end user.
SFU thru N-Service

The semantic is a little different from the QoS approach in the sense that the requesting entity directly invokes protection and takes decision depending on the outcome of the attempted security protection.
SFU thru N-Service

N-Authenticate
N-Protect: Confidentiality, Integrity, Digital Signature, etc
SFU thru N-Service

N-Authenticate
Entity E1 invokes N-Authenticate on its lower layer entity. Based on E1s request, the underlying entity authenticates the corresponding E2 through its peer entity on the same layer.
E1s security parameters are used on one side and E2s security parameters are used on the other side.
SFU thru N-Service

N-Authenticate
N-Authenticate must be a confirmed service:

N-Authenticate.Request N-Authenticate.Indication N-Authenticate.Replay N-Authenticate.Confirmation
SFU thru N-Service

N-Authenticate
N-Authenticate
do not replace NConnect. Rather, it is invoked after it and potentially several times during a single connection session.
N-Authenticate
should have the capability to break an established connection in case authentication could not be verified.
SFU thru N-Service

N-Protect
Entity E1 invokes N-Protect on its lower layer entity. Based on E1s request, the underlying entity applies protection measures on the data to be sent and invokes the normal data transfer service to its underlying entity. E1s security parameters are used to produce the protection. The corresponding layer entity on the other side verifies the protection using E2s security parameters. If verification is successful, the received data is transferred to E2; otherwise, the data is rejected. Eventually, E1 will be told about the success or failure of the protection so that it decides on subsequent actions to take. HiLCoE School of Computer Science &
Technology
SFU thru N-Service

N-Protect
N-Protect is just like a data transfer service except that protection measures are provided. N-Protect may serve data confidentiality, integrity, traffic confidentiality and data-origin authentication. The specific protection to apply on the data can be chosen as a QoS.
SFU thru N-Service

Traffic Confidentiality
As already mentioned, full-fledged traffic confidentiality is not a matter to be left to individual invocation and hence is not appropriate for the semantic of N-Service.
Link Layer Security
L2 Security
Switch Security Vlan ACL (& VACL) Authentication: RADIUS, EAP, WEP, WPA, etc N-tier Architecture (for switches) Ciscos 3-layered hierarchical model It has more to do with scalability, reliability, efficiency Availability is more of a concern from security p.o.v Wireless network security (together with L3 wireless HiLCoE School of Computer Science & router) Technology
L2 Sec: Essential Services

Encryption (on the wire) Authentication Access control Availability
Switches
Switches creates instant networks that contain only the two end devices communicating with each other at that moment in time. Switches maintain CAM tables to map the source addresses with the switch ports with which the sources are hooked. This table is populated by an address-learning process on the switch. If the destination address of a frame is not known or if the frame received by the switch is destined for a broadcast or multicast address, the switch forwards the frame to all ports.
Switch Security Threats

Mac Flooding MAC Address spoofing Vlan hopping (when vlan is in use) Spanning-Tree Protocol manipulation Physical access threats
L2Sec: Port Security

Mac address list (static) Max number of Mac addresses
Invalid address is blocked or port is shutdown
L2Sec: VLAN

Vlan allows to create different network segments within the same physical network (LAN). Vlan provides a separate broadcast (multicast) domain. Only computers within the same vlan can communicate. Vlans may also be created across a single switch. Most of the threats to a switch is now contained within a vlan. Protocol separation: different protocols can coexist in the same network (switch) but still logically functions independently. Example: IPX, HiLCoE School of Computer Science & Technology AppleTalk.
Vlan on a single switch

Taken from Tom Olzak
Vlan across switches

Vlan Configuration
Port assignment MAC address IP Subnet Dynamic assignment Device assignment Protocols Applications
Vlan: Port assignment
The default method specified in 802.1Q is to assign ports explicitly to VLANs within the switch.
In the figure on Page 91, any packet entering through port 2, 4, or 8 is automatically assigned to VLAN 10.
Vlan: MAC Address

An administrator can build a table of MAC address to VLAN pairs within the switch. When a packet arrives, it is parsed to retrieve the source MAC address and assigned to the appropriate VLAN. This is a way to maintain VLAN membership for devices that frequently move. It is, however, easier for an attacker to spoof a valid MAC address to gain access to the VLAN.
Vlan: IP Subnet
Each VLAN is assigned an IP address scope (a subnet). The switch parses a packet, locates the source IP address, and assigns the packet to the appropriate VLAN (dynamically).
Vlan: Dynamic Assignment

One approach particularly useful for wireless or remote devices is dynamic VLAN assignment. It is based on the authenticating users group membership (which may be managed by a third party service such as Active Directory). The switch might use a third party authentication server such as RADIUS to authenticate users. Once the user is authenticated, packets from his device are assigned to the appropriate VLAN. Adds security for shared wired VLAN ports. For example, both a staff and an outside partner could connect their laptop to Ethernet jacks in a conference room since they are both assigned based on authentication server and an active directory. HiLCoE School of Computer Science &
Technology
Vlan: Dynamic Assignment

DA adopts well with role-based access control. For instance, if a sales person moves to project management, access is automatically denied to the Sales VLAN and also is automatically included in the Project Management VLAN.
Vlan: Protocol Assignment
Some networks run multiple network protocols, such as IPX and AppleTalk. Switches assign packets to VLANs based on the protocol used.
Trunking
When using more than one switches to create VLANs, a trunk is configured between them using a port on each switch: a trunk port. During a broadcast, all VLAN packets entering either switch are sent via the trunk to the other switch. This allows VLAN members to exist in different locations.
Vlan across switches

Private VLAN
Pvlan limits connectivity even further: the ports within the pvlan could not communicate to each other. This is interesting in a situation where the individual systems (such as servers) serve other users (outside of this vlan) but they systems do not need to communicate to each other. If one of the systems is compromised, the other would still be unaffected.
Inter-vlan routing
Using a router. Using Layer 3 Switch.
Access Control List

Switches
uses two types of
acl: Basic acl Vlan acl
Basic ACL
Basic acl: filters L2 traffic based on source IP @ (standard) or based on source & destination IP @ plus (L3 and above) protocols. A traffic maybe dropped if it does not fall into the acl policy of the switch. Basic acl does not filter intra-vlan traffic.
Vacl: vlan access control list
VACL: Intra-vlan filtering

VACLs are assigned to VLANs. a VACL filters all traffic entering the VLAN or passing between same-VLAN members. A switch blocks any frame that does not meet the vacl policy for the particular vlan.
L2Sec: VLAN for security
MAC/CAM table overflow only floods traffic within the local VLAN so the intruder will see only traffic within the local VLAN to which he or she is connected. Reduces attack surface. Increases threat agents effort. Enables secure, flexible user mobility if vlan assignment is used dynamic based on user or device group membership (See 802.1x for port authentication). This can also be arranged using statically configured port assigned to a vlan. HiLCoE School of Computer Science & Most wireless systems assign a VLAN by coupling it Technology
L2Sec: VLAN for security

Vlan to mitigate certain threats such as Mac flooding Vlan as access control (see Vacl) Vlan for availability (thru limiting the traffic to the particular vlans only). Vlan limits the attack impact to the particular vlan to which the attacker is connected. reduces the attack surface (say for packet sniffing)

IP Security (IPSec) Router Security
IPSec: IP Security
Optional in IPv4 Mandatory in IPv6
IP Security
Security Services Confidentiality. IPsec can ensure that data cannot be read by unauthorized parties.
Integrity. IPsec can determine if data has been changed (intentionally or unintentionally) during transit. The integrity of data can be assured by generating a message authentication code (MAC) value. Peer Authentication. Each IPsec endpoint confirms the identity of the other IPsec endpoint with which it wishes to communicate, ensuring that the network traffic and data is being sent from the expected host.
IP Security
Security Services
Key Management: Replay Protection. The same data is not delivered multiple times. However, IPsec does not ensure that data is delivered in the exact order in which it is sent.

Limited Traffic Analysis Protection. A person monitoring network traffic does not know which parties are communicating, how often communications are occurring, and the like. However, the number of packets being exchanged can be counted. Access Control. IPsec endpoints can perform filtering to ensure that only authorized IPsec users can access particular network resources. IPsec endpoints can also allow or block certain types of network traffic, such as allowing Web server access but denying file sharing (a kind of firewall).
IPSec: The Big Picture

http://www.ciscopress.com/articles/article.asp?p=25474&seqNum=7
"Interesting traffic" initiates the IPSec process. Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process. IKE phase 1: IKE authenticates peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase 2. IKE phase 2: IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers. Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database. HiLCoE School of Computer Science &
Technology
IPSec onto IP
IPSec is not a separate full-fledged protocol at Network Layer. In fact, the main protocol remains IP. IPSec is grafted onto IP by extending the protocol header that follow the main IP header in an IP packet.
IPSec over IP
IP Header
Main Packet Header for IPv4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | version | IHL | DS | ECN | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification | Flags | Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time To Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HiLCoE School of Computer Science &
Technology
IPSec over IP
The Protocol field (of IP Header)
This field normally indicates the next higher level protocol in the TCP/IP stack that is responsible for the contents of the data field of the IP packet. The higher level protocols are designated by numbers: 1 ICMP 2 IGMP 4 IP (IP within IP for tunnelling protocol) 6 TCP 17 UDP 50 ESP (new - related to IPSec) 51 AH (new related to IPSec)
IPSec Components
Authentication Header (AH) Encapsulating Security Payload (ESP) Internet Key Exchange (IKE) protocols
IPSec Modes
Transport Tunnel
IPSec Modes
Transport
Provides protection primarily for upper-layer protocols. These include a TCP or UDP segment packet, all of which operate directly above IP in a host protocol stack. Typically, transport mode is used for end-to-end communication between two hosts (e.g., a client and a server).
IPSec Modes
Tunnel

Tunnel mode provides protection to the entire IP packet (Transport layer packet + IP Header). No routers along the way are able to examine the inner IP header which includes the source and destination addresses (among other items). Because the original packet is encapsulated, the new, larger packet may have totally different source and destination addresses, adding to the security. Tunnel mode is (commonly) used when both ends of a security association are security gateways such as a firewall or router that implements IPsec. With tunnel mode, a number of hosts on networks behind firewalls may engage in secure communications without implementing IPsec.
Authentication Header (AH)

Data-origin authentication Data integrity Replay protection
Authentication Header
The five fields
Next Header: This field contains the IP protocol number for the next packet payload.
In tunnel mode, the payload is an IP packet, so the Next Header value is set to 4 for IP-in-IP. In transport mode, the payload is usually a transport-layer protocol, often TCP (protocol number 6) or UDP (protocol number 17).
AH Len: This defines the length, in 32-bit words, of the whole AH header Reserved: This value is reserved for future use.
Security Parameters Index (SPI): Each endpoint of each IPsec connection has an arbitrarily chosen SPI value, which acts as a unique identifier for the connection.
Sequence Number: Each packet is assigned a sequential number which provides protection against replay attacks because duplicate packets will use the same sequence number.
Authentication Data: This field contains the MAC (ie the hash value). The recipient of the packet can recalculate the MAC to confirm that the packet has not been altered in transit.

Two Modes

Transport Tunnel

Transport Mode
The IP addresses of the source and destination hosts are used in the secure transaction. Used for host-to-host protection

Transport Mode

Transport Mode
As shown in the previous slide, part of the IP header is authenticated. ie: they are included in the AH protection which in this case means MAC is computed on them. IP Header fields not included are those that may change in transit such as TTL and Checksum.

Transport Mode
Exc: What would happen if NAT were used somewhere along the path?

Tunnel Mode
The IP addresses of the source and destination hosts are replaced by the source gateway and destination gateway IP addresses respectively. Used for gateway-to-gateway protection. In other words, the security needs of a network is met only by securing the gateway traffic (both outgoing and incoming).

Tunnel Mode

Tunnel Mode
As in the case of Transport Mode, only part of the Outer IP header is authenticated. Note, however, that the Inner IP header is totally authenticated. IP Header fields not included are those that may change in transit such as TTL and Checksum.
Example courtesy of: http://fengnet.com/book/VPNs%20Illustrated%20Tunnels%20%20VPNsand%20IPsec/ ch12lev1sec5.html
Data Integrity
Authentication Header (AH) Both Modes
A keyed hash algorithm creates a hash based on a message and a secret key shared by the two endpoints. The hash is added to the packet, and the packet is sent to the recipient. The recipient can then regenerate the hash using the shared key and confirm that the two hashes match, which provides integrity protection for the packet. IPsec uses hash message authentication code (HMAC) algorithms. Examples of keyed hash algorithms are HMAC-MD5 and HMAC-SHA-1. But, other hashing algorithms could also be negotiated between the parties.
Encapsulating Security Payload (ESP)

Confidentiality Data origin authentication Data Integrity Replay protection Traffic flow confidentiality (in tunnel mode)
ESP
Most implementations use both symmetric and asymmetric cryptography. Asymmetric cryptography is used to authenticate the parties (and key exchanges). Symmetric encryption is used for protecting the actual data (ESP).
ESP Header, Payload and Trailer
ESP Header, Payload and Trailer
ESP Header: SPI and Sequence Number.
ESP Trailer: Padding, Padding Length, and Next Header.

IV is used only when the encryption algo requires Initialization Vector. Payload is the upper layer data. Authentication Data is where the outcome of the hash is stored to be transmitted across the communication.
ESP Modes

Transport Tunnel
ESP
Transport
In this mode, the protection is applied on the IP payload. Host IP header is used to route the protected data.
This is useful for host-to-host protection.
ESP
Transport Mode
ESP
Tunnel
In this mode, the protection is applied on the whole IP packet including the header (that includes source and destination addresses). New IP header is pre-pended so that the original IP headers can be protected. Protecting the data helps it from being accessed or modified by unauthorized parties without being detected. Encrypting the IP header conceals the actual source or destination of the packet.
ESP Tunnel Mode
Example courtesy of http://fengnet.com/book/VPNs%20Illustrated%20Tun nels%20%20VPNsand%20IPsec/ch12lev1sec5.html
Internet Key Exchange
Negotiate, create, and manage security associations (SA). Security association constitute a set of values that define the IPSec features and protections applied to a connection. Examples of values are encryption algorithms, modes of operation, hash functions, key lengths, session keys, etc. Communicating parties negotiate on a security parameters to be used. SAs can also be manually created, using values agreed upon in advance by both parties. HiLCoE School of Computer Science &
Technology
Why Security Association?
The traditional TCP/IP connection does not exactly coincide with the security semantic in general (at all layers).
Eg: Same security parameters may be used across different connections between a given pair of entities. Eg: A security parameter may need to be changed while the actual connection is still active.
A need to define a security association that is appropriate with the semantics of the security services provided.
Security Association
IPSec
Security Associations are one way. A two-way connection requires at least two SAs. Furthermore, each protocol (ESP/AH) has its own SA in each direction. These are all kept in the Security Associations Database (SAD).
IKE: How to
Two phase exchanges:

Phase 1 Exchange
Phase 1I Exchange
IKE: How to Phase 1 Exchange
Successfully negotiate a secure channel, commonly known as IKE SA. An IKE SA may be established thru
Main mode: stronger security protocol but computationally expensive (six exchanges) Aggressive mode: Less secure and computationally less expensive (three exchanges)
IKE: How to Phase 1 Exchange

Negotiates encryption algorithms Negotiates Hashing algorithms Mutual authentication:
Kerberos PKI (thru Certificate Authorities) Manual shared keys (less secured)
Negotiates Diffie-Hellman group and exchanges secret key.

IKE: How to Phase I1 Exchange

Establish an SA for the actual IPsec connection, called IPsec SA. IPSec SA is one way. A two-way connection requires at least two IPSec SAs. Furthermore, each protocol (ESP/AH) has its own IPSec SA in each direction. These are all kept in the Security Associations Database (SAD).

The SAD includes the following information for each protected connection:
Source IP address, Destination IP address, SPI, IPsec security protocol (AH or ESP), Mode (transport or tunnel), Encryption algorithm for ESP, Integrity protection algorithm, Secret keys, Key length, SA lifetime, Sequence number,
The mode used to establish IPSec SA is called Quick Mode. Quick mode communications are protected by the method specified in the IKE SA created in Phase I Exchange.
Policy
A set of rules that govern how packets shall be processed in terms of the different security protections.
Policy
An IPSec policy consists of a set of filters, filter actions, and rules. A rule associates a filter with a filter action.
Policy: Filter (or Selectors)

Elements for policy formulation
The following fields are possible selectors:

A source IP address or range of addresses A destination IP address or range of addresses An IP protocol, such as TCP, UDP, or "any" Source and destination ports (for TCP or UDP only)
Policy: Filter Action
A filter action specifies which actions to take when a given filter is invoked. It can be one of the following:
Permit. The traffic is not secured; it is allowed to be sent and received without intervention. Block. The traffic is not permitted. Negotiate security (AH, ESP, Both). The endpoints must agree on and then use a secure method to communicate.

Negotiate security. The endpoints must agree on and then use a secure method to communicate.
If they cannot agree on a method, the communication does not take place. If negotiation fails, you can specify whether to allow unsecured communication or to whether all communication should be blocked.
RFC 2401 mandates that any datagram that does not have a matching policy must be dropped, but many implementations have a default policy that applies to datagram that don't match any explicit policies.
Policy: Mirroring
Most of the selectors (ie. Filters) are usually mirrored in order to allow both inbound and outbound communication. Example: The following two selectors are mirrors:
Allow an inbound connection from a host A to all the local ports. Allow an outbound connection from any port to host A.
Default Policy
UDP Port 500 is allowed by default since it is the port number used by IKE.
Policy Challenges
ICMP packets
Packet fragmentation
Dynamic policies
Policy: How it works

All communications are mediated by IPSec. 1. Determine if a communication requires IPSec 2. Negotiate and establish a secure connection 3. (Securely) Transmit the data
Transparency of IPsec to users and applications Restricted access to servers Customizable security configuration Support for automatic cryptographic key management
IPSec Implementation
RFC 2401 describes three possible implementations:
IPsec can be integrated into the TCP/IP stack itself. This implementation is probably the cleanest and most efficient but requires access to the kernel source and has the usual maintenance problems associated with kernel code. 2. IPsec can be added just below the TCP/IP stack, usually as a pseudo-device driver. Such implementations are called bump-inthe-stack (BITS) implementations. Because such implementations can use tunnel driver techniques, they don't necessarily require access to the kernel source code. 3. IPsec can be implemented as a stand-alone crypto device. Such devices are called bump-in-the-wire (BITW) implementations. Usually, such devices are added to a router or firewall, making the combination appear like a security gateway.
1.
IPSec Implementations in Linux
FreeS/WAN: First IPsec implementation available for Linux. Openswan: A continuation of FreeS/Wan strongSwan is also a continuation of FreeS/WAN. Kernel 2.6+ contains a native IPsec implementation, which is known as "NETKEY", "26sec" or "PF_KEY". This means that recent distributions ship with IPsec support out of the box. isakmpd: there is a Linux port of OpenBSD's ISAKMP daemon.
IPSec in Windows
Native support
The
Windows Server 2003 Windows 2000 Windows XP Windows Vista Windows Server 2008 Windows 7
Transport Layer Security
Secure Socket Layer
Secure Socket Layer

This lecture slide is mainly adopted from: http://fengnet.com/book/vpns%20illustrate d%20tunnels%20%20vpnsand%20ipsec/c h06lev1sec1.html
Secure Socket Layer

History
Originated in 1994 at Netscape, which was interested to secure certain transactions made within its Netscape Navigator Web browser. Release version is SSL 2. It was, however, discovered that SSL 2 (and its Netscape implementation) has serious security flaws due to the way the pseudorandom numbers were generated.
Secure Socket Layer

History
At the same time, other vendors were producing their own implementations. One of these, Microsoft's Private Communications Technology (PCT), addressed several shortcomings of SSL 2, and came with better security. In 1995, Netscape released SSL 3 specification.
SSL 3 included many good features of PCT, supported new algorithms, and as a whole become much more secure.
Many browsers currently use SSL 3.
Secure Socket Layer

History

In 1996, the IETF began an effort to standardize the SSL protocol. the new protocol was named the Transport Layer Security (TLS) protocol. TLS is based mostly on version 3 of SSL but with enough "minor" changes to make it incompatible with SSL 3. The TLS specification was finished in 1999 and published as RFC 2246.
Secure Socket Layer

Security Services
Authentication Confidentiality Data origin authentication Data Integrity Replay protection
Secure Socket Layer

Family of protocols

Handshake protocol Record protocol
Cipher change spec (Included in the handshake

protocol)
Security alert protocol
SSL Protocols
The Big Picture
SSL session has three stages: connection setup, data transfer, and disconnection.
In the connection stage, the encryption, authentication, and compression algorithms are negotiated; the identity of the server and, optionally, the client is verified, and a key exchange takes place. This is the domain of Handshake Protocol. In the second stage, the client and server exchange application data. These exchanges are encrypted and authenticated. This is Record Protocol.
In the third stage, one or both of the communicating entities send a closure notification to break the connection. Because the closure notification is authenticated, it can't be forged by a third party. This prevents malevolent parties from forging a TCP FIN and truncating the data prematurely. These (and others) belongs to the Alert Protocol.
SSL: Handshake Protocol
This protocol allows the client to authenticate the server (by default) negotiate an encryption and MAC algorithm, agree cryptographic keys to be used to protect payload data. The handshake protocol is used before any application data is transmitted. Sessions are created by the Handshake Protocol. Sessions are used to avoid the expensive negotiation of new security parameters each time a new connection is created.
SSL makes a distinction between a connection and a session. A connection represents one specific communications channel (typically mapped to a TCP connection), along with its keys, cipher choices, sequence number state, etc. A session is a virtual construct representing the negotiated algorithms and the master_secret . A new session is created every time a given client and server go through a full key exchange and establish a new master_secret. Multiple connections can be associated with a given session. Although all connections in a given session share the same master_secret, each has its own encryption keys. Resumption allows the generation of a new set of bulk keys and IVs from a common master_secret because the keys depend on the random values, which are fresh for each connection. The new random values are combined with the old master_secret to produce new keys.

Session Parameters
Session identifier: an arbitrary number chosen by the server to identify an active or resumable session state. Peer certificate: an X509.v3 certificate of the peer. This element of the state may be null (when a different method is used). Compression method: the algorithm used to compress data prior to encryption. Cipher spec: specifies the bulk data encryption algorithm (such as null, DES, etc.) and a hash algorithm (such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the padding, IV, and the like.
Master secret: 48-byte secret shared between the client and server.
Is resumable: a flag indicating whether the session can be used to initiate new connections.

Handshake messages
Type 0 1 2 11 12 13 14 15 16 20 Handshake Type HELLO_REQUEST CLIENT_HELLO SERVER_HELLO CERTIFICATE SERVER_KEY_EXCHANGE CERTIFICATE_REQUEST SERVER_HELLO_DONE CERTIFICATE_VERIFY CLIENT_KEY_EXCHANGE FINISHED

The four phases
The Handshake Protocol consists of a series of messages exchanged by client and server, in four phases.

The four phases

Phase 1. Establish Security Capabilities
Phase 2. Server authentication and key exchange

Phase 3. Client authentication and key exchange Phase 4. Finish
Phase 1: Establish Security Capabilities

Client_hello Server_hello
Phase 1: Establish Security Capabilities Client_Hello request

Request an establishment of a secure session by proposing crypto parameters or possibly resuming a previously negotiated session.

The major and minor version are the latest version of SSL that the client understands. This allows the server to determine which protocol version to use for the rest of the session. Both the client and server will contribute some random data that will be used for key generation. The random data changes with each ClientHello or ServerHello, helping prevent replay attacks.
The session ID is used to resume a previous session, thereby bypassing the key-generation phase, which requires considerable resources. If there is no intention of session resumption, the session ID length is set to 0. A list of the cipher suites is prepared, sorted in order of preference
SSL Cipher Suites
Phase 1: Establish Security Capabilities Server_Hello request

The server responds to the clients request by choosing the cipher suite of its preference, by putting a new session Id or else accepting to resume a previous one.
Severs generates its own random data. Chooses its preference of cipher suite. Adds a new session Id or accepts the clients resumption request.
Phase 2: Server Authentication and Key Exchange

Certificate (server sends its certificate to client) Server_key_exchange (It can be used with or
without Certificate)
Certificate_request (Opional: if sever also

wants to authenticate client)
Server_hello_done
Phase 2: Server Authentication and Key Certificate

This message allows the server to send its (CA signed) certificate to the client thereby allowing the client to retrieve the servers authentic public key for further use.
Phase 2: Server Authentication and Key Certificate
Phase 2: Server Authentication and Key Server_key_exchange (only if DH is used)
Phase 2: Server Authentication and Key Server_key_exchange
Phase 2: Server Authentication and Key Certificate_request (optional)

This message includes a list of certificate types (RSA signed, DSS signed, etc) and authorities that the server is willing to accept.
Phase 2: Server Authentication and Key Certificate_request (optional)
Phase 2: Server Authentication and Key Server_hello_done

This message is used to tell the client that the server has finished its hello sequence and that the client may begin the key-transfer process. It consists merely of a handshake header with a type of 14.
Phase 2: Server Authentication and Key Server_hello_done
Phase 3: Client Authentication and Key Exchange
Certificate (only if the server requested)
Client_key_exchange
Certificate_verify ()
Phase 3: Client Authentication and Key Certificate

It is possible for the server to require that the client authenticate itself just as the server must. To do this, the server issues a Certificate_request, and the client replies with its Certificate and a Certificate_verify.
Phase 3: Client Authentication and Key Certificate
Phase 3: Client Authentication and Key Client_key_exchange
This message contains the PreMasterSecret encrypted with the server's public key that was in its certificate.
Phase 3: Client Authentication and Key Client_key_exchange (for RSA)
Phase 3: Client Authentication and Key Client_key_exchange (for RSA)
The PreMasterSecret is composed of the client's version and 46 cryptographically secure random bytes. Both sides use the PreMasterSecret along with the random bytes from the client and server hellos to generate the MasterSecret, which in turn is used to generate the various keys used by the encryption and digest algorithms. RSA is used for this key exchange. The details are slightly different for other methods such as Diffie-Helman.
Phase 3: Client Authentication and Key Certificate_verify
This message sent by the client helps the server to prove that the client has the private key associated with the clients certificate as sent in the Certificate message.

Message format not available yet!!
Client uses private key to sign previously sent messages. The server can then use clients public key to verify that client indeed has both the private and public key pair.
Phase 4: Finish
Client_Change_cipher_spec Server_Change_cipher_spec Client_Finished Server_Finished
Phase 4: Finish
Client_Change_cipher_spec and Server_Change_cipher_spec
This message is sent by both sides indicating that they will henceforth use the new cipher suite. The message is not a handshake message as such. It is rather one of the four record types (see slide #193).
Phase 4: Finish
Client_Finished and Server_Finished
This message is sent by both sides indicating that they are over with the handshake and begin to exchange the actual payload of the upper layer application. The Finished message is encrypted with the already agreed cipher suite (encryption algo + hash) as concluded in the previous ChangeCipherSpec message. The two HMACs (in the figure shown next slide) are computed over all the previous handshake messages, verifying that the unauthenticated messages were not tampered with.
Phase 4: Finish
Client_Finished and Server_Finished
Handshake Scenarios
Server Authentication Handshake

Basic SSL Flow
Resumed Session Handshake
Mutual Authentication Handshake
SSL Record Protocol

Confidentiality Data integrity
SSL Record Format
SSL Record-Layer Message Types
Record Type
CHANGE_CIPHER_SPEC ALERT HANDSHAKE
Value
Description
20 switch to the last negotiated cipher suite 21 error or CloseNotify messages 22 hello and other connection-initiation messages
APPLICATION_DATA
23 data messages
SSL Record Protocol

Five operations (in order)
Fragmentation: The message (either from server to client, or from client to server) is fragmented into blocks whose length does not exceed a certain limit (say16384 bytes. Compression (optional) Adding MAC: This step computes the MAC for the block and adds it to the (optionally) compressed message block. Encryption: The (optionally) compressed message and the MAC are encrypted using symmetric-key encryption. Append SSL Record Header: Finally, an SSL header is prepended to the encrypted block.
SSL Alert Protocol
This protocol is used to report errors (such as ) Unexpected message Bad record MAC Decompression failure Handshake failure (i.e. security parameters negotiation failed) Illegal parameters It is also used for other purposes (such as ) To notify closure of the connection (Close_Notify) To notify the absence of certificate (when requested) To notify that a bad or unknown certificate was received To notify that a certificate is revoked or has expired
Description CLOSE_NOTIFY UNEXPECTED_MESSAGE
Value 0 10
TLS
SSL 3
BAD_RECORD_MAC
DECRYPTION_FAILED RECORD_OVERFLOW DECOMPRESSION_FAILURE HANDSHAKE_FAILURE NO_CERTIFICATE BAD_CERTIFICATE UNSUPPORTED_CERTIFICATE CERTIFICATE_REVOKED
20
21 22 30 40 41 42 43 44
CERTIFICATE_EXPIRED
CERTIFICATE_UNKNOWN ILLEGAL_PARAMETER UNKNOWN_CA
45
46 47 48
Last Assignment: SSL secure application

Submission: December 31, 2099
Write a chat application that uses SSL for authentication (using certificates) and secure its communication (confidentiality, integrity and anti-replay) using the OpenSSL implementation of SSL.

CS687 - Network Security V5.5 - Spring 2013

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

CS687 - Network Security V5.5 - Spring 2013

Încărcat de

Drepturi de autor:

Formate disponibile

CS687 Information Systems Security

Network & Application Security

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

Approaches to Network Security

Preventive Security o Organizational: Defensive Security (Topic for next chapter)

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

The Role of Trust

HiLCoE School of Computer Science & Technology

Where shall security services be integrated?

HiLCoE School of Computer Science & Technology

Where shall security services be integrated ...

HiLCoE School of Computer Science & Technology

Trust and Security

HiLCoE School of Computer Science & Technology

Service User Service Provider Definition

HiLCoE School of Computer Science & Technology

Service User vs Service Provider Scenario 1

HiLCoE School of Computer Science & Technology

Service User vs Service Provider Scenario 2

HiLCoE School of Computer Science & Technology

When two SUs communicate using an SP:

Threats by the service users

Masquerade/Impersonation Sender repudiation Receiver repudiation

HiLCoE School of Computer Science & Technology

Threats within the service provider

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

Trust and Multi-layer security

Scenario 1: Enforcing all communication on an Ethernet LAN to be confidential.

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

Scenario 2: A branch of an organization connected to HQ.

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

Service Provider Internet

HiLCoE School of Computer Science & Technology

Router Protection Host Authentication R Service Provider Internet

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

Trust and Security FU

Trust and Security FU

Four Layers of Security

Application Layer Security (PGP, Ssh, etc)

HiLCoE School of Computer Science & Technology

Four Layers of Security Link Layer Security

Four Layers of Security

HiLCoE School of Computer Science & Technology

Four Layers of Security

Four Layers of Security

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

HiLCoE School of Computer Science & Technology

The requested QoS (FU) is served at this layer

HiLCoE School of Computer Science & Technology