Participant Access Control in IP Multicasting. Project Highlights 16/06/2008Participant Access Control in IP Multicasting2 Data Distribution Control Data

Participant Access Control in IP Multicasting

Salekul Islam Supervisor: Dr. J. William Atwood

Computer Science and Software EngineeringConcordia University

PhD Thesis Defence

Participant Access Control in IP Multicasting 2

Project Highlights

16/06/2008

Data Distribution Control

Policy Framework

Inter-domain Access Control Architecture

DiameterAgents

MulticastSA

Mobile Multicast: Receiver Access Control & Secured Handoff

Sender Access Control PANA, IKEv2 and IPsec SA

Receiver Access Control IGMP with Access Control (IGMP-AC)Verification by PROMELA/SPINValidation by AVISPA Access Control Architecture

Access Control: Authentication, Authorization &

Accounting

Participant:Receivers & Sender(s)


Existing Multicast Service Model

16/06/2008

AR1

AR2

AR3CR3

Sender

ReceiversEUs

Routing ProtocolBuilds DDT

IGMP MessagesEUs Join/Leave

Sends multicast data

Data forwardingusing DDT

CR1

CR2

CR3

DDT: Data Distribution Tree


Existing Multicast Service Model : Vulnerabilities

16/06/2008

AR1

AR2

AR3CR3

Sender

ReceiversEUs

CR1

CR2

CR3

AR4

AR1

IGMP Join

Routing Protocol Join

AdversaryReceiver

Forged data

AdversarySender


Multicast-based Applications

16/06/2008

Number of Participants

Applications

One-to-many(single sender

multiple receivers)

• Scheduled audio/video distribution• Push media: news headlines, weather updates• File distribution and caching• Announcements: multicast session, key updates• Monitoring: stock prices, sensor equipment

Many-to-many (multiple senders multiple receivers)

• Multimedia conferencing• Synchronized resources• Distance learning with input from receivers• Multi-player games

Many-to-one (multiple senders single receivers)

• Resource discovery• Auctions• Polling


Motivation: Revenue Generation Architecture Secure Multicasting

Protecting control messages—routing protocol specific Protecting multicast data—encryption and authentication

Securing multicasting only fails to happen in large scale commercial deployment

A revenue generation architecture considers Participant access control—AAA for sender(s) and

receivers Policy enforcement E-commerce communications

16/06/2008


Why Access Control?

Effects of forged IGMP messages Join message pulls distribution tree, may create DoS Leave message prunes distribution tree, prevents

legitimate users from receiving IGMP security—only authenticates IGMP messages

Attacks by a forged sender Replay attack Sender address spoofing attack May create DoS

GKM fails to prevent these attacks

16/06/2008


How to deploy access control?

Receiver access control for a secured group While joining/leaving Changing reception state at ARs

Sender access control for a secured group Sending data

16/06/2008

Coupling access control with IGMP

Per-packet cryptographic protection at AR


Sender Access Control

• AAA for sender(s)• Per-packet

protection


• Protects distribution tree from

forged sender • Not routing protocol security

Receiver Access Control

• AAA for receivers/EUs

Overview of Our Access Control Architecture

16/06/2008

AR1

AR2

AR3CR3

CR1

CR2

Sender

ReceiversEUs


Access Control and Authentication in Unicast Access Control is achieved by AAA framework

RADIUS—with limited functionalities Diameter—next generation AAA protocol

• Extensible• Large AVP• Agent support

For authentication IETF has designed Extensible Authentication Protocol (EAP) Protocol for carrying Authentication for Network

Access (PANA)—EAP lower layer

16/06/2008


Authentication, Authorization and Accounting (AAA) Framework

16/06/2008

AAA protocol

AAA ServerAuthentication

Authorization

AccountingNASAAA Client

End User

Network

End UserDatabase

Requesting access to network

EU credentials

Accept

Access is granted

NAS: Network Access Server


Extensible Authentication Protocol (EAP)

16/06/2008

EAP Request1

EAP Response1

EAP Request2

EAP ResponseNDiameter (EAP ResponseN)

Diameter (EAP Success)EAP Success

NAS/ EAP Authenticator

AAA Server EAP Server

EAP Diameter (EAP)

End UserEAP Peer

EAP summary

- Authentication framework

- Multiple authentication

- EAP methods

- Four EAP messages

Request, Response

Success, Failure

(Initiate EAP)

By peer or authenticator

Authenticator to peer

Peer to authenticator

Diameter (EAP Response1)

Diameter (EAP Request2)

Encapsulatedover Diameter


Protocol for carrying Authentication for Network Access (PANA)

16/06/2008

PaC PAA AS

EP SNMP/API

PANA RADIUS/Diameter

IKE

PaC : PANA Client AS : Authentication ServerEP : Enforcement Point PAA : PANA Authentication Agent

PANA summary

- Network access protocol

- Works as EAP lower layer

- Four entities: PaC, PAA, AS, EP


Key Challenges for Access Control Architecture The most generic architecture

Deployable for multi-domain distributed groups Supports wide range of authentication Independent of routing protocol Supports both ASM and SSM

A scalable solution Minimum workload for on-tree routers and end hosts A distributed solution (e.g., using AAA)

Reuse standard frameworks/protocols Fits easily in the existing Internet service model Will reduce the work of service providers

16/06/2008


Out of the scope of the thesis

NAS

NAS

Proposed Architecture

16/06/2008

AR1

AR2

AR3CR3

CR1

CR2

Sender

EUs

AAAS

Participants Database &

Policy Server

Updates Registration

GO/MRFI

Diameter

IGMP Carrying EU auth. info


Receiver Access Control: Related Work

16/06/2008

Method IGMP version

Authentication

Authorization

Accounting Remarks

EUIAIGMPv3 Flexible Yes Yes Initial work at HSPL, Concordia.

Does not support EAP-like framework

IGAPIGMPv2 Passwd

CHAPYes Yes Plain text password

Extends IGMPv3

IGMPv3 No specific

No No Not suitable for multiple round-trip- based authentication

IGMPv3 access control

IGMPv3 Using IP address

Source filtering

No Address spoofing attack, no advanced authentication scheme

RADIUS based

IGMPv2 CHAP No No Sender access control also, replay attack.

IGMP key based

IGMPv2 Token di-gital sign

No No Needs GKM protocol, high overhead.

Shared secret

IGMPv3 No No No AR needs shared secret to authenticate, overload for AR.

Based on IGMPv2

Specific authentication

No authorization & accounting

Suffer from common attacks


IGMP Extension: Requirements

A generic client-server authentication An authentication framework (e.g., EAP) should be deployable Must be based on IGMPv3 and support “source filtering” Works in in parallel with IGMPv3 and Open multicast group Only authenticated/authorized EUs are allowed to modify

IGMP reception states Performs EU authentication as few times as possible Not inclined to a particular business model or to a specific

relation between NSP and CP Not restricted to single domain Reuses standard protocols and framework

16/06/2008


NAS

Receiver Access Control using IGMP-AC

16/06/2008

AR1

AR2

AR3

CR1

CR2

CR3

EUs

Sender

IGMP-AC (EAP)

IGMP with Access Control (IGMP-AC)• Extended version of IGMPv3• Encapsulates EAP packets

• Verification using SPIN• Validation using AVISPA

AAA ServerParticipants Database

Diameter (EAP)


IGMP-AC Protocol

State Diagrams for Host, AR and AAAS Additional messages

Authentication Unicast Query (auquery) Authentication Report(areport) Authentication Result(aresult)

Required reception states Host: (G, S, EU id, authentication info, filter mode) AR: (G, S, EU id, authorization and accounting info,

filter mode)

16/06/2008


IGMP-AC Verification by PROMELA/SPIN

16/06/2008


Verification Results PROMELA model from the state diagrams Simple model, but satisfies all states/transition of state diagrams First, random simulation runs and no error reported Simulator generates Message Sequence Chart (MSC) Next, SPIN produces the Verifier (C program) from PROMELA

model Different search techniques: Exhaustive, Depth-first, Breadth-

first, Bit-state storage and Hash compact. Search for errors: Assert violation, Invalid end-state, Non-

progress cycle, Never claim and Unreachable state Reaches depth up to > 800 Output confirms free from error, no unreachable state

16/06/2008


EAP auth

End User Authentication using Extensible Authentication Protocol (EAP)

16/06/2008

EAP method

EAP peer

EAP layer

IGMP-AC

Lower layers

EAP peer

IGMP-AC EAP layer

Lower layers

EAP auth

EAP layer

AAA/IP

EAP method

EAP auth

EAP layer

AAA/IP

EU/ Peer

AR/Authenticator/NAS

AAA Server

EAP Encapsulation over IGMP-AC


EAP Method Example

16/06/2008

1. P <- S: EAP-Request/Identity

2. P -> S: EAP-Response/Identity(Id)

3. P <- S: EAP-Req (HDR, SAs, KEs, Ns)

4. P -> S: EAP-Res (HDR, SAp, KEp, Np, [SK{IDp}])

5. P <- S: EAP-Req (HDR, SK{IDs, AUTH})

6. P -> S: EAP-Res (HDR, SK{IDp, AUTH})

7. P <- S: EAP-Success

EAP Internet Key Exchange (EAP-IKEv2) Method

P : Peer/EU N : Nonce HDR : HeaderS : Server/AAAS ID : Identity SA : Cryptographic AlgorithmKE : Deffie-Hellman component AUTH : Authentication payloadSK{x} : x is encrypted and authenticated

Standard EAP messages

D-H exchange

Mutual auth.by AUTH


Security Properties Validation of EAP-IKEv2

16/06/2008

1. P <- S: request_id

2. P -> S: respond_id.P

3. P <- S: SA.KEs.Ns

4. P -> S: SA.KEp.Np.[{IDp}_SKp]

5. P <- S: {S.{AUTHs}_inv(Ks)}_SKs

6. P -> S: {P.{AUTHp}_inv(Kp)}_SKp

7. P <- S: success

Simplified AVISPA Model of EAP-IKEv2

1. Mutual authentication2. Key establishment3. Confidentiality4. Replay protection

Security Goals

KEs : exp(G, DHs) AUTHs : SA.KEs.Ns.NpKEp : exp(G, DHp) AUTHp : SA.KEp.Np.Ns SKp : hash(Ns.Np.exp(exp(G,DHs),DHp)SKs : hash(Ns.Np.exp(exp(G,DHp),DHs)


MitM Attack on P2P Model

16/06/2008

ATTACK TRACE (s,10) -> i: request_id i -> (p,3) : request_id (p,3) -> i : respond_id.p i -> (s,10): respond_id.i (s,10) -> i: SA(3).exp(g,DHs(3)).Ns(3) i -> (p,3) : SA(3).exp(g,DHs(3)).Ns(3) (p,3) -> i : SA(3).exp(g,DHp(4)).Np(4) i -> (s,10): SA(3).exp(g,DHp(4)).Np(4) (s,10) -> i: {s.{SA(3).exp(g,DHs(3)).Ns(3).Np(4)}_inv(ks)}

_(f(Ns(3).Np(4).exp(exp(g,DHp(4)),DHs(3)))) i -> (p,3) : {s.{SA(3).exp(g,DHs(3)).Ns(3).Np(4)}_inv(ks)}

_(f(Ns(3).Np(4).exp(exp(g,DHs(3)),DHp(4))))

Peer Intruder Server

Replaces “p” with “i”

Intruder convinced P he was talking

with S!


Fixing the Attacks First modification

16/06/2008

5. P <- S: hash{MID.SKs}.{S.

{AUTHs}_inv(Ks)}_SKs

6. P -> S: hash{MID.SKp}.{P.

{AUTHp}_inv(Kp)}_SKp

Still AVISPA could find the attacks Second modification fixed the attacks

4. P -> S: SA.KEp.Np.{IDp}_SKp % for symmetric key authentication

4. P -> S: SA.KEp.Np.{P}_SKp % for asymmetric key/password

% authentication

AVISPA reported the pass-through model attack free

Developed from the P2P model by adding authenticator

between peer and server

Newly added

Specified as mandatory


Sender Access Control: Related Work

16/06/2008

Method AAA functions

Authentication Attacks Over-

headRouting Protocol

Intra or Inter domain

Authen.Stamp

Authentication Authorization

Digital signature DoS High CBT Both

CHAP Authentication Authorization

CHAP using password

Dictionary, source address spoof

Low Any protocol

Intra domain

KHIP Authentication Authorization

Digital signature + encryption

DoS Medium CBT, OCBT Both

SACL Authorization No explicit method

Replay, source address spoof Medium Any bidir-

ectional Both

Lack of accounting

Specific authentication

Suffer from common attacks

Dependent on specific protocol

Sender Access Control

16/06/2008 Participant Access Control in IP Multicasting 28

AR1

AR2

AR3

CR1

CR2

CR3Diameter (EAP)

PANA (EAP)

AAA Server

EUs

Sender

IKEv2

IPsec SA

NAS

AAA-Key

IKE-pre-shared-Key

1. Anti-replay2. Prevents source address spoofing3. Minimizes DoS

AAA-Key

PaC-EP-Master-Key

IKE-pre-Shared-Key


Benefits of Sender Access Control Provides AAA functionalities Per-packet cryptographic protection Minimum overhead and fast packet processing Independent of routing protocol Serves both ASM and SSM groups Security services by IPsec SA

Anti-replay Prevents source address spoofing Minimizes DoS

16/06/2008


Policy Framework: Requirements

Extends the proposed access control architecture Entities of MSEC FW will be present Based on IETF Policy FW, should have

PDP: Policy Decision Point PEP: Policy Enforcement Point Policy repository

Divides policy into Data Control Policy and Access Control Policy

Independent of policy specification language and transport protocol

16/06/2008


Policy Framework

16/06/2008

AR2AR4

AR1AR3

AAAServer

AAAServer

GC/KSPDP

NAS/PEP

NAS/PEP

NAS/PEP

NAS/PEP

Policy Protocol (SAML)

Policy Repository (XACML)

Policy Management Tool

Group Owner

Sender

ReceiversReceivers

Sender

PDP: Policy Decision PointPEP: Policy Enforcement Point


Inter-domain Communication: Diameter Agents

16/06/2008

DRD

DRLNAS HMS4. Request

2. Request

6. Answer 5. Answer

example.net example.net example.com

NAS: Network Access ServerDRL: Diameter ReLay AgentDRD: Diameter ReDirect AgentHMS: HoMe AAA Server

1. Request

Network Access Identifier (NAI)

(e.g., [email protected])

3. Redirect Notification

Contains route to

reach example.com

Performs route lookup in Realm Routing Table

No route for HMS


Inter-domain Receiver Access Control

16/06/2008

AR1

EUs

AR1BR1 BR2MBGP

NW1 NW2

NW3

Participants’ Database

Group Owner

Home AAAS AAA

Redirect Relay

Sender

AAA (EAP)

IGMP-AC (EAP)

AAA (EAP)Sends

NAI of EU


Inter-domain Sender Access Control

16/06/2008

AR1MBGP

EUs

AR1BR1 BR2

Participants’ Database

Group Owner

NW1NW2

NW3

Home AAASAAA

(EAP) AAA

RedirectRelaySender

AAA (EAP)

PANA (EAP)

IKEv2

IPsec SA

Checkpoint at entrance of NW1

CR



16/06/2008

AR1

EUs

AR2

BR1

BR2

NW1

NW2

Sender

EUs

AR3BR3

NW3

MBGP

DR

Data Distribution

Multicast SA (MSA)

Checkpoints


Multicast Security Association (MSA)

16/06/2008

MSA S

R1 R2 Rn

GCKSConstructs MSA

MSA provides:• Multicast data integrity • Anti-replay• Prevention of source address spoofing

Get MSA parameters

Transports data



16/06/2008

AR1

EUs

AR2

BR1

BR2

NW1

NW2

Sender

EUs

AR3BR3

NW3

MBGP

DR

SenderReceivers

Centralized MSA



16/06/2008

AR1

EUs

AR2

BR1

BR2

NW1

NW2

Sender

EUs

AR3BR3

NW3

MBGPDR

Distributed MSA

MSA1

MSA2

MSA3

Sender Receivers

Only BRs and ARs are member

of MSA

Receiver of MSA1Sender of MSA2


Establishing the MSA: Extended PIM (S, G) Join

16/06/2008

S

DR

S

DR

BR11 BR12

AR21 AR23AR22 AR24

MSA MSA1

MSA2 MSA3

11hd

dd

AR22AR21

BR11

AR23 AR24

BR12

PIM (S, G) Join

1hd Cost for a d-ary

height h tree:

Cost for a d-ary height h tree:

Centralized MSA

Distributed MSA


Comparison of Performance

16/06/2008

1 2 3 4 5 6 7 8 9 100

2000

4000

6000

8000

10000

12000

DistributedCentralized

Height, h

Nu

mb

er

of

ed

ge

s t

rav

ers

ed

x 1

03


Summary of Two Methods

16/06/2008

Features Centralized MSA Distributed MSAs

Establish-ment cost

High, in worst-case , in best-case .

Low, in best-case , in worst-case .

Maintenance All members maintain a single MSA.

Only the root and the leaves maintain a single MSA. Internal nodes maintain two MSAs.

UpdatingLess scalable and flexible. Updates all members if needed.

Scalable and flexible. A small MSA might be updated independently.

Delivery time Low. BRs need not create IPsec encapsulated packet.

High. BRs have to create IPsec encapsulated packet.

Security features

Less flexible. All routers use same authentication and keys.

Flexible. Individual MSA deploys different authentication and keys.

hdh.dh.

11

hddd

dh.

Low for distributed

Low for centralized

Scalable & flexible for distributed

Low forcentralized

Flexible for distributed


Receiver Mobility and Secured Handoff: Related Work Aggregating many multiple IGMP messages Advanced joining the DDT Deploying Handoff Agent—proxy for MN and replies IGMP query Allowing MN to go into sleep mode Sending unsolicited join without IGMP query Tuning IGMP query timer

16/06/2008

Researchers have concentrated in two issues:

1. Reducing handoff time

2. Optimizing communication between mobile host and IGMP router

Receiver access control and secured handoff are absent!


Mobile Receiver Access Control and Secured Handoff

16/06/2008

Domain3

DR

CR1 CR2

NAS

IGMP-AC (EAP)

Domain2

NAS

MN (EU)

Domain1

NAS

AAA (EAP)AAA (EAP)

Source

Multicast DDT

LAAAS

HAAAS

MN (EU)Handoff

Routing Protocol Join

MR

MR

MR

MR: Multicast RouterMN: Mobile NodeLAAAS: Local AAASHAAAS: Home AAAS

Multiple ro

und-trips


EAP Re-authentication (ERP)

16/06/2008

Peer ER Authenticator Local ER Server

EAP-Initiate/Re-auth-Start

EAP-Initiate / Re-authAAA(EAP-Initiate / Re-auth)

AAA(rMSK, EAP-Finish / Re-auth)EAP-Finish / Re-auth)

Single Round-trip from Peer to Local ER Server

Optional message

MN/EU MR/AR Local AAAS


ERP Key Hierarchy

16/06/2008

Peer/EU AuthenticatorMR/NAS

Local ER Server EAP Server

DSRK DSRKDSRK

rMSK

DS-rRK

rMSK DS-rIK

DS-rRK

DS-rIKrMSK

MSK : Master Session KeyEMSK : Extended Master Session KeyDSRK : Domain Specific Root KeyDS-rRK: Domain Specific re-authentication Root KeyrMSK : re-authentication Master Session KeyDS-rIK : Domain Specific root Integrity Key

MSK EMSK MSK EMSK

Established at the end of EAP session

Mutual authentication


Mobile Receiver Access Control in Wireless Networks

16/06/2008

NAS1

Domain1

Home Domain

Home EAP Server

NAS2

Local ER Server1

AAA (EAP)

AAA (EAP)

IGMP-AC (EAP)

DSRK1

IGMP-AC (ERP)

AAA (ERP)

NAS3

Domain2

NAS4

Local ER Server2

AAA (ERP)

IGMP-AC (ERP)

IGMP-AC (ERP)

AAA (ERP)

DSRK2

Peer Peer Peer PeerMicro Mobility Macro Mobility

ER : EAP Re-authenticationERP: EAP Re-authentication Protocol


Conclusion: Major Contributions

Developing a participant access control architecture A complete access control architecture Provides policy enforcement and acknowledges e-commerce Supports inter-domain multicast groups for the first time

Receiver access control using IGMP-AC Verification using PROMELA/SPIN Validation of EAP-IKEv2 by AVISPA, fixing MitM attack Successfully overcome limitations of previous IGMP extensions

Sender access control Per-packet cryptographic protection Prevents anti-replay, sender address spoofing, minimizes DoS

16/06/2008


Conclusion: Major Contributions

Developing access control policy framework Unique FW—both fits with MSEC FW and follows IETF Policy

FW A novel inter-domain data distribution control

Two alternate ways to deploy MSAs: Centralized and Distributed MSA construction methods—explained in depth Compared the two methods

Mobile Multicast Receiver access control by IGMP-AC Secured handoff with low latency

16/06/2008


Conclusion: Impacts of Our Research Access control is acknowledged as key component to be

solved by IETF MBONED Working Group ITU-T IPTV Focus Group

We have projected Missing components in MBONED framework The additional problems to be addressed

Mobile multicast architecture will open new horizon of wireless networks for IP multicast

Will facilitate the e-commerce researchers with an extendible framework

16/06/2008


Conclusion: Future Work

Complete the development of the protocols Define the packet format Specify timers’ values

Presented our architecture in MBONED Meeting during 69th IETF Meeting, 2007

Actively working on writing Internet Drafts Explaining the IGMP-AC protocol Describing the EAP/ERP encapsulation over IGMP-AC for mobile

multicast Moreover, inter-domain DDT control for ASM groups Extend mobile multicast architecture for source mobility

16/06/2008


PublicationsJournal/Magazine Papers1. S. Islam and J.W. Atwood, “Multicast Receiver Access Control by IGMP-AC”, Submitted to Computer Networks.

2. S. Islam and J.W. Atwood, “Sender Access and Data Distribution Control for Inter-domain Multicast Groups”, will be submitted to Computer Networks.

3. S. Islam and J.W. Atwood, “A Novel Inter-domain Access Control Architecture for IP Multicasting”, in preparation.

Conference Papers4. S. Islam and J.W. Atwood, "Receiver Access Control and Secured Handoff in Mobile Multicast using IGMP-AC",

submitted to 33rd IEEE Conference on Local Computer Networks.

5. S. Islam and J.W. Atwood, "Sender Access Control in IP Multicast", in 32nd IEEE Conference on Local Computer Networks, Dublin, Ireland, 2007 October 15-18, pp. 79-86.

6. S. Islam and J.W. Atwood, "A Policy Framework for Multicast Group Control", in IEEE CCNC--Workshop on Peer-to-Peer Multicasting, Las Vegas, NV, 2007 January 11, pp. 1103-1107.

7. S. Islam and J.W. Atwood, "The Internet Group Management Protocol with Access Control (IGMP-AC) ", in 31 st IEEE Conference on Local Computer Networks, Tampa, Florida, U.S.A., 2006 November 14-16, pp. 475-482.

8. S. Islam and J.W. Atwood, "A Framework to Add AAA Functionalities in IP Multicast'', in Advanced International Conference on Telecommunications (AICT'06), Guadeloupe, French Caribbean, 2006 February 19-22.

Internet Drafts9. “Internet Group Management Protocol with Access Control (IGMP-AC)”, in preparation.

10. “Receiver Access Control and Secured Handoff in Mobile Multicast using IGMP-AC”, in preparation.

16/06/2008


Project Funding

FQRNT Doctoral Research Scholarship

NSERC Discovery Grant (received by Dr. Atwood)

Concordia University Concordia University Graduate Fellowship Concordia University Graduate Entrance Fellowship Campaign for Concordia Graduate Award Concordia University External Award Holder Doctoral

Scholarships

16/06/2008


Thank You!

16/06/2008

Questions?

Documents

Participant Access Control in IP Multicasting. Project Highlights 16/06/2008Participant Access Control in IP Multicasting2 Data Distribution Control Data