Schaefer ICC2003 SecurityTutorial-2Up

8/3/2019 Schaefer ICC2003 SecurityTutorial-2Up

http://slidepdf.com/reader/full/schaefer-icc2003-securitytutorial-2up 1/36

ICC 2003, Network Security Tutorial, May 2003, Anchorage, Alaska 1 © Dr.-Ing G. Schäfer

Introduction to Network Security

! Threats & Countermeasuresin Communication Networks

! Network Security Protocols

Dr.-Ing. Günter Schäfer

Telecommunications Network GroupTechnische Universität Berlin, Germany


! Security Threats & Requirements

! Security Services & Mechanisms

! Fundamentals of Security Technology:

! Symmetric & Asymmetric Cryptography

! Detection of Message Modifications

! Cryptographic Protocols

! Integrating Security into Communications Architectures

Part I:

Threats & Countermeasuresin Communication Networks




What is a Threat in a Communication Network?

! Abstract Definition:

! A threat in a communication network is any possible event or sequence ofactions that might lead to a violation of one or more security goals

! The actual realization of a threat is called an attack

! Examples:! A hacker breaking into a corporate computer

! Disclosure of emails in transit

! Someone changing financial accounting data

! A hacker temporarily shutting down a website

! Someone using services or ordering goods in the name of others

! ...

! What are security goals?

! Security goals can be defined:

s

depending on the application environment, ors in a more general, technical way


Security Goals Technically Defined

! Confidentiality:

! Data transmitted or stored should only be revealed to an intended audience

! Confidentiality of entities is also referred to as anonymity

! Data Integrity:

! It should be possible to detect any modification of data

! This requires to be able to identify the creator of some data

! Accountability:

! It should be possible to identify the entity responsible for anycommunication event

! Availability:

! Services should be available and function correctly

! Controlled Access:

! Only authorized entities should be able to access certain services orinformation




Threats Technically Defined

! Masquerade:

! An entity claims to be another entity

! Eavesdropping:

! An entity reads information it is not intended to read

! Authorization Violation: ! An entity uses a service or resources it is not intended to use

! Loss or Modification of (transmitted) Information:

! Data is being altered or destroyed

! Denial of Communication Acts (Repudiation):

! An entity falsely denies its’ participation in a communication act

! Forgery of Information:

! An entity creates new information in the name of another entity

! Sabotage:

! Any action that aims to reduce the availability and / or correct functioningof services or systems


Threats and Technical Security Goals

These threats are often combined in order to perform an attack!

General Threats

TechnicalSecurity Goals

Masquer-ade

Eaves-dropping

Authori-sation

Violation

Loss or Mo-dification of(transmitted)information

Denial ofCommuni-cation acts

Forgeryof Infor-mation

Sabotage(e.g. by

overload)

Confidentiality x x x

Data Integrity x x x x

Accountability x x x x

Availability x x x xControlled

Accessx x x




Network Security Analysis

! In order to take appropriate countermeasures against threats, thesehave to be evaluated appropriately for a given network configuration.

! Therefore, a detailed network security analysis is needed that:

! evaluates the risk potential of the general threats to the entities using a

network, and! estimates the expenditure (resources, time, etc.) needed to perform known

attacks.

Attention: It is generally impossible to assess unknown attacks!

! A detailed security analysis of a given network configuration / specificprotocol architecture:

! might also be required in order to convince financially controlling entities inan enterprise to grant funding for security enhancements, and

! can better be structured according to the more fine grained attacks on the

message level.


Attacking Communications on the Message Level

! Passive attacks:

! Eavesdropping

! Active attacks:

! Delay of PDUs (Protocol Data Units)

! Replay of PDUs

! Deletion of PDUs

! Modification of PDUs

! Insertion of PDUs

! Successful launch of one of the above attacks requires:

! There are no detectable side effects to other communications(connections / connectionless transmissions)

! There are no side effects to other PDUs of the same connection / connectionless data transmission between the same entities

! A security analysis of a protocol architecture has to analysethese attacks according to the architecture’s layers




Communication in Layered Protocol Architectures

End-

system

End-

system

Network

Layer 5Layer 5

Layer 4Layer 4

Layer 3Layer 3

Layer 5Layer 5

Layer 4Layer 4

Layer 3Layer 3Layer 3Layer 3 Layer 3Layer 3

Application Layer

Transport Layer

Network Layer Network Layer

Layer 2Layer 2

Layer 1Layer 1

Layer 2Layer 2

Layer 1Layer 1

Layer 2Layer 2

Layer 1Layer 1

Layer 2Layer 2

Layer 1Layer 1

Data Link Layer

Physical Layer

Data Link Layer

Physical Layer


Security Analysis of Layered Protocol Architectures 1

Dimension 1: At which interface does the attack take place?

Endsystem

(Initiator)

Endsystem

(Responder)

Network

?? ?




Security Analysis of Layered Protocol Architectures 2

Layer 5Layer 5

Layer 4Layer 4

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Layer 5Layer 5

Layer 4Layer 4

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Application Layer

Transport Layer

Data Link Layer

Physical Layer

Network Layer

Data Link Layer

Physical Layer

Network Layer

?

?

?

?

?

Dimension 2: In which layer does the attack take place?


Communications Security: Some Terminology

! Security Service:

! An abstract service that seeks to ensure a specific security property

! A security service can be realised with the help of cryptographicalgorithms and protocols as well as with conventional means:

s One can keep an electronic document on a floppy disk confidential bystoring it on the disk in an encrypted format as well as locking awaythe disk in a safe

s Usually a combination of cryptographic and other means is mosteffective

! Cryptographic Algorithm:

! A mathematical transformation of input data (e.g. data, key) to output data

! Cryptographic algorithms are used in cryptographic protocols

! Cryptographic Protocol:

! A series of steps and message exchanges between multiple entities inorder to achieve a specific security objective




Important Properties of Encryption Algorithms

! Error propagation characterizes the effects of bit-errors duringtransmission of ciphertext to reconstructed plaintext P1´, P2´, ...

! Depending on the encryption algorithm there may be one or moreerroneous bits in the reconstructed plaintext per erroneous ciphertext bit

! Synchronization characterizes the effects of lost ciphertext data unitsto the reconstructed plaintext

! Some encryption algorithms can not recover from lost ciphertext and needtherefore explicit re-synchronization in case of lost messages

!

Other algorithms do automatically re-synchronize after 0 to n (n dependingon the algorithm) ciphertext bits

Consider, a sender is encrypting plaintext messages P1, P2, ... tociphertext messages C1, C2, ...

Then the following properties of the encryption algorithm are of specialinterest:


Classification of Encryption Algorithms: Three Dimensions

! The type of operations used for transforming plaintext to ciphertext:

! Substitution , which maps each element in the plaintext (bit, letter, group ofbits or letters) into another element

! Transposition, which re-arranges elements in the plaintext

! The number of keys used:

! Symmetric ciphers, which use the same key for en- / decryption

! Asymmetric ciphers, which use different keys for en- / decryption

! The way in which the plaintext is processed:

! Stream ciphers work on bit streams and encrypt one bit after another:s Many stream ciphers are based on the idea of linear feedback shift registers,

and there have been detected vulnerabilities of a lot of algorithms of this class,

as there exists a profound mathematical theory on this subject.

s Most stream ciphers do not propagate errors but are sensible to loss ofsynchronization.

! Block ciphers work on blocks of width b with b depending on the specificalgorithm.




Symmetric Encryption

General description:

! The same key K A,B is used for enciphering and deciphering ofmessages:

Notation:

! If P denotes the plaintext message E(K A,B , P) denotes the ciphertext and itholds D(K A,B , E(K A,B , P)) = P

! Alternatively we sometimes write {P} K A,B for E(K A,B , P)

Examples: RC4, DES, 3DES, IDEA, AES, ...

Plain-text

Encrypt

Cipher-text

Cipher-text

Decrypt

Plain-text


Detection of Message Modifications

! Motivation:

! An error detection code over a message enables the receiver to check if amessage was altered during transmission

s Examples: Parity, Bit-Interleaved Parity, Cyclic Redundancy Code (CRC)

! This leads to the wish of having a similar value called modification check value (MDC) that allows to check, if a message has been modified duringtransmission

s Attention: CRC is not suited for detection of malicious modifications!

! Realization of Modification Check Values:! Cryptographic Hash Functions:

s These are either combined with asymmetric cryptography to obtain asigned modification detection code (MDC) or already include a sharedsecret mixed with the message (e.g., MD5, SHA-1, RIPEMD-160)

! Message Authentication Codes:

s Common message authentication codes (MAC) are constructed from asymmetric block cipher (e.g. DES-CBC-MAC)




Cryptographic Protocols

Definition:

A cryptographic protocol is defined as a series of steps and messageexchanges between multiple entities in order to achieve a specificsecurity objective

Applications of cryptographic protocols:

! Key exchange

! Authentication

s Data origin authentication: the security service, that enables a receiverto verify by whom a message was created and that it has not beenmodified

s Entity authentication: the security service, that enables communicationpartners to verify the identity of their peer entities

! Combined authentication and key exchange


Integrating Security into Networks: What to do where?

! Analogous to the methodology of security analysis, there are two dimensions guiding the integration of security services intocommunications architectures:

Dimension 1:

Which security serviceshould be realized inwhich node?

Endsystem

(Initiator)

Endsystem

(Responder)

Network

? ? ? ??

Layer 5Layer 5

Layer 4Layer 4

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Layer 5Layer 5

Layer 4Layer 4

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Layer 3Layer 3

Layer 2Layer 2

Layer 1Layer 1

Application Layer

Transport Layer

Data Link Layer

Physical Layer

Network Layer

Data Link Layer

Physical Layer

Network Layer

?

?

?

?

?

Dimension 2:

Which security serviceshould be realized inwhich layer?




Application Level

End System Level

Subnetwork Level

A Pragmatic Model for Secured & Networked Computing

End-System 1

End-System 2

ApplicationA

ApplicationB

End System Comm.

ApplicationC

ApplicationB

End System Comm.

Subnetwork 1 Subnetwork 2

Inter-Network Link Level


Relationships Between Layers & Requirements Levels

! The relations between protocol layers and the protocol element securityrequirements levels are not one-to-one:

! Security mechanisms for fulfilling both the end system and the subnetworklevel requirements can be either realized in the transport and / or thenetwork layer

! Link level requirements can be met by integrating security mechanisms orusing “special functions” of the either the link layer and / or the physical layer

Application Layer

Transport Layer

Network Layer

Link Layer

Physical Layer

Application Level

End System LevelSubnetwork Level

Link Level

Protocol LayersSecurity ProtocolElements Level




General Considerations for Architectural Placement (1)

! Traffic mixing:

! As a result of multiplexing, there is greater tendencies at lower levels tohave data items from different source/destination-users and / orapplications mixed in one data stream

!

A security service realized at one layer / level will treat the traffic of thatlayer / level in an equal manner, resulting in inadequate control oversecurity mechanisms for users and applications

! If a security policy demands for a more differentiated treatment, it shouldbe better realized at a higher level

! Route knowledge:

! At lower levels, there tends to be more knowledge about the securitycharacteristics of different routes and links

! In environments, where such characteristics vary significantly, placingsecurity at lower levels can have effectiveness and efficiency benefits

! Appropriate security services can be selected on a subnetwork or linkbasis eliminating cost for security, where protection is unnecessary


General Considerations for Architectural Placement (2)

! Number of protection points:

! Placing security at the application level requires security to beimplemented in every sensitive application and every end system

! Placing security at the link level requires security to be implemented at theend of every network link which is considered to be less trusted

! Placing security in the middle of the architecture will tend to requiresecurity features to be installed at fewer points

! Protocol header protection:

! Security protection at higher levels can not protect protocol headers oflower protocol layers

! The networking infrastructure might need to be protected as well

! Source / sink binding:

! Security services like data origin authentication and non-repudiationdepend upon association of data with its source or sink

! This is most efficiently achieved at higher levels, especially the applicationlevel




Considerations Regarding Specific Levels (1)

! Application level:

! This level might be the only appropriate level, for example because:

s A security service is application specific, e.g. access control for anetworked file store

s A security service needs to traverse application gateways, e.g.integrity and / or confidentiality of electronic mail

s Semantics of data is important, e.g. for non-repudiation services

s It is beyond the reach of a user / application programmer to integratesecurity at a lower level

! End system level:

! This level is appropriate when end systems are assumed to be trusted andthe communication network is assumed to be untrusted

! Further advantages of end system level security:

s Security services are transparent to applications

s The management of security services can be more easily given in thehands of one system administrator


Considerations Regarding Specific Levels (2)

! Subnetwork level:

! Even if security implemented on this level might be implemented in thesame protocol layer like for the end system level, these should not bemixed up:

s With security implemented on the subnetwork level, usually the sameprotection is realized for all end systems of that subnetwork

! It is very common, that a subnetwork close to an end system is consideredequally trusted, as there are on the same premises and administered bythe same authorities

! In most situations there are far less subnetwork gateways to be securedthan there are end systems

! Link level:

! If there are relatively few untrusted links, it might be sufficient and as welleasier and cheaper to protect the network on the link level

! Furthermore the link level allows to make use of specific protectiontechniques, like spread spectrum or frequency hopping techniques

! Traffic flow confidentiality usually demands for link level protection




Integrating Security into Networks: Summary

! Integration of security services into communications architectures isguided by two main questions:

! Which security service into which node?

! Which security service into which layer?

! These design choices can also be guided by looking at a pragmaticmodel of networked computing which distinguishes four different levelson which security services may be realized:

! Application / end system / subnetwork / link level

! As there are various reasons for and against each option, there is nosingle solution to this design problem

! In this tutorial we, therefore, look at some examples of securityservices integration into network architectures in order to betterunderstand the implications of the design choices made:

! Link Layer Security Protocols / IPSec / Transport Layer Security Protocols


Additional References

[Amo94] E. G. Amorosi. Fundamentals of Computer Security Technology.

Prentice Hall. 1994.

[For94b] Warwick Ford. Computer Communications Security - Principles,Standard Protocols and Techniques. Prentice Hall. 1994.

[Gar96] Simson Garfinkel and Gene Spafford. Practical Internet & Unix Security.O'Reilly, 1996.

[KPS95] C. Kaufman, R. Perlman und M. Speciner. Network Security - Private Communication in a Public World. Prentice Hall. 1995.

[Men97a] A. J. Menezes, P. C. Van Oorschot, S. A. Vanstone. Handbook of Applied Cryptography. CRC Press Series on Discrete Mathematics and Its Applications,

Hardcover, 816 pages, CRC Press, 1997.[Sch96] B. Schneier. Applied Cryptography Second Edition: Protocols, Algorithms and

Source Code in C. John Wiley & Sons, 1996.

[Sta98a] W. Stallings. Cryptography and Network Security: Principles and Practice.

Hardcover, 569 pages, Prentice Hall, 2nd ed, 1998.




! Securing Data Transfer at Different Layers:

! Layer 2: Link Layer Security Protocols

s IEEE 802.1x

s PPP & PPTP

! Layer 3: IP Security Architecture (IPSec)

! Layer 4: Transport Layer Security Protocols

s Secure Socket Layer (SSL)

s Secure Shell (SSH)

!

Controlling Access:! Internet Firewalls

Part II:

Network Security Protocols


Layer 2: Scope of Link Layer Security Protocols

! According to the classical understanding of the OSI model, the linklayer provides an assured data transmission service between two peer entities that are directly inter-connected by a communications medium

! Its main tasks are:

! Error detection and correction

! Medium access control (MAC, not to be mixed up with messageauthentication code) for shared media, e.g. Ethernet, etc.

!

Not all of today’s networking technology fits nicely into that model:! Dial-up connections to an Internet service provider

! Virtual Private Network (VPN) solutions

! In this tutorial, we content ourselves with the following definition:

! The purpose of a link layer security protocol is to ensure specific securityproperties of link layer PDUs, that is the PDUs of the protocol layercarrying the PDUs of the network layer (e.g. IP)




IEEE 802.1x: Background & Goals

! The Institute of Electrical and Electronics Engineers (IEEE) 802 LAN/MAN Standards Committee develops local area networkstandards and metropolitan area network standards

! The most widely used standards are:

! Ethernet family (802.3, generally referred to as CSMA/CD),! Token Ring (802.5),

! Wireless LAN (802.11)

! The IEEE committee is currently working on a standard that:

! aims to “restrict access to the services offered by a LAN to those users and devices that are permitted to make use of those services”

! may be used with different IEEE 802.x technologies

! defines port based network access control to provide a means of“authenticating and authorizing devices attached to a LAN port that has point-to-point connection characteristics”

! is generally referred to as IEEE 802.1x


IEEE 802.1x: Controlled and Uncontrolled Ports

System

Controlled Port Uncontrolled Port

Point of

Attachment

LAN

! IEEE 802.1x introduces the notion of two logical ports:

! the uncontrolled port allows to authenticate a device

! the controlled port allows an authenticated device to access LANservices




IEEE 802.1x: Roles

! Three principal roles are distinguished:

! A device that wants to use the service offered by an IEEE 802.1x LANacts as a supplicant requesting access to the controlled port

! The point of attachment to the LAN infrastructure (e.g. a MAC bridge) acts

as the authenticator demanding the supplicant to authenticate itself! The authenticator does not check the credentials presented by the

supplicant itself, but passes them to his authentication server forverification

! Accessing a LAN with IEEE 802.1x security measures:

! Prior to successful authentication the supplicant can access theuncontrolled port:

s The port is uncontrolled in the sense, that it allows access prior toauthentication

s However, this port allows only restricted access

! Authentication can be initiated by the supplicant or the authenticator! After successful authentication the controlled port is opened


IEEE 802.1x: Security Protocols

! IEEE 802.1x does not define its own security protocols, but advocatesthe use of existing protocols:

! The Extensible Authentication Protocol (EAP) may realize basic deviceauthentication [RFC 2284]

! If negotiation of a session key during authentication is required, the use ofthe PPP EAP TLS Authentication Protocol is recommended [RFC 2716]

! Furthermore, the authentication server is recommended to be realized withthe Remote Authentication Dial In User Service (RADIUS)

[RFC 2865]




IEEE 802.1x: Security Message Exchange

! Exchange of EAP messages between supplicant and authenticator isrealized the with the EAP over LANs (EAPOL) protocol:

! EAPOL defines the encapsulation techniques that shall be used in order tocarry EAP packets between supplicant port access entities (PAE) and

Authenticator PAEs in a LAN environment! EAPOL frame formats have been defined for various members of the

802.x protocol family, e.g. EAPOL for Ethernet, ...

! Between supplicant and authenticator RADIUS messages may be used

! Besides initial entity authentication and access control no furthersecurity services are provided to LAN traffic!

! IEEE 802.11 still has to protect its traffic with WEP...


IEEE 802.1x: Example of an 802.1x Authentication

Supplicant PAE Authenticator PAE Authentication Server

EAP-Request/Identity

EAP-Response/Identity(MyID)

EAP-Request/OTP

OTP Challenge

EAP-Request/OTPOTP Passwd

EAP-Success

Port authorizedAuthenticationsuccessfully completed

EAPOL-Start

[source: IEEE Draft P802.1X/D11]




Point-to-Point Protocol: Purpose and Tasks

! Large parts of the Internet rely on point-to-point connections:

! Wide area network (WAN) connections between routers

! Dial-up connections of hosts using modems and telephone lines

! Protocols for this purpose:

!

Serial Line IP (SLIP): no error detection, supports only IP, no dynamicaddress assignment, no authentication [RFC 1055]

! Point-to-Point Protocol (PPP): successor to SLIP, supports IP, IPX, ...

! PPP [RFC 1661/1662]:

! Layer-2 frame format with frame delimitation and error detection

! Control protocol (Link Control Protocol, LCP) for connection establishment,

-test, -negotiation, and -release

! Separate Network Control Protocols (NCP) for supported Layer-3 protocols

Host Modem Modem Provider

PPP

Internet


Point-to-Point Protocol: Security Services

! The original version of PPP [RFC 1661] suggests the optional run ofan authentication protocol after the link establishment phase:

! If required, authentication is demanded by one peer entity via an LCPConfiguration-Request at the end of the link establishment phase

! Originally, two authentication protocols have been defined:

s Password Authentication Protocol (PAP)

s Challenge Handshake Authentication Protocol (CHAP)

! Meanwhile, an extensible protocol has been defined:

s Extensible Authentication Protocol (EAP)s PPP EAP Transport Level Security Protocol (PPP-EAP-TLS)

! Furthermore, encryption can be negotiated after authentication:

! Protocols:

s Encryption Control Protocol (ECP) for negotiation

s PPP DES Encryption Protocol (DESE)

s PPP Triple DES Encryption Protocol (3DESE)




Point to Point Tunneling Protocol (PPTP)

! PPP was originally designed to be run between “directly” connectedentities, that is entities which share a layer-2 connection

! Example: a PC and a dialup-router of an Internet service providerconnected over the telephone network using modems

! The basic idea of PPTP is to extend the protocol’s reach over theentire Internet by defining transport of PPP PDUs in IP packets

! Thus, the payload of PPTP PDUs are PPP packets (without layer-2specific fields like HDLC flags, bit insertion, control characters, CRC errorcheck values, etc.)

! PPP packets are encapsulated in GRE packets (generic routingencapsulation) that themselves are encapsulated in IP packets:

Media Header (e.g. Ethernet MAC header)

IP Header

GRE V.2 HeaderPPP Packet


PPTP: Voluntary Tunneling Protocol Layers

Internet

PPTP-Tunnel

Client Application ServerISP POP PPTP RAS

IP / IPX / NetBEUI packet flow

IP / IPX / NetBEUI

PPP

GRE Version 2

IP

Layer 2

Physical Layer

IP / IPX / NetBEUI

Layer 2 (e.g. 802.x)

Physical Layer

PPP

PPTP

IP / IPX / NetBEUI

PPP

GRE Version 2

IP

PPP

PPP Framing (HDLC)

Physical Layer




Layer 3: Security Objectives of IPSec

! IPSec aims to ensure the following security objectives:

! Data origin authentication / connectionless data integrity:

s It is not possible to send an IP datagram with neither a masqueradedIP source nor destination address without the receiver being able todetect this

s It is not possible to modify an IP datagram in transit, without thereceiver being able to detect the modification

s Replay protection: it is not possible to later replay a recorded IP packetwithout the receiver being able to detect this

! Confidentiality:

s It is not possible to eavesdrop on the content of IP datagrams

s Limited traffic flow confidentiality

! Security policy:

! Sender, receiver and intermediate nodes can determine the requiredprotection for an IP packet according to a local security policy

! Intermediate nodes and the receiver will drop IP packets that do not meetthese requirements


Overview of the IPSec Architecture

! A security association (SA) is a simplex “connection” that providessecurity services to the traffic carried by it

! Security services are provided to one SA by the use of either AH or ESP,but not both

! For bi-directional communication two security associations are needed

! An SA is uniquely identified by a triple consisting of a security parameter index (SPI), an IP destination address, and a security protocol identifier(AH / ESP)

! An SA can be set up between the following peers:

s Host↔ Host

s Host↔ Gateway (or vice versa)

s Gateway↔ Gateway

! There are two conceptual databases associated with SAs:

s The security policy database (SPD) specifies, what security servicesare to be provided to which IP packets and in what fashion

s The security association database (SADB)




IPSec’s Security Protocols

! The authentication header (AH):

! Provides data origin authentication and replay protection

! Is realized as a header which is inserted between the IP header and thedata to be protected

! The encapsulating security payload (ESP):

! Provides data origin authentication, confidentiality and replay protection

! Is realized with a header and a trailer encapsulating the data to beprotected

IPheader

AHheader

protecteddata

authenticated

IP

header

ESP

header

protected

data

ESP

trailer

authenticated

encrypted


The Authentication Header

! Immutable fields of the outer IP header are also authenticated

Security Parameter Index (SPI)

Sequence Number

Authentication Data

PayloadLength

0 23157 31

NextHeader

Reserved

IP Header

Payload

a u t h en t i c a

t e d

AH




The Encapsulating Security Payload

! The ESP header immediately follows an IP header or an AH header

! The next-header field of the preceding header indicates “50” for ESP

Security Parameter Index (SPI)

Sequence Number

Initialization Vector

Protected Data

Pad Pad Length Next Header

Authentication Data

0 23157 31

en c r y p t e d

a u

t h en t i c a t e d


IPSec Protocol Modes

! Protocol modes – An SA is always of one of the following types:

! Transport mode can only be used between end-points of a communication:

s host↔ host, or

s host↔ gateway, if the gateway is a communication end-point (e.g. fornetwork management)

! Tunnel mode can be used with arbitrary peers

! The difference between the two modes is, that:

! Transport mode just adds a security specific header (+ eventual trailer):

! Tunnel mode encapsulates IP packets:

Encapsulation of IP packets allows for a gateway protecting traffic on behalfof other entities (e.g. hosts of a subnetwork, etc.)

IPheader

IPSecheader

protecteddata

IP

header

IPSec

header

protected

data

IP

header




Nesting of Security Associations

! Security associations may be nested:

! Example: Host A and gateway RB perform data origin authentication andgateways RA and RB perform subnetwork-to-subnetwork confidentiality

Internet

SAA,RB

A BRA RB

IP packet flow

IPheader

IPSecheader

protecteddata

IPheader

Src = RADst = RB Src = ADst = RB

packet structure

SARA,RB

IPSecheader

IPheader

Src = ADst = B


Setup of Security Associations

! SA setup is realized with:

! Internet Security Association Key Management Protocol (ISAKMP):

s Defines generic framework for key authentication, key exchange andnegotiation of security association parameters [RFC2408]

s Does not define a specific authentication protocol, but specifies: – Packet formats

– Retransmission timers

– Message construction requirements

s Use of ISAKMP for IPSec is further detailed in [RFC2407]

! Internet Key Exchange (IKE):

s Defines an authentication and key exchange protocol [RFC2409]

s Is conformant to ISAKMP and may be used for different applications

s Setup of IPSec SAs between two entities is realized in two phases: – Establishment of an IKE SA (defines how to setup IPSec SAs)

– Setup of IPSec SAs




Further Issues with IPSec

! Compression:

! If encryption is used, then the resulting IP packets can not be compressedin the link layer, e.g. when connecting to an ISP via Modem

! Therefore, the IP payload compression protocol (PCP) has been defined

! PCP can be used with IPSec:

s IPSec policy definition allows to specify PCP

s IKE SA negotiation allows to include PCP in proposals

! Interoperability problems of end-to-end security with headerprocessing in intermediate nodes:

! Interoperability with firewalls:

s End-to-end encryption conflicts with the firewalls’ need to inspectupper layers protocol headers in IP packets

! Interoperability with network address translation (NAT):

s Encrypted packets do neither permit analysis nor change of addresses

s Authenticated packets will be discarded if source or destinationaddress is changed


Conclusion on IPSec

! IPSec is IETF’s security architecture for the Internet Protocol

! It provides the following security services to IP packets:

! Data origin authentication

! Replay protection

! Confidentiality

! It can be realized in end systems or intermediate systems:

! End system implementation: OS integrated or “bump in the stack”

! Gateway implementation: Router integrated or “bump in the wire”

! Two fundamental security protocols have been defined:

! Authentication header (AH)

! Encapsulating security payload (ESP)

! SA negotiation and key management is realized with:

! Internet security association key management protocol (ISAKMP)

! Internet key exchange (IKE)




SSL Security Services

! Peer entity authentication:

! Prior to any communications between a client and a server, anauthentication protocol is run to authenticate the peer entities

! Upon successful completion of the authentication dialogue an SSL session

is established between the peer entities! User data confidentiality:

! If negotiated upon session establishment, user data is encrypted

! Different encryption algorithms can be negotiated: RC4, DES, 3DES, IDEA

! User data integrity:

! A MAC based on a cryptographic hash function is appended to user data

! The MAC is computed with a negotiated secret in prefix-suffix mode

! Either MD5 or SHA can be negotiated for MAC computation


SSL Protocol Architecture

! SSL is structured as a layered and modular protocol architecture:

! Handshake: authentication and negotiation of parameters

!

Change Cipherspec.: signaling of transitions in ciphering strategy! Alert: signaling of error conditions

! Application Data: interface for transparent access to the record protocol

! Record:

s Fragmentation of user data into plaintext records of length < 214

s Compression (optional) of plaintext records

s Encryption and integrity protection (both optional)

SSL HandshakeProtocol

SSL ChangeCipherspec. Protocol

SSL ApplicationData Protocol

SSL AlertProtocol

SSL Record Protocol




SSL Record Protocol Processing

! Sending side:

! The record layer first fragments user data into records of a maximumlength of 214 octets, more than one message of the same content type canbe assembled into one record

! After fragmentation the record data is compressed, the default algorithm

for this is null (~ no compression), and it may not increase the recordlength by more than 210 octets

! A message authentication code is appended to the record data:

s MAC = H(MAC_write_secret + pad_2 +H(MAC_write_secret + pad_1 + seqnum + length + data))

s Note, that seqnum is not transmitted, as it is known implicitly and theunderlying TCP offers an assured service

! The record data and the MAC are encrypted using the encryptionalgorithm defined in the current cipherspec (may imply prior padding)

! Receiving side:

! The record is decrypted, integrity-checked, decompressed, de-fragmentedand delivered to the application or SSL higher layer protocol


SSL Handshake Protocol

! The SSL handshake protocol is used to establish peer authenticationand cryptographic parameters for an SSL session

! An SSL session can be negotiated to be resumable:

! Resuming and duplicating SSL sessions allows to re-use establishedsecurity context

! This is very important for securing HTTP traffic, as usually every item on aweb page is transferred an individual TCP connection

! When resuming / duplicating an existing session, an abbreviated

handshake is performed




The Secure Shell Protocol Version 2 (SSH)

! SSH was originally designed to provide a secure replacement for theUnix r-tools (rlogin, rsh, rcp, and rdist), thus it represents anapplication or session-layer protocol

! However, as SSH also includes a generic transport layer security

protocol and offers tunneling capabilities, it is discussed here as atransport layer security protocol

! SSH Architecture:

! SSH follows a client-server approach

! Every SSH server has at least one host key

! SSH version 2 offers two different trust models:

s Every client has a local database that associates each host name withthe corresponding public host key

s The hostname to public key association is certified by a CA and everyclient knows the public key of the CA

! The protocol allows full negotiation of encryption, integrity, key exchange,compression, and public key algorithms and formats


SSH Transport Protocol

! The SSH Transport Protocol runs on top of a reliable transport protocol(usually TCP)

! It provides the following services:

! Encryption of user data

! Data origin authentication (integrity)

! Server authentication (host authentication only)

! Compression of user data prior to encryption

! Supported algorithms:

! Encryption:s 3DES, Blowfish, Twofish, AES, Serpent, IDEA, CAST in CBC

s Arcfour (“believed” to be compatible with the “unpublished” RC4)

s none (not recommended)

! Integrity: HMAC with MD5 or SHA-1, none (not recommended)

! Key exchange: Diffie-Hellman with SHA-1 and one pre-defined group

! Public key: RSA, DSS

! Compression: none, zlib (see RFCs 1950, 1951)




SSH Authentication Protocol

! The SSH authentication protocol serves to verify the client’s identityand it is intended to be run over the SSH transport protocol

! The protocol per default supports the following authentication methods:

! Public key: the user generates and sends a signature with a per user public

key to the serverClient → Server: E(-K User , (session_id, 50, Name User , Service, “publickey”,

True, PublicKeyAlgorithmName, +K User ))

! Password: transmission of a per user password in the encrypted SSHsession (the password is presented in clear to the server but transmittedwith SSH transport protocol encryption)

! Host-based: analogous to public key but with with per host public key

! None: used to query the server for supported methods and if noauthentication is required (server directly responds with success message)

! If the client’s authentication message is successfully checked, the

server responds with a ssh_msg_userauth_success message


SSH Connection Protocol

! The SSH connection protocol runs on top of the SSH transportprotocol and provides the following services:

! Interactive login sessions

! Remote execution of commands

! Forwarded TCP/IP connections

! Forwarded X11 connections

! For each of the above services one or more “channels” areestablished, and all channels are multiplexed into a single encrypted

and integrity protected SSH transport protocol connection:! Either side may request to open a channel and channels are identified by

numbers at the sender and receiver

! Channels are typed, e.g. “session”, “x11”, “forwarded-tcpip”,“direct-tcpip” ...

! Channels are flow-controlled by a window mechanism and no data may besent via a channel before “window space” is available




Conclusions on Transport Layer Security Protocols

! Both SSL and SSH are suited to secure Internet communications in(above) the transport layer:

! Both security protocols operate upon and require a reliable transportservice, e.g. TCP

! Up to now, no major security protocol has been proposed to protectdatagram-oriented transport protocols like UDP

! Even though SSH operates in / above the transport layer the serverauthentication is host-based and not application-based

! Transport layer security protocols offer true end-to-end protection for userdata exchanged between application processes

! Furthermore, they may interwork with packet filtering of today’s firewalls(see below for more details on this)

! But, protocol header fields of lower layer protocols can not be protectedthis way, so they offer no countermeasures to threats to the networkinfrastructure itself


Introduction to Internet Firewalls

! In building construction, a firewall is designed to keep a fire fromspreading from one part of the building to another

! A network firewall, however, can be better compared to a moat of amedieval castle:

! It restricts people to entering at one carefully controlled point

! It prevents attackers from getting close to other defenses

! It restricts people to leaving at one carefully controlled point

! Usually, a network firewall is installed at a point where the protected

subnetwork is connected to a less trusted network:! Example: Connection of a corporate local area network to the Internet

! So, basically firewalls realize access control on the subnetwork level

FirewallInternet




Firewall Terminology & Building Blocks for Firewalls (1)

! Firewall:

! A component or a set of components that restricts access between aprotected network and the Internet or between other sets of networks

! Packet Filtering:

!

The action a device takes to selectively control the flow of data to and froma network

! Packet filtering is an important technique to implement access control onthe subnetwork-level for packet oriented networks, e.g. the Internet

! A synonym for packet filtering is screening

! Bastion Host:

! A computer that must be highly secured because it is more vulnerable toattacks than other hosts on a subnetwork

! A bastion host in a firewall is usually the main point of contact for userprocesses of hosts of internal networks with processes of external hosts

! Dual homed host: ! A general purpose computer with at least two network interfaces


Firewall Terminology & Building Blocks for Firewalls (2)

! Proxy:

! A program that deals with external servers on behalf of internal clients

! Proxies relay approved client requests to real servers and also relay theservers answers back to the clients

! If a proxy interprets and understands the commands of an applicationprotocol it is called an application level proxy, if it just passes the PDUsbetween the client and the server it is called a circuit level proxy

! Network Address Translation (NAT):

! A procedure by which a router changes data in packets to modify thenetwork addresses

! This allows to conceal the internal network addresses (even though NATis not actually a security technique)

! Perimeter Network:

! A subnetwork added between an external and an internal network, in orderto provide an additional layer of security

! A synonym for perimeter network is de-militarized zone (DMZ)




Firewall Architectures (1)

! The most simple architecture just consists of a packet filtering router

! It can be either realized with:

! A standard workstation (e.g. Linux PC) with at least two network interfaces

plus routing and filtering software! A dedicated router device, which usually also offers filtering capabilities

Firewall

InternetPacket Filtering

Router

The Simple Packet Filter Architecture

Denied Traffic Permitted Traffic



! The packet filter:

! Allows permitted IP traffic to flow between the screened host and the Internet

! Blocks all direct traffic between other internal hosts and the Internet

! The screened host provides proxy services:

! Despite partial protection by the packet filter the screened host acts as abastion host

The Screened Host Architecture

Firewall

Internet

Bastion Host





! A perimeter network is created between two packet filters

! The inner packet filter serves for additional protection in case the bastionhost is ever compromised:

! For example, this avoids a compromised bastion host to sniff on internal traffic

! The perimeter network is also a good place to host a publicly accessibleinformation server, e.g. a www-server

The Screened Subnet Architecture

Firewall

Internet

Bastion Host


Packet Filtering

! What can be done with packet filtering?

! Theoretically speaking everything, as all information exchanged in acommunication relation is transported via packets

! In practice, however, the following observations serve as a guide:

s Operations that require quite detailed knowledge of higher layerprotocols or prolonged tracking of past events are easier to realize inproxy systems

s Operations that are simple but need to be done fast and on individualpackets are easier to do in packet filtering systems

! Basic packet filtering enables to control data transfer based on:

! Source IP Address

! Destination IP Address

! Transport protocol

! Source and destination application port

! Eventually, specific protocol flags (e.g. TCP’s ACK- and SYN-flag)

! The network interface a packet has been received on




An Example Packet Filtering Ruleset

! This ruleset specifies, that incoming and outgoing email is the onlyallowed traffic into and out of a protected network:

! Email is relayed between two servers by transferring it to an SMTP-daemon on the target server (server port 25, client port > 1023)

! Rule A allows incoming email to flow to the bastion host and rule B allowsthe bastion hosts acknowledgements to exit the network

! Rules C and D are analogous for outgoing email! Rule E denies all other traffic

Rule Direction Src. Addr. Dest. Addr. Protocol Src. Port Dest. Port ACK Action

A Inbound External Bastion TCP >1023 25 Any Permit

B Outbound Bastion External TCP 25 >1023 Yes Permit

C Outbound Bastion External TCP >1023 25 Any Permit

D Inbound External Bastion TCP 25 >1023 Yes Permit

E Either Any Any Any Any Any Any Deny


Additional References (1)

[IEEE01a] IEEE. Standards for Local and Metropolitan Area Networks: Standard for Port

Based Network Access Control. IEEE Draft P802.1X/D11, 2001.

[RFC1661] W. Simpson. The Point-to-Point Protocol (PPP). RFC 1661, 1994.

[RFC1968] G. Meyer. The PPP Encryption Control Protocol (ECP). RFC 1968, 1996.

[RFC1994] W. Simpson. PPP Challenge Handshake Authentication Protocol (CHAP). RFC1994 (obsoletes RFC 1334), 1996.

[RFC2284] L. Blunk, J. Vollbrecht. PPP Extensible Authentication Protocol (EAP).RFC 2284, 1998.

[RFC2419] K. Sklower, G. Meyer. The PPP DES Encryption Protocol, Version 2 (DESE-

bis). RFC 2419 (obsoletes RFC 1969), 1998.

[RFC2420] H. Kummert. The PPP Triple-DES Encryption Protocol (3DESE).

RFC 2420, 1998.

[RFC2637] K. Hamzeh, G. Pall , W. Verthein, J. Taarud, W. Little, G. Zorn. Point-to-Point Tunneling Protocol (PPTP). RFC 2637, 1999.

[RFC2661] W. Townsley, A. Valencia, A. Rubens, G. Pall, G. Zorn, B. Palter. Layer Two Tunneling Protocol (L2TP). RFC 2661, 1999.

[FH98a] P. Ferguson, G. Huston. What is a VPN? The Internet Protocol Journal, volume

1, no. 1&2, Cisco Systems. 1998.





[RFC2401] R. Atkinson, S. Kent. Security Architecture for the Internet Protocol.

RFC 2401, Internet Engineering Taskforce (IETF), 1998.

[RFC2402] R. Atkinson, S. Kent. IP Authentication Header (AH). RFC 2402, IETF, 1998.

[RFC2403] C. Madson, R. Glenn. The Use of HMAC-MD5-96 within ESP and AH.

RFC 2403, IETF, 1998.

[RFC2404] C. Madson, R. Glenn. The Use of HMAC-SHA-1-96 within ESP and AH.

RFC 2404, IETF, 1998.

[RFC2405] C. Madson, N. Doraswami. The ESP DES-CBC Cipher Algorithm With Explicit IV. RFC 2405, IETF, 1998.

[RFC2406] R. Atkinson, S. Kent. IP Encapsulating Security Payload (ESP).RFC 2406, IETF, 1998.

[RFC2407] D. Piper. The Internet IP Security Domain of Interpretation for ISAKMP.

RFC 2407, IETF, 1998.

[RFC2408] D. Maughan, M. Schertler, M. Schneider, J. Turner.Internet Security Association and Key Management Protocol (ISAKMP).

RFC 2408, IETF, 1998.

[RFC2409] D. Harkins, D. Carrel. The Internet Key Exchange (IKE).

RFC 2409, IETF, 1998.[RFC2857] A. Keromytis, N. Provos. The Use of HMAC-RIPEMD-160-96 within ESP and

AH. RFC 2857, IETF, 2000.


[FKK96a] A. O. Freier, P. Karlton, P. C. Kocher. The SSL Protocol Version 3.0. NetscapeCommunications Corporation, 1996.

[RFC2246] T. Dierks, C. Allen. The TLS Protocol Version 1.0. RFC 2246, 1999.

[YKS01a] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Protocol Architecture. Internet Draft (work in progress), draft-ietf-secsh-architecture-

09.txt, 2001.

[YKS01b] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Transport Layer Protocol. Internet Draft (work in progress), draft-ietf-secsh-transport-09.txt, 2001.

[YKS01c] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Authentication

Protocol. Internet Draft (work in progress), draft-ietf-secsh-userauth-11.txt, 2001.

[YKS01d] T. Ylonen, T. Kivinen, M. Saarinen, T. Rinne, S. Lehtinen. SSH Connection Protocol. Internet Draft (work in progress), draft-ietf-secsh-connect-11.txt, 2001.

[Zwi00a] E. Zwicky, S. Cooper, B. Chapman. Building Internet Firewalls. Second Edition,

O’Reilly, 2000.

[Sem96a] C. Semeria. Internet Firewalls and Security. 3Com Technical Paper, 1996.

[Wack95a] J. P. Wack, L.J. Carnahan. Keeping Your Site Comfortably Secure: An

Schaefer ICC2003 SecurityTutorial-2Up

Documents

Transcript of Schaefer ICC2003 SecurityTutorial-2Up