The Internet Group Management Protocol with ... - Semantic Scholar

The Internet Group Management Protocol with Access Control (IGMP-AC) Salekul Islam and J. Willam Atwood Concordia University Department of Computer Science and Software Engineering Montreal, Quebec, Canada {salek is, bill}@cse.concordia.ca

Abstract

able to take the advantages of multicasting, its commercial deployment is still facing obstacles due to various security measures. Both the Content Providers (CP) and the Network Service Providers (NSP) can generate significant amounts of revenue by deploying multicast if there is a mechanism for streaming revenue from the end users or the receivers of the delivered content. To ensure revenue collection from the end users, we have to identify the end users and to keep a record of the content used by them. The source of the content (the CP) should not be concerned about enforcing the requirement that only the authenticated and the authorized end users are receiving the services. The CP should out-source the task and delegate the NSP to perform Authentication, Authorization and Accounting (AAA) functionalities [19]. The generated revenue should be divided between the parties: the CP and the NSP. To achieve these complex tasks we have to discard the classical “anyone can send any one receive” multicast model where the receivers remain anonymous throughout the group activity period. We need an architecture that will add AAA functionalities to the present multicast model. A framework has been developed in [14], where the nearest Access Router (AR) of an end user will perform the AAA client behaviors. The end user (receiver) or host informs the AR of its interest in receiving multicast traffic destined to a particular group using the IGMP [3] (MLD [25] in case of IPv6). However, the present IGMP/MLD Join message does not carry the identity of the user or the host. The IGMPv3 supports “source filtering” through which a system can request to receive multicast packets only from a specific list of sources, or from all but specific sources, sent to a particular multicast group. In this paper, we have presented the Internet Group Management Protocol with Access Control (IGMP-AC), a modified version of the IGMPv3, which deploys one of the AAA protocols for end user authentication and authorization. The rest of the paper is organized as follows: section 2 will discuss briefly some of the existing methods, section 3 will explain all the details of the IGMP-AC. In section 4, the

IP Multicast is best known for its bandwidth conservation and lower resource utilization. The classical model of multicast makes it difficult to permit access only to authorized end users or paying customers. A scalable, distributed and secure architecture is needed where authorized end users can be authenticated before delivering any data or content. In (unsecure) multicast, an end user or host informs the multicast edge-router of its interest in receiving multicast traffic using the Internet Group Management Protocol (IGMP). To carry the end user authentication data, we have extended the IGMPv3 protocol, and called our new version the Internet Group Management Protocol with Access Control (IGMP-AC). New messages and reception states have been added to IGMPv3, and the AAA framework is used for end user authentication, authorization and accounting purposes. IGMP-AC is presented using state diagrams of the entities that are involved. The proposed protocol has been modeled in PROMELA, and has also been verified using SPIN. Keywords— Multicasting; Internet Group Management Protocol (IGMP); Access control; Authentication, Authorization and Accounting (AAA)

1. Introduction IP multicast was standardized by the IETF in RFC 1112 [5]. It is an efficient technology to deliver data to many recipients who may be geographically scattered. For each recipient, multicast replicates data at a point as close to that recipient as possible. Thus, it is considered as a bandwidth conservation technique with respect to unicast, especially when there are many recipients and large amounts of data (e.g., streaming video) are being sent. Though different types of applications including video-conferencing, distance learning, software updates, stock quotes, etc. are

1-4244-0419-3/06/$20.00 ©2006 IEEE

475

use of Extensible Authentication Protocol (EAP) [2] to support flexible authentication has been introduced. The next section will discuss different issues related to policy framework of AAA Server (AAAS). We have also modeled the IGMP-AC in PROMELA [12] and verified the model using SPIN [11]. The model and the verification results have been presented in section 6. Finally, section 7 will be the conclusion and the work that we have planned to accomplish in the future.

CP CS

AR

AAAS CR

CR

2. Related work NAS

AAA issues are not addressed well in IP multicast by the researchers. We have found only a few attempts that meet our requirements. Among these, the End User Identification and Accounting (EUIA) [24] system deploys AAA protocols for user authentication, accounting and host identification. The Internet Group Membership Authentication Protocol (IGAP) [9] provides IGMPv2 functionalities with the addition of user authentication and accounting. It suffers from a serious threat due to its use of a plaintext password. A multicast architecture has been presented in [10], where a centralized Multicast Manager (MM) has been introduced. The “source filtering” option in the IGMPv3 has been used to control the access of the receivers. An architecture that uses CHAP and deploys RADIUS [22] has been proposed in [13] to authenticate both the receiver and the sender. Here, we have only mentioned the methods that are similar to our research direction. A summary of the different approaches regarding AAA issues is presented in [14]. A complete list of receiver and sender access control mechanisms, and their comparisons can be found in [16, 15].

AR

Host 1

Host 2

Host 3

Figure 1. The IGMP-AC protocol architecture

1. The end user authentication process should support all sorts of authentication — from simple password based authentication to complex certificate based authentication. 2. The IGMP version 3 is the current standard designed by the IETF. The modification will be based on the IGMPv3 and must support the “source filtering” property as well. 3. The IGMP-AC will not disrupt the usual function of the IGMPv3 and end user access control must be performed only if required. 4. The least functionality and minimal workload should be added to the ARs and the hosts. 5. Authentication is a costly process in terms of CPU cycles and bandwidth. Therefore, an end user should send the authentication information to the AR as few times as possible.

3. IGMP with Access Control (IGMP-AC) The Internet Group Management Protocol with Access Control (IGMP-AC) will perform access control of the end users (only if required for a specific application) in addition to the IGMPv3 functionalities. The architecture of the IGMP-AC has been presented in Figure 1. Here, “access control” is used to address all the AAA functionalities: to authenticate successfully, to verify authorization to receive group data for which IGMP-AC join message has been sent, and also to keep accounting information for each end user. In the following subsections the rationale behind the architecture, different participats and their roles, the messages of the protocol, and required reception states will be explained.

3.2. Assumptions It is important to clarify when the IGMP-AC protocol will anticipate access control. We have assumed two types of multicast groups: Open Group, to/from which a host can join/leave any time by sending regular IGMPv3 messages, and Secured Group, where access control mechanism of the IGMP-AC will take place to join/leave to/from the group. While the IGMP-AC supports “source filtering” we have to extend the definition of Secured Group, which may be either Group-Specific, (*, G) or Group-and-Source-Specific, (S*, G). Here, “*” by itself means absence of any specific multicast source address and “S*” means one or more multicast source addresses.

3.1. Essential properties The following essential properties have been identified in [14] for the modification of the IGMPv3 protocol to perform access control of end users:

476

The AAA protocols (e.g., RADIUS [22]) have been designed to control access to network resources, and are being used very successfully. Use of the AAA protocols in access control of content or service should be similar to access control of network resources. The only difference is instead of dealing with physical resources, we are dealing with data or packets of a network. It is assumed that the AAAS must be updated about the Secured Groups and end users authentication information before it receives a request for the status of a specific group or to authenticate an end user. In RFC 3376 [3], IPSec [18] in Authentication Header mode [17] has been suggested for use to provide connectionless integrity, data origin authentication and replay protection for the IGMPv3 messages. Thus, an AR will be certain that IGMPv3 messages are coming from a system (or, more specifically, a system with the proper key) on the LAN to which the AR is directly connected. Two types of key management are possible, a symmetric signature algorithm with a single key for the LAN or an asymmetric signature algorithm, where a sender can be authenticated individually. We are adopting the same concept of using IPSec in Authentication Header mode for the messages of the IGMP-AC protocol. Finally, it is assumed that one of the multicast group key management protocols (e.g., SIM-KM [20]) is deployed to protect multicast data from unauthorized users.

each other using the IGMP-AC while the AR/NAS and the AAAS use one of the AAA protocols. From this point, whenever we use the term “AR” it will indicate both the AR and the NAS. In this secton, we explain the IGMP-AC protocol by using flow charts. For each entity (i.e., host, AR and AAAS), one flow chart has been drawn and that will explain the state diagram of the corresponding entity. In the flow charts, two-dimensional labeled arrows are used to represent sending or receiving of messages to or from the entity labeled inside the arrow. An incoming arrow represents receiving of a message and an outgoing arrow represents sending of a message. We have adopted the phrase g or gs to indicate Group-Specific or Group-and-SourceSpecific. Thus, query(g or gs) is to mean that this is either a Group-Specific Query or a Group-and-SourceSpecific Query. The circular state, labeled as “S”, stands for the “Start” state. Thus an arrow towards “S” means it is going to the “Start” state. Start

API

join (g_or_gs, id, pwd)

API

report (add, AR g_or_gs )

leave (g_or_gs)

report (del, g_or_gs )

AR

query (g_or_gs)

report (current, g_or_gs)

AR

AR

3.3. Participants and their roles AR

There are five participants in the IGMP-AC architecture: CP, Core Routers (CR), ARs, End Users (EU) and AAAS. The Network Access Servers (NAS) or the AAA client will reside inside the AR. The CP will deliver service or data packets through the Content Server (CS). It will send multicast packets to the nearest AR, and the AR will forward the packets through the multicast data distribution tree, which has already been constructed by the CRs. The AR that is directly connected to the subnet of the end users will perform two tasks: it will receive and process the IGMP messages and will act as a NAS by communicating with the AAAS. If an end user has to be authenticated, the AR/NAS will collect this authentication information from the IGMP Join message and forwards a request to the AAAS. The AAAS will verify this information and send the answer to the NAS. When an end user leaves a multicast group, its group activity will be sent to the AAAS inside an account message.

auquery (g_or_gs, )

areport (rstate, g_or_gs, id, pwd)

AR

aresult (g_or_gs, id, result )

no

result?

S

S

AR

yes

del

rstate?

add

del (g_or_gs, id, pwd )

add (g_or_gs, id, pwd )

S

S

Figure 2. State diagram for host The state diagram for a host that communicates with an AR using the IGMP-AC is shown in Figure 2. Here, API means Application Program Interface or any upper layer protocol interface. The leave and the join messages are not part of the IGMP-AC protocol, they are used to express that one of the applications, running in the host is interested to join or leave a multicast group. The filter mode (rstate) of the reception states that a host maintains, may

3.4. Protocol description The architecture in Figure 1 has three entities: hosts, AR/NAS and AAAS. A host and the AR communicate with

477

Start

have any of the three values: add, del or current. When a host receives a join message, it creates a new reception state and assigns the filter mode with the value add. When it receives a leave message for a g or gs, the filter mode is changed from current to del. The filter mode is assigned with the value current for the period of time the host maintains membership for a group. In Figure 2, query and report messages are standard IGMPv3 messages; auquery, areport and aresult have been created for the IGMP-AC protocol. In this diagram, a simple password based authentication mechanism is illustrated. In section 4, we have explained how this mechanism can be extended for advanced authentication mechanisms (e.g., CHAP, certificate, etc.) where more than one round-trip may be required for a successful authentication. To minimize the number of times authentication data has to be sent by the host, only in response to an auquery, the host will send an areport to the AR carrying the identity and the password of the end user. The AR will inform the host of the result of the authentication process by sending an aresult message. On successful authentication, if the value of rstate was add, the host will add a new reception state for (g or gs, id, pwd) by changing the filter mode from add to current. If the value of rstate was del, the host will delete the reception state (g or gs, id, pwd) for which the filter mode was assigned del before.

querytimer (g_or_gs) expires

del (g_or_gs, id)

S

AAAS

report (rstate, g_or_gs)

H

g is in database?

no request (g_or_gs)

answer (open)

AAAS

AAAS

answer (secured)

Do nothing, IGMPv3 will be used current

rstate?

S

reset querytimer (g_or_gs)

request (g_or_gs, id, pwd)

AAAS

AR

answer (secured)

yes no

AR

account AR (g_or_gs, id, data)

add (g_or_gs, id)

S

yes

answer (yes, time)

valid?

update (id, data)

answer (open)

AR

S

AAAS

answer (no)

aresult (g_or_gs, H id, no)

S

del

del (g_or_gs, id)

account (g_or_gs, id, data) AAAS

query (g_or_gs)

H

no

AR

set querytimer (g_or_gs)

S S

AAAS

aresult (g_or_gs, H id, yes)

request (g_or_gs, id, pwd)

secured?

answer (yes, time)

rstate?

H

areport (rstate, g_or_gs, id, pwd)

H

S

add

request (g_or_gs)

add/del

auquery (g_or_gs)

refresh (g_or_gs)

Start

AR

yes

answer (no)

S

AR

Figure 4. State diagram for Access Router S

S

defining new Attribute Value Pairs (AVP). (All data are delivered by Diameter in the form of AVPs.) There are two types of request messages: one for the status of a group and the other for a specific end user. By sending a request(g or gs), the AR wants to know if the type of the group for g or gs is Secured or Open. The purpose of sending a request(g or gs, id, pwd) is to verify the identity and the password of the end user and also if he/she is authorized to join the group g or gs. In

Figure 3. State diagram for AAA Server The state diagram for the AAAS that communicates with the AR using one of the AAA protocols is presented in Figure 3. We have assumed that, request, answer and account are messages of the Diameter [4] protocol. The constructions of these messages are out of the scope of this paper and are included in our future study. We mention that it is possible to extend the Diameter protocol by

478

response to request, the AAAS will send an answer. If the end user is successfully authenticated and also authorized for the group g or gs, the AAAS will send an answer(yes, time) where time is to indicate the period of time up to which the end user is allowed to receive data for the multicast group g or gs. The AAAS will update its database indexed by (g or gs, id) on receiving an account message. This database can be accessed later by the CP as described in [14]. The state diagram for the AR has been presented in Figure 4. We have already explained all the messages of this diagram. We have summarized the functionalities of the AR in the following:

destination address of 224.0.0.1, the all-system multicast address. A Group-Specific or Group-and-SourceSpecific Query is sent with an IP destination address equal to the multicast address of interest. An Authentication Unicast Query, denoted as auquery in the diagrams, is sent with a unicast destination address. Whenever the AR receives a report from a host with the value of filter mode as either add or del, the AR gets the IP address of the host from that report, and uses that IP address as the IP destination address of the auquery message. This query is sent with g or gs, hence it has either Group-Specific or Groupand-Source-Specific type. 2. Authentication Report– In the above diagrams, Authentication Report is presented by areport. It carries end user authetication information. This report is sent by a host in response to auquery only. An areport contains the end user’s reception state filter mode, identity and password. When any other authentication mechanism is used it will carry the corresponding authentication information. This issue will be discussed in detail in the next section. 3. Authentication Result– The AR forwards authentication information of the end user to the AAAS and gets back the result from the AAAS. This result is relayed to the host by an Authentication Result or aresult message. It consists of (g or gs, id, result), where result is a flag (value of yes/no) type data.

• The AR will maintain a list of Secured groups of type g or gs and whenever a report with a new g or gs is received, it will request the AAAS to inform about it. If this is an Open group, the IGMPv3 protocol will be followed, otherwise, the group will be added to the list. • If the AR receives a report with the reception state’s filter mode as current, it will refresh the reception state and reset the timer, querytimer for that group only. No authentication information will be exchanged at that time. • The AR will send an auquery if it receives a report with the reception state’s filter mode as either add or del. Thus, authentication is only necessary during joining or leaving of an end user. • The actual authentication will be performed by the AAAS, the AR receives authentication information (here, user identity and password) through the areport message, extracts this information and forwards it to the AAAS by sending a request message. • If the authentication is successful and the filter mode was add the AR will add a new reception state for (g or gs, id). • For successful authentication, with filter mode value as del, an account message will be sent to the AAAS and an IGMPv3 query will be sent to all the hosts inside the subnet. A timer named querytimer for the group g or gs will be set. • In case the querytimer for the group g or gs is expired, all the entries with g or gs in reception states will be deleted.

3.6. Required reception states To operate the IGMP-AC successfully a set of extra reception states should be maintained by the AR and the hosts in addition to the IGMP reception states. The AR and the hosts will have to maintain different sets of reception states. A host will be informed through the Application Program Interface (API) or upper-layer protocol interface that it should perform a join operation to a multicast group. The host will be able to differentiate between an Open Group and a Secured Group by checking the information received from the API or upper-layer protocol interface as some authentication information must be present for a Secured group. If it is an Open Group the host will follow the IGMPv3 standard [3]. In case of a Secured Group, the host will have to maintain (group address, source address, identity of end user, authentication information, filter mode). For Group-Specific membership the source address field will be empty and for Group-and-Source-Specific membership this field will contain one or more source address(es). The filter mode will be any value of add, del or current.

3.5. Additional messages The IGMP-AC has added three messages to the existing ones of the IGMP protocol. 1. Authentication Unicast Query– In IGMPv3, all types of query messages are sent with an IP multicast destination address. A General Query is sent with an IP

479

The AR always maintains a list of multicast groups of g or gs format. Whenever a report with unknown group (which is not present in the existing group list) arrives, the AR will communicate with the AAAS to update its list. This list is very simple and consists of

an end user is using. Next, we present an authentication framework, the Extensible Authentication Protocol [2] that can be deployed with the IGMP-AC protocol to facilitate the authentication process by adding flexibility.

(group address, source address, status).

4.1. Extensible Authentication Protocol

Here, the group address and the source address are same as for the reception states of a host, and the status is either Open or Secured. The AR should collect accounting information for each end user and when an end user leaves a multicast group, the AR should forward accounting information to the AAAS by sending an account message. Moreover, for each successful authentication, the AAAS will send the authorization information to the AR. In Figure 3 and 4, this authorization information is the duration of time up to which point the end user is authorized to receive multicast group data. Though, it can be any thing depending on a specific application. It is to be noted that the AR will never maintain authentication information of an end user. To meet all these requirements the AR should maintain the reception states of

End User

AAA Server

NAS (initiate Eap) EAP Request #1 (Identity) EAP Response #1 (Identity) Diameter-EAP-Request EAP-Payload (EAP Response #1) Diameter-EAP-Answer EAP-Payload (EAP Request #2) EAP Request #2

EAP Response #N Diameter-EAP-Request EAP-Payload (EAP Response #N)

(group address, source address, identity of end user, authorization information, accounting information, filter mode).

EAP Success

Diameter-EAP-Answer EAP-Payload (EAP Success) (authorization AVPs)

Figure 5. EAP and Diameter messages

4. Authentication protocol

The Extensible Authentication Protocol (EAP) supports multiple authentication mechanisms. It has been used between a host and a router connected via switched circuit or dial-up line that uses PPP [23]. It has also been used between a switch and an access point that uses IEEE 802 [1]. The EAP runs between an authenticator and a peer, where the authenticator can act as a pass-through, and a backend authentication server (or EAP server) may be connected with the authenticator. The actual authentication will be performed by the backend server. The pass-through authenticator is nothing but a NAS and the backend server is an AAAS. In such an environment, the EAP will be used by the end user (host) and the NAS, and one of the AAA protocols will be used by the NAS and the AAAS. The EAP packets that arrive at the NAS are sent to the AAAS by encapsulating them inside the AAA packets, and the NAS will decapsulate the AAA packets received from the AAAS and forward the EAP packets to the end user. The Diameter EAP application that carries the EAP packets inside the Diameter packets between a NAS (EAP authenticator) and an AAAS (backend authentication server) is already standardized by the IETF in RFC 4072 [7]. There are four types of EAP messages: Request, Response, Success and Failure. The Request is always sent by the authenticator to the peer, and the peer replies to it

We have presented the basic and simplest authentication scheme, password based authentication in the previous section. Our goal is to develop a framework that will be much more flexible to support all types of authentication methods. Authentication is not free of cost and is not even required for every application. Most of the time, when we expect a revenue stream from the end users, we need authentication. In some cases, in a closed environment, for example, a videoconference among the policy makers of a giant company, authentication is required. However, the framework we want to develop must support a large variety of authentication schemes. Some of the key factors that dominate to decide the preferable authentication scheme are: 1. The specific application using IP multicast to deliver data to the end users. 2. The value of the information we want to distribute among the end users. It may be valuable in terms of revenue (e.g., pay-per-view) or sensitive information (e.g., company secret, military intelligence). 3. The resources of the network, including AAAS, ARs and the links among these entities. 4. The hardware and software resources of the machine

480

by sending a Response to the authenticator. The sequence of different messages between the NAS and the end user, and between the NAS and the AAAS is shown in Figure 5. The EAP Request and Response messages are sent inside the Diameter messages. Depending on the authentication method used, more than one round-trip may be required. In this scenario, after N round-trips, the AAAS authenticates the end user and sends an EAP Success message inside an EAP-Payload. If authorization is requested appropriate authorization AVPs are sent also.

dard policy for the AAA protocols. Three areas have been identified for the multicast security policy in the multicast group security architecture: policy creation, high-level policy translation, and policy representation [8]. To develop a policy framework, we have to deal with the AAA policy as well as with the multicast security policy. The IETF has standardized the Common Open Policy Service (COPS) protocol [6], a simple query and response protocol that can be used to exchange policy information between a policy server (Policy Decision Point or PDP) and its clients (Policy Enforcement Points or PEPs). In the IGMP-AC architecture, the AAAS will be the Policy Decision Point and the NAS will be Policy Enforcement Points. Another way to represent the policy in the IGMP-AC architecture is to use the Extensible Markup Language (XML), one such representation for secure multicast can be found in [21].

4.2. Use of EAP in IGMP-AC

End User

NAS

auquery (EAP Request #1 (Identity))

6. Verification using SPIN

areport (EAP Response #1 (Identity))

We have used the formal verification language, PROMELA (PROcess MEta LAnguage) [12] to specify the verification model, and used the tool, SPIN (Simple PROMELA INterpreter) [11], to verify our model. SPIN is a generic verification system, which can simulate the execution of a verification model by interpreting PROMELA statements on the fly. It can detect many types of logical design error in distributed systems and it checks the logical consistency of a specification. It reports on deadlock, livelock and improper termination.

auquery (EAP Request #2)

areport (EAP Response #N) aresult (EAP Success)

Figure 6. EAP inside IGMP-AC protocol The EAP framework exactly resembles the IGMP-AC architecture when the authenticator acts as pass-through. The AR/NAS in Figure 1 can perform the tasks of the passthrough authenticator, the AAAS will act as backend server, and the Diameter protocol [4, 7] must be used for the communication of the AR (NAS) and the AAAS. The only discrepancy we have to solve is in the IGMP-AC, a host communicates with the AR (NAS) using the IGMP-AC protocol, whereas in the EAP framework, a host communicates with the NAS using the EAP protocol. We are not presenting the solution of this problem in detail. One possible solution is to send the EAP packets inside the IGMP-AC messages. In Figure 6, the sequence of the messages is shown, where an EAP Request is encapsulated inside an auquery message, and an EAP Response is encapsulated inside an areport message. An EAP Success or Failure is encapsulated inside an aresult message. For N round-trips of the EAP messages, N pairs of (auquery, areport) messages will be exchanged.

6.1. Description of the model We have developed the PROMELA model from the state diagrams of the IGMP-AC protocol presented in section 3. We have designed the model in such a way that it is as simple as possible, but at the same time, it satisfies all the states and transitions of the diagrams. Our model consists of three processes: host for a host, ar for the AR and aaas for the AAAS. Before the starting of the processes, aaas is initialized with the AAAS database, which consists of the membership information (e.g., group and source addresses, user id and password, etc.). At the beginning, the reception state of ar is empty. We have invoked multiple instances of host, through which end users can join/leave dynamically to/from different multicast groups. In the runtime, the ar will buildup its reception states according to the behavior of the hosts.

6.2. Verification results

5. Policy framework for AAAS SPIN can be used for either simulation or verification. Once we are sure that our model is free from syntax error, different random simulation runs are performed with

The multicast security policy is still an open issue for the research community. Even to date, there is no stan-

481

various SPIN options, and no errors were reported by the simulator. These simulation runs are not intended to measure performance, but rather to build our confidence that our model is behaving as expected. The verifier is compiled several times with different search techniques: exhaustive or full state exploration, partial order reduction, depth-first and breadth-first search. When the verifier is executed it looks for different errors such as assertion violation, invalid end state, non-progress cycles and never claim. In different verification runs, it goes up to the depth of 642 levels, generates from 70 to 200 thousand states and uses 225 to 634 Mbytes of memory while searching for an error. The outputs confirm that our model is free from any type of error. From the outputs, it is also established that there is no unreachable state in our design. The working of the ar, the aaas and the host processes are observed and are found to function as expected.

[5] S. Deering. Host Extensions for IP Multicasting, RFC 1112, August, 1989. [6] D. Durham, et al. COPS (Common Open Policy Service) Protocol. RFC 2748, January 2000. [7] P. Eronen, et al. Diameter Extensible Authentication Protocol (EAP) Application. RFC 4072, August 2005. [8] T. Hardjono and B. Weis. The Multicast Group Security Architecture. RFC 3740, March 2004. [9] T. Hayashi, et al. Internet Group membership Authentication Protocol (IGAP). Internet Draft, work in progress. [10] B. Hilt and J. Pansiot. Using IGMPv3 to manage multicast access. 4th Conference on Security and Network Architectures, Batz sur Mer, France, June 2005. [11] G. J. Holzmann. The Model Checker SPIN. IEEE Transactions on Software Engineering, 23(5):279–295, May 1997. [12] G. J. Holzmann. The SPIN Model Checker. Addison-Wesley, September 2003. [13] N. Ishikawa, et al. An Architecture for User Authentication of IP Multicast and Its Implementation. IEEE/APAN Internet Workshop, Japan, February 1999. [14] S. Islam and J. William Atwood. A Framework to Add AAA Functionalities in IP Multicast. Proceedings of the Advanced International Conference on Telecommunications, Guadeloupe, French Caribbean, February 2006. [15] P. Judge and M. Ammar. Security Issues and Solutions in Multicast Content Distribution: A Survey. IEEE Network, 17(1):30–36, January/February 2003. [16] M. Kellil, et al. Multicast Receiver and Sender Access Control and Its Applicability to Mobile IP Environments: A Survey. IEEE Communications Surveys and Tutorials, 7(2):46– 70, 2005. [17] S. Kent and R. Atkinson. IP Authentication Header. RFC 4302, December 2005. [18] S. Kent and K. Seo. Security Architecture for the Internet Protocol. RFC 4301, December 2005. [19] C. Metz. AAA Protocols: Authentication, Authorization, and Accounting for the Internet. IEEE Internet Computing, 3(6):75–79, December 1999. [20] R. Mukherjee and J. William Atwood. SIM-KM: Scalable Infrastructure for Multicast Key Management. Proceedings of Local Computer Networks, November 2004. [21] R. Mukherjee and J. William Atwood. XML Policy Representation for Secure Multicast. Proceedings of the IEEE SoutheastCon 2005 Conference, Fort Lauderdale, FL, April 2005. [22] C. Rigney, et al. Remote Authentication Dial In User Service (RADIUS). RFC 2865, June 2000. [23] W. Simpson. The Point-to-Point Protocol (PPP). RFC 1661, July 1994. [24] N. Sultana and J. William Atwood. Secure Multicast Communication: End User Identification and Accounting. Proceedings of the IEEE Canadian Conference on Electrical and Computer Engineering, Saskatoon, SK, May 2005. [25] R. Vida, et al. Multicast Listener Discovery Version 2 (MLDv2) for IPv6, RFC 3810, June, 2004.

7. Conclusion and future work We are not very far from the deployment of IP multicast to deliver content to the end users on a commercial basis. The IGMP-AC protocol will take the whole process one step forward. It will add minimum workload to the ARs without interfering the usual operation of the IGMPv3. At the same time, if the EAP is used, it will provide a flexible authentication framework. In future, we have to develop the incorporation of the EAP protocol with the IGMP-AC protocol. Moreover, a policy framework of the AAAS for the IGMP-AC architecture must be developed.

8. Acknowledgements J.W. Atwood acknowledges the support of the Natural Sciences and Engineering Research Council of Canada, through its Discovery Grants program. S. Islam acknowledges the support of Quebec Government through its FQRNT scholarship program and of Concordia University.

References [1] Local and Metropolitan Area Networks: Overview and Architecture. Institute of Electrical and Electronics Engineers, IEEE Standard 802, 1990. [2] B. Aboba, et al. Extensible Authentication Protocol (EAP). RFC 3748, June 2004. [3] B. Cain, et al. Internet Group Management Protocol, Version 3, RFC 3376, October, 2002. [4] P. Calhoun, et al. Diameter Base Protocol. RFC 3588, September 2003.

482