Participant Access Control in IP Multicasting
description
Transcript of Participant Access Control in IP Multicasting
Participant Access Control Participant Access Control in IP Multicastingin IP Multicasting
PhD Thesis DefencePhD Thesis Defence
Project HighlightsProject Highlights
16/06/2008 Participant Access Control in IP Multicasting 2
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 Existing Multicast Service ModelService Model
16/06/2008 Participant Access Control in IP Multicasting 3
AR1AR1
AR2AR2
AR3AR3CR3CR3
Sender
ReceiversEUs
Routing ProtocolBuilds DDT
IGMP MessagesEUs Join/Leave
Sends multicast data
Data forwardingusing DDT
CR1CR1
CR2CR2
CR3CR3
DDT: Data Distribution Tree
Existing Multicast Service Existing Multicast Service Model : VulnerabilitiesModel : Vulnerabilities
16/06/2008 Participant Access Control in IP Multicasting 4
AR1AR1
AR2AR2
AR3AR3CR3CR3
Sender
ReceiversEUs
CR1CR1
CR2CR2
CR3CR3
AR4AR4
AR1AR1
IGMP Join
Routing Protocol Join
AdversaryReceiver
Forged data
AdversarySender
Multicast-based ApplicationsMulticast-based Applications
16/06/2008 Participant Access Control in IP Multicasting 5
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 Motivation: Revenue Generation ArchitectureGeneration 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 Participant Access Control in IP Multicasting 6
Why Access Control?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 Participant Access Control in IP Multicasting 7
How to deploy access control?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 Participant Access Control in IP Multicasting 8
Coupling access control with IGMP
Per-packet cryptographic protection at AR
Sender Access Control
• AAA for sender(s)• Per-packet protection
Data Distribution Control
• Protects distribution tree from forged sender • Not routing protocol security
Receiver Access Control
• AAA for receivers/EUs
Overview of Our Access Overview of Our Access Control ArchitectureControl Architecture
16/06/2008 Participant Access Control in IP Multicasting 9
AR1AR1
AR2AR2
AR3AR3CR3CR3
CR1CR1
CR2CR2
Sender
ReceiversEUs
Access Control and Access Control and Authentication in Unicast 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 Participant Access Control in IP Multicasting 10
Authentication, Authorization and Authentication, Authorization and Accounting (AAA) FrameworkAccounting (AAA) Framework
16/06/2008 Participant Access Control in IP Multicasting 11
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 Extensible Authentication Protocol (EAP)Protocol (EAP)
16/06/2008 Participant Access Control in IP Multicasting 12
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 Protocol for carrying Authentication for Network Access (PANA)for Network Access (PANA)
16/06/2008 Participant Access Control in IP Multicasting 13
PaC PAA AS
EP SNMP/API
PANA
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 Key Challenges for Access Control ArchitectureControl 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 Participant Access Control in IP Multicasting 14
Out of the scope of the thesis
NAS
NAS
Proposed ArchitectureProposed Architecture
16/06/2008 Participant Access Control in IP Multicasting 15
AR1AR1
AR2AR2
AR3AR3CR3CR3
CR1CR1
CR2CR2
Sender
EUs
AAAS
Participants Database &
Policy Server
Updates Registration
GO/MRFI
Diameter
IGMP Carrying EU auth. info
Receiver Access Control: Receiver Access Control: Related WorkRelated Work
16/06/2008 Participant Access Control in IP Multicasting 16
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 ac- cess 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: RequirementsIGMP 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 Participant Access Control in IP Multicasting 17
NAS
Receiver Access Control Receiver Access Control using IGMP-ACusing IGMP-AC
16/06/2008 Participant Access Control in IP Multicasting 18
AR1AR1
AR2AR2
AR3AR3
CR1CR1
CR2CR2
CR3CR3
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 ProtocolIGMP-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 Participant Access Control in IP Multicasting 19
IGMP-AC Verification by IGMP-AC Verification by PROMELA/SPINPROMELA/SPIN
16/06/2008 Participant Access Control in IP Multicasting 20
Verification ResultsVerification 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 Participant Access Control in IP Multicasting 21
EAP authEAP auth
End User Authentication using End User Authentication using Extensible Authentication Protocol (EAP)Extensible Authentication Protocol (EAP)
16/06/2008 Participant Access Control in IP Multicasting 22
EAP methodEAP method
EAP peerEAP peer
EAP layerEAP layer
IGMP-ACIGMP-AC
Lower layersLower layers
EAP peerEAP peer
IGMP-AC IGMP-AC EAP layerEAP layer
Lower layersLower layers
EAP authEAP auth
EAP layerEAP layer
AAA/IPAAA/IP
EAP methodEAP method
EAP authEAP auth
EAP layerEAP layer
AAA/IPAAA/IP
EU/ Peer
AR/Authenticator/NAS
AAA Server
EAP Encapsulation over IGMP-AC
EAP Method Example EAP Method Example
16/06/2008 Participant Access Control in IP Multicasting 23
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
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) MethodEAP 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 Security Properties Validation of EAP-IKEv2 of EAP-IKEv2
16/06/2008 Participant Access Control in IP Multicasting 24
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
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-IKEv2Simplified AVISPA Model of EAP-IKEv2
1. Mutual authentication2. Key establishment3. Confidentiality4. Replay protection
1. Mutual authentication2. Key establishment3. Confidentiality4. Replay protection
Security GoalsSecurity 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 ModelMitM Attack on P2P Model
16/06/2008 Participant Access Control in IP Multicasting 25
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))))
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!
Intruder convinced P he was talking
with S!
Fixing the AttacksFixing the Attacks First modification
16/06/2008 Participant Access Control in IP Multicasting 26
5. P <- S: hash{MID.SKs}.{S.
{AUTHs}_inv(Ks)}_SKs
6. P -> S: hash{MID.SKp}.{P.
{AUTHp}_inv(Kp)}_SKp
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
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: Sender Access Control: Related WorkRelated Work
16/06/2008 Participant Access Control in IP Multicasting 27
MethodAAA functions
Authentication
AttacksOver- head
Routing Protocol
Intra or Inter domain
Authen.Stamp
Authentication Authorization
Digital signature
DoS High CBT Both
CHAPAuthentication Authorization
CHAP using password
Dictionary, source address spoof
LowAny protocol
Intra domain
KHIPAuthentication Authorization
Digital signature + encryption
DoS MediumCBT, OCBT
Both
SACL AuthorizationNo explicit method
Replay, source address spoof
MediumAny bidir-ectional
Both
Lack of accounting
Specific authentication
Suffer from common attacks
Dependent on specific protocol
Sender Access ControlSender Access Control
16/06/2008 Participant Access Control in IP Multicasting 28
AR1AR1
AR2AR2
AR3AR3
CR1CR1
CR2CR2
CR3CR3Diameter (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 Benefits of Sender Access ControlAccess 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 Participant Access Control in IP Multicasting 29
Policy Framework: Policy Framework: RequirementsRequirements
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 Participant Access Control in IP Multicasting 30
Policy Framework
16/06/2008 Participant Access Control in IP Multicasting 31
AR2AR2AR4AR4
AR1AR1AR3AR3
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: Inter-domain Communication: Diameter AgentsDiameter Agents
16/06/2008 Participant Access Control in IP Multicasting 32
DRDDRD
DRLDRLNASNAS HMSHMS4. Request
2. Request
6. Answer
5. Answerexample.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])Network Access Identifier (NAI)
(e.g., [email protected])
3. Redirect Notification
Contains route to
reach example.comContains route to
reach example.com
Performs route lookup in Realm Routing Table
Performs route lookup in Realm Routing Table
No route for HMSNo route for HMS
Inter-domain Receiver Inter-domain Receiver Access ControlAccess Control
16/06/2008 Participant Access Control in IP Multicasting 33
AR1AR1
EUs
AR1AR1BR1BR1 BR2BR2MBGP
NW1NW1 NW2NW2
NW3NW3
Participants’ Database
Group Owner
Home AAAS AAA
Redirect Relay
Sender
AAA (EAP)
IGMP-AC (EAP)
AAA (EAP)Sends
NAI of EU
Inter-domain Sender Inter-domain Sender Access ControlAccess Control
16/06/2008 Participant Access Control in IP Multicasting 34
AR1AR1MBGP
EUs
AR1AR1BR1BR1 BR2BR2
Participants’ Database
Group Owner
NW1NW1 NW2NW2
NW3NW3
Home AAASAAA
(EAP) AAA
RedirectRelaySender
AAA (EAP)
PANA (EAP)
IKEv2
IPsec SA
Checkpoint at entrance of NW1
CRCR
Data Distribution ControlData Distribution Control
16/06/2008 Participant Access Control in IP Multicasting 35
AR1AR1
EUs
AR2AR2
BR1BR1
BR2BR2
NW1NW1
NW2NW2
Sender
EUs
AR3AR3BR3BR3
NW3NW3
MBGP
DRDR
Data Distribution
Multicast SA (MSA)
Checkpoints
Multicast Security Multicast Security Association (MSA)Association (MSA)
16/06/2008 Participant Access Control in IP Multicasting 36
MSA SS
R1R1 R2R2 RnRn
GCKSConstructs MSA
MSA provides:• Multicast data integrity • Anti-replay• Prevention of source address spoofing
Get MSA parameters
Transports Transports datadata
Data Distribution ControlData Distribution Control
16/06/2008 Participant Access Control in IP Multicasting 37
AR1AR1
EUs
AR2AR2
BR1BR1
BR2BR2
NW1NW1
NW2NW2
Sender
EUs
AR3AR3BR3BR3
NW3NW3
MBGP
DRDR
SenderSenderReceivers
Centralized MSA
Data Distribution ControlData Distribution Control
16/06/2008 Participant Access Control in IP Multicasting 38
AR1AR1
EUs
AR2AR2
BR1BR1
BR2BR2
NW1NW1
NW2NW2
Sender
EUs
AR3AR3BR3BR3
NW3NW3
MBGPDRDR
Distributed MSA
MSA1
MSA2
MSA3
Sender Sender Receivers
Only BRs and ARs are member
of MSA
Only BRs and ARs are member
of MSA
Receiver of MSA1Sender of MSA2
Establishing the MSA: Establishing the MSA: Extended PIM (S, G) JoinExtended PIM (S, G) Join
16/06/2008 Participant Access Control in IP Multicasting 39
S
DRDR
S
DRDR
BR11BR11BR12BR12
AR21 AR23AR22 AR24
MSA MSA1
MSA2 MSA3
11hd
dd
AR22AR21
BR11BR11
AR23 AR24
BR12BR12
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 PerformanceComparison of Performance
16/06/2008 Participant Access Control in IP Multicasting 40
Summary of Two MethodsSummary of Two Methods
16/06/2008 Participant Access Control in IP Multicasting 41
Features Centralized MSA Distributed MSAs
Establish-ment cost
High, in worst-case , in best-case .
Low, in best-case , in worst-case .
MaintenanceAll 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 timeLow. 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
hdd
d
dh.
Low for distributed
Low for centralized
Scalable & flexible for distributed
Low forcentralized
Flexible for distributed
Receiver Mobility and Secured Receiver Mobility and Secured Handoff: Related WorkHandoff: 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 Participant Access Control in IP Multicasting 42
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!
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 Mobile Receiver Access Control and Secured Handoffand Secured Handoff
16/06/2008 Participant Access Control in IP Multicasting 43
Domain3Domain3
DRDR
CR1CR1 CR2CR2
NASNAS
IGMP-AC (EAP)
Domain2Domain2
NASNAS
MN (EU)
Domain1Domain1
NASNAS
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)EAP Re-authentication (ERP)
16/06/2008 Participant Access Control in IP Multicasting 44
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 HierarchyERP Key Hierarchy
16/06/2008 Participant Access Control in IP Multicasting 45
Peer/EU AuthenticatorMR/NAS
Local ER Server EAP Server
DSRKDSRK DSRKDSRKDSRKDSRK
rMSKrMSK
DS-rRKDS-rRK
rMSKrMSK DS-rIKDS-rIK
DS-rRKDS-rRK
DS-rIKDS-rIKrMSKrMSK
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
MSKMSK EMSKEMSK MSKMSK EMSKEMSK
Established at the end of EAP session
Mutual authentication
Mobile Receiver Access Mobile Receiver Access Control in Wireless NetworksControl in Wireless Networks
16/06/2008 Participant Access Control in IP Multicasting 46
NAS1NAS1
Domain1Domain1
Home Home DomainDomain
Home EAP Server
NAS2NAS2
Local ER Server1
AAA (EAP)
AAA (EAP)
IGMP-AC (EAP)
DSRK1
IGMP-AC (ERP)
AAA (ERP)
NAS3NAS3
Domain2Domain2
NAS4NAS4
Local ER Server2
AAA (ERP)
IGMP-AC (ERP)
IGMP-AC (ERP)
AAA (ERP)
DSRK2
Peer Peer Peer PeerMicro MobilityMicro Mobility Macro MobilityMacro Mobility
ER : EAP Re-authenticationERP: EAP Re-authentication Protocol
Conclusion: Major ContributionsConclusion: 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 Participant Access Control in IP Multicasting 47
Conclusion: Major ContributionsConclusion: 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 Participant Access Control in IP Multicasting 48
Conclusion: Conclusion: Impacts of Our ResearchImpacts 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 Participant Access Control in IP Multicasting 49
Conclusion: Future WorkConclusion: 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 Participant Access Control in IP Multicasting 50
PublicationsPublicationsJournal/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 Participant Access Control in IP Multicasting 51
Project FundingProject 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 Participant Access Control in IP Multicasting 52
Thank You!Thank You!
16/06/2008 Participant Access Control in IP Multicasting 53
Questions?