Network Security Network Security Protocol 1 Network Security Chapter 3. Security and Layered Architecture.

Network Security Network Security Protocol 1

Network Security

Chapter 3. Security and Layered Architecture


Security at Layer 1

Security at Layer 2–Extensible Authentication Protocol(EAP)

–EAPoL : EAP Over LAN

–EAP-TLS : TLS Handshake Over EAP

Security at Layer 3 : IPSec

Security at Layer 4 : SSL/TLS

Objectives


Physical transmission of the bits over the medium.

Provide certain amount of security.

Direct Sequence Spread Spectrum(DSSS)

Frequency Hopping Spread Spectrum(FHSS)

Security provided by these protocols stems from keeping the codes(chip sequence or frequency hopping sequence) secret.

The codes are not cryptographically protected

are usually well known or easy to figure out.

Keep out of the most casual of eavesdroppers.

Security at Layer 1


HFSS system


DSSS (CDMA Example)


Extensible Authentication Protocol (EAP)

Point-to-Point Protocol(PPP) – used for connecting to the internet over phone line using modem.

< Authentication Model for Dial-In Internet Access>

-Three entities : - Supplicant (user)

- Authenticator (Point-of-Presence) – decision implementer

- Authentication Server ( authenticating the user) – decision maker

Security at layer 2


PPP connection procedure

PPP connection procedure

PPP client PPP Server(ex: Switch)

(1) LCP : PPP connection option negotiation

(2) Authentication Procedure

(3) IP address Allocation

(4) IP packet exchange using PPP Frame

Authentication Server

DHCP Server


Two Authentication protocol for PPP– PAP(password Authentication Protocol)

–CHAP(challenge handshaking Authentication Protocol)

PPP

Username : johnPassword : urbiz

Local userDatabaseInputs Name

andPassword when

Prompted

Run PPP

Use PAP

John, urbiz

Accept or Reject

Username : johnPassword : urbiz

Local userDatabase

Name : johnPassword :

urbiz

Run PPP

Use CHAP

Response

Accept or Reject

Use Challenge

User NAS

PAP

CHAP


PAP : username and password is transmitted in plain text

CHAP : challenge-response-based mechanism

Cheating CHAP (refer to handout)

When new protocol is developed, it should be registered to IANA(Internet Assigned Numbers Authority).

Also NAS should update software module to identity the new authentication protocol.

Idea :– EAP header : identify various authentication method

– NAS do not process Authentication, instead relay EAP message to authentication server.

– Authentication is processed between user and Authentication server

– EAP-MD5, EAP-TSL is well known.

EAP(Extensible Authentication Protocol)


Problem of authentication in PPP


Advantage :

– Allows Arbitrary authentication protocol between

supplicants and the authentication server.

– just act as pass through agent for back-end

authentication server.

– Separation of authenticator and authentication

server allows for higher flexibility and simple, low-

cost authenticators.

Disadvantage

– No mechanism to tie the two authentications

together as part of a session.

– Do not provide protection against a forged “EAP-

success”

– does not provide any mechanism to link the

authentication procedure to the following session.

The EAP Architecture


802.1X : definition - “mechanism for port-based network access control that make use of the physical access characteristics of IEEE 802 LAN ….”

EAPoL : EAP over LAN


Authentication category : – establish security context such as session key : TLS and so on.

– dose not establish security context : MD5, SHA and so on.

EAP-TLS – RFC 2716: www.faqs.org/rfc/rfc2409.html

– TLS(Transport Layer Security) sits over EAP.

– Use DH protocol to establish a premaster key.

– for more real authentication case, see the documents.

EAP-TLS: TLS Handshake Over EAP


L3 : responsible for providing end-to-end connectivity

IPSec (Internet Protocol Security)

– general IP Security mechanisms

– provides•authentication

•confidentiality

•key management

– applicable to use over LANs, across public & private WANs, & for the Internet

Security at Layer 3 (IP network Layer)


IPSec Uses


Access control

Integrity

Data origin authentication

Rejection of replayed packets

Confidentiality (encryption)

Limited traffic flow confidentiality - padding

IPSec Services


specification is quite complex

defined in numerous RFC’s–RFC 2401 - 2412 (1998)

–RFC 4301 – 4309 (2005)

mandatory in IPv6, optional in IPv4

have two security header extensions:–Authentication Header (AH)

–Encapsulating Security Payload (ESP)

IP Security Architecture


IKE(Internet Key Exchange Protocol) Protocol–responsible for authentication and session key establishment between the two communicating parties.

– RFC 2409 : IKEv1, RFC 4306 : IKEv2

AH(Authentication Header), ESP(Encapsulation Security Payload)

– IP Header extensions are used for confidentiality, integrity, and authentication.

– AH standard - 2402(1998), 4302(2005)

– ESP standard – 2406(1998), 4303(2005)

IPSec overview


Specifies completely all the cryptographic information required in one direction of communication

defined by 3 parameters:–Security Parameters Index (SPI)

–IP Destination Address

–Security Protocol Identifier(AH or ESP)

other parameters– Seq no, anti-reply window, lifetime of SA, IPSec mode

– AH info : algorithm, Key, key lifetime

– ESP info: encryption : algorithm, key, key lifetime authentication : algorithm, key, key lifetime

Security Associations


Sequence number starts at 1 and cannot go past 232-1

receiver keeps a window of min size 32 (64 preferred, larger is ok)

–packets to left of window are discarded

–repeated packets within window are discarded

–authentic packets to right of window cause window to move right

Anti-Reply Mechanism


provides message content confidentiality & limited traffic flow confidentiality

can optionally provide the same authentication services as AH

supports range of ciphers, modes, padding–incl. DES, Triple-DES, RC5, IDEA, CAST etc

–CBC & other modes

–padding needed to fill block size, fields, for traffic flow confidentiality

Encapsulated Security Payload (ESP)


IPSec Encapsulating Security Payload (ESP) in Transport Mode


IPSec ESP Tunnel Mode


Encryption and MAC algorithm for ESP


Authentication is applied to the entire packet, with the mutable fields(change hop-by-hop) in the IP header zeroed out

Data origin authentication, data integrity, reply prevention

If both ESP and AH are applied to a packet, AH follows ESP

Authentication Header (AH)


IPSec Authentication Header (AH)in Transport Mode


IPSec AH Tunnel Mode


MAC Algorithms for AH


Combining Security Associations


A mature, complex protocol for securely setting up keyed sessions, in particular IP-Sec SA.

Evolved over several years from multiple proposals; IKEv2 is now ‘draft standard` (http://tools.ietf.org/html/rfc4306)

Runs over UDP (port 500; detect NAT: 4500)

One IKE message per UDP datagram

Uses (only) exchanges (request/response)–Initiator (Alice) makes request, Responder (Bob) responses

–Initiator (only) retransmits/aborts for reliability

–Not necessarily client/server! But usually Alice is client.

Introduction to IKE


Cryptographic negotiation– Efficient, secure, robust, flexible

Robustness against Denial Of Service

NAT/NAPT-friendly

Strong (Perfect) Forward Secrecy (PFS)– What’s this?

IKE advanced features(design goals)-IKEv2


Protect traffic of period i from exposure of all keys of all periods j≠i, as long as exposure happens after (refresh phase of) period i+1

Active adversary - can always inject/eavesdrop etc.

Motivation: attacker may eventually expose some old keys, by cryptanalysis, reading erased data,…

Strong (Perfect) Forward Security(PFS)


Phase I : Establish a secure channel

–ISAKMP(Internet Security Association and Key Management Protocol) SA.

–Authenticate computer identity–Algorithms, keys, etc. – to be used by IKE (not AH/ESP!)

–Perfect forward secrecy (PFS)

Phase II : Generate IP-Sec SA–Establishes a secure channel between computers intended for the transmission of data.

–Protected using the ISAKMP SA

–Many 2nd phases may share ISAKMP SA (1st phase)

–PFS optional

Internet Key Exchange (IKE) ver. 1


Why not establish and use one `master key`?

Ensure reliable, secure separation of sessions–In particular prevent IP spoofing in ESP/Transport

Restrict use of a single key– Make cryptoanalysis harder

• Less available ciphertext

•Some sessions may be easier to attack

(chosen/known plaintext)

Restrict damage of known key attack: session key exposure does not expose past or future messages, session keys, or master key

Strong (Perfect) Forward Secrecy (PFS)

Why derive many session keys?


To fulfill the PFS requirement, every phase I exchange, performs a DH exchange

In phase II, DH execution is optional – phase II and the IPsec keys can be derived from phase I exchange

– Phase II is more efficient

– Many phase II exchanges can use the same set of phase I keys

Why derive different keys and not?

Why Two IKE Phases?


IKE DOS Attack: flood victim with IKE requests (fake source IP addr) victim performs expensive computations in vain

Solution : before performing expensive computations (e.g. DH), verify that the other party is indeed located in the IP address that appears in the header

How ? Cookies mechanism… (next)

Note: requires the `main mode` of IKEv1 (6 flows, cf. to `aggressive mode of 3 flows), also optional exchange in IKEv2.

IKE Denial Of Service Attacks


The recipient sends a pseudo random string (Cookie) to the other party

The other party return the cookie, proving it can receive from its IP address

Compute cookie – Cookie = <VersionIDofSecret> | Hash(Ni | IPi | SPIi | <secret>)

– <secret> : a randomly generated secret known only to the responder and periodically changed

– <VersionIDofSecret> : should be changed whenever <secret> is regenerated.

Efficient generation, memory less verification

Expensive calculations will be performed, and state kept, only if valid cookie is received

The Cookies Mechanism


IKEv2 Exchanges


Negotiate crypto-suites

Exchange gi, gr (Diffie-Hellman public values)

Exchange nonces

Identities (and certificates) not exposed yet!

IKEv2 : IKE_SA_Init exchange


Key Derivation in IKE


Authenticate IKE_SA_Init exchange Exchange identities and certificates (encrypted for privacy

– but client identity has weaker protection) Exchange traffic selectors Establish 1st child SA Encrypted and authenticated (MAC) using SK { } Like in ESP: encrypt then MAC; use keys SK_[a/e][i/r].

IKEv2: IKE_Auth exchange


IKE generates keying material using an ephemeral Diffie-Hellman exchange in order to gain the property of "perfect forward secrecy". This means that once a connection is closed and its corresponding keys are forgotten, even someone who has recorded all of the data from the connection and gets access to all of the long-term keys of the two endpoints cannot reconstruct the keys used to protect the conversation without doing a brute force search of the session key space.

Achieving perfect forward secrecy requires that when a connection is closed, each endpoint MUST forget not only the keys used by the connection but also any information that could be used to recompute those keys. In particular, it MUST forget the secrets used in the Diffie-Hellman calculation and any state that may persist in the state of a pseudo-random number generator that could be used to recompute the Diffie-Hellman secrets. Since the computing of Diffie-Hellman exponentials is computationally expensive, an endpoint may find it advantageous to reuse those exponentials for multiple connection setups. There are several reasonable strategies for doing this. An endpoint could choose a new exponential only periodically though this could result in less-than- perfect forward secrecy if some connection lasts for less than the lifetime of the exponential. Or it could keep track of which exponential was used for each connection and delete the information associated with the exponential only when some corresponding connection was closed. This would allow the exponential to be reused without losing perfect forward secrecy at the cost of maintaining more state.

Decisions as to whether and when to reuse Diffie-Hellman exponentials is a private decision in the sense that it will not affect interoperability. An implementation that reuses exponentials MAY choose to remember the exponential used by the other endpoint on past exchanges and if one is reused to avoid the second half of the calculation.

Reuse of Diffie-Hellman Exponentials


Secure Socket Layer(SSL)/Transport layer Security(TLS): incompatible but similar.

–A protocol developed by Netscape for transmitting private documents via the Internet.

–Sits between application layer and transport layer, so applications use SSL sockets.

–Authenticate the communicating party and establish a session key.

–By convention, URLs that require an SSL connection start with https: instead of http:

Security at Layer 4 : SSL/TLS


TLS Message flow


When Key Exchange Message is sent?


TLS Hand shaking

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random)

Encrypted with master secret Signed hash


Session-Id used in TLS:

Become valid only when shaking is completed and persists until it is removed due to aging or session error.

The whole session messages are protected(signed hash) by the Finished message.

Can not be spoofed by a malicious Eve.

SSL/TLS Security


SSL runs on top of TCP.

TCP checks transmission error; not protected cryptographically.

SSL does not have API to tell vague packet to TCP

Scenario1. Insert malicious data packet into a packet stream which is

protected by SSL.

2. SSL drops the packet;

3. When real packet arrive, TCP will drop the packet since duplicate packet.

4. SSL is missing a packet it is expecting.

5. SSL close the connection after timeout. DoS attack!

SSL – DoS attack loop hole


EAP-TLS deployment CISCO documents.

IPSec PPTs - Stalling Book(Chapt 16)

A Cryptographic tour of the IPSec Standards – K.G. Paterson

Alcatel IPSec White Paper(IKEv1)

New efficient, DoS Resistant IKE(paper, 2002)

Resources

Network Security Network Security Protocol 1 Network Security Chapter 3. Security and Layered Architecture.

Documents

Network Security Network Security Protocol 1 Network Security Chapter 3. Security and Layered Architecture.