A Framework to Add AAA Functionalities in IP Multicast Salekul Islam J. William Atwood Department of Computer Science and Software Engineering Concordia University, Montréal, Canada {salek_is, bill}@cse.concordia.ca

Abstract Multicasting, as an operational paradigm, has not been widely adopted until now, in spite of the advantages of its lower resource utilization and bandwidth conservation. This is due to lack of control over the multicast groups, which implies that the Network Service Provider has no simple mechanism for generating revenue from IP multicast. The Authentication, Authorization and Accounting (AAA) protocols are being used very successfully to ensure revenue generation by controlling access to network resources in unicast communication. AAA protocols can be used for multicast based applications to authenticate the end users, to establish their authority to participate in the group, and to keep a record of their group activity. In this paper, we have proposed a framework to deploy AAA protocols in such uses. The edge-router will be the perfect place to implement the AAA client functions. A modification to the Internet Group Management Protocol (IGMP) is also required to carry end user authentication data.

1. Introduction In the Internet, the number of users and various applications are growing exponentially. Many applications, previously available only to a limited number of power users with high-end workstations, are starting to become mainstream applications in the PC world. Video-conferencing, collaborative applications, etc., are very common applications today. Many of the new applications rely on one-to-many or many-to-many communications, where one or more sources are sending data to multiple receivers. A very large amount of bandwidth can be saved by using IP multicast for these types of applications. Moreover, the Network Service Providers (NSP) can generate significant revenue by deploying multicast. However, to ensure that non-paying parties cannot access the data, the

multicast stream must be secured. Multicasting has suffered from various security breaches from the very inception of its evolution. Secured multicast is a complex issue to achieve, and sometimes it is not worth the cost. There are two orthogonal criteria to satisfy for making multicast communication secure: protecting multicast data by applying encryption and protecting multicast routing protocol control messages. For secure data transmission, a great advancement, the Group Security Architecture [1] has been developed by the MSEC [2] Working Group of the IETF. Security of a multicast routing protocol is dealt with individually for a specific protocol. For example, security of PIM-SM [3] link-local messages is addressed in [4]. All of these efforts to provide security will be in vain without commercial use of multicasting. The key to establishing a revenue stream from multicast clients lies in authenticating the end users, and establishing their authority to participate in the group. Prior to delivering any service to a client, the client's ability to pay for it should be checked. This implies that there has to be a strong relationship to AAA [5] functions, and various e-commerce interactions. The solution must be fully distributed to handle hundreds or thousands of participants, who may be geographically scattered in a wide area. The rest of the paper is organized as follows: section 2 will define the problem we want to solve, section 3 will present existing methods, the proposed architecture will be explained in section 4, and finally section 5 will be the conclusion and the future work that we plan.

2. Problem statement A multicast routing protocol builds the distribution tree among the core routers. The end user (receiver) or host informs the multicast edge-router of its interest in receiving multicast traffic destined to a particular group using IGMP [6] (MLD [7] in case of IPv6). Securing routing protocol messages will not prevent an illegal

Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) 0-7695-2522-9/06 $20.00 © 2006 IEEE

host from sending an IGMP Report message, which may cause unnecessary extension of the distribution tree. The result will be the wastage of bandwidth and CPU cycles, and the risk of DoS attacks. Applying endto-end data encryption techniques will not eradicate these problems since a host can always send a report message. The classical architecture of IP multicast allows any host to send data to a multicast group without a prior join to that group. An attacker can take advantage of this and deteriorate the usage of the network by sending many bogus packets to a group. It is clear that, data encryption techniques will not solve this problem either. The present architecture of IP multicast needs to be extended to achieve both receiver and sender access control. Here “access control” has two impacts: authentication and authorization. A receiver must be authenticated before allowing him to receive any data and a sender must be authenticated before permitting him to send any data. Authorization defines the rights and services the authenticated end user is allowed to have. This implies that successful authentication is a prerequisite for authorization. For example, in a multicast group, only a few members may have the permissions to both send and receive data, and the rest of the members will join as a receiver only and will not be allowed to send any multicast data. According to [8], the lack of accounting capability is one of the major reasons that multicast based applications are well behind in comparison with those based on unicast. In multicasting, the Network Service Providers (NSP) and the Content Providers (CP) may wish to record the client behavior of all the members (e.g., connecting to the server, starting reception, terminating reception, etc.). The CP will use the resources of the NSP to deliver its content or service to the end user. There are two types of accounting issues. The NSP is interested to keep track of the use of network resources whereas the CP wants to record the use of delivered content by the end users.

2.1. AAA in unicast AAA protocols (e.g., RADIUS [9]) have been designed to control network access by the NSPs, and are being used very successfully. AAA framework, as shown in Figure 1, has two components: AAA server and AAA client. The AAA server is attached to the network and it serves as a central repository for storing and distributing the AAA information. The Network Access Server (NAS) acts as the point of entry into the network, and contains an AAA client. The NAS

collects authentication data of an end user and forwards these data to the AAA server, which checks its database and returns an “accept” or “reject” response to the AAA client. AAA server Authentication

Authorization

Accounting

Network

NAS AAA client

End User

Figure 1: AAA framework in unicast

2.2. Where to implement AAA functionalities During unicast communication, to control network access, the entry point of a network is the obvious choice to implement AAA client behaviors. In case of IP multicast, the point of implementation of AAA client behavior is difficult to specify. In unicast, here is a one-to-one relation between the sender and the receiver(s), whereas in multicast, the sender has no idea about the presence of the receivers, and who the actual receivers are. In the middle of the transmission, intermediate routers replicate multicast data packets if needed. The receivers use IGMP/MLD to inform the edge router at the receiver side to join a group. As a result, only the edge router has some sort of way to learn the presence of a receiver in the network to which it is attached. This is clear that the only suitable point to implement AAA client behaviors is the edge router of the receiver's side. The edge router of the network to which the sender is connected will be the best place for sender authentication and other AAA functions (i.e., authorization and accounting). However, the present IGMP/MLD Join message does not carry the identity of the user or the host.

3. Present solutions and their limitations AAA issues are not addressed well in IP multicast by the researchers. We have found a few attempts that meet our requirements. Among these, the End User Identification and Accounting (EUIA) [10] system deploys AAA protocols for user authentication, accounting and host identification. It proposed some

Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) 0-7695-2522-9/06 $20.00 © 2006 IEEE

Table 1: Summary of different approaches regarding AAA issues Approach

IGMP Version

User Authentication

Authorization

Accounting

Remarks

EUIA

IGMPv3

Flexible authentication

Yes

Yes

- Provides host identification - No protocol exists for communication between NAS and Policy Server

IGAP

IGMPv2

Password (mandatory) or CHAP

Yes

Yes

- Sends plaintext password - Pertinent to IGMPv2

IGMPv3 to multicast access

IGMPv3

By using host IP address only

Uses source filtering of IGMPv3

No explicit mechanism

Authentication using RADIUS

IGMPv2

CHAP

No

No

IGMP key establishment

IGMPv2

Access token signed by digital signature

No

No

Upload auth. info by IGMPv3

IGMPv3

No specific scheme

No

No

modifications in IGMPv3 [6]. The Internet Group Membership Authentication Protocol (IGAP) [11] provides all the functionalities of IGMPv2 [12] with the addition of user authentication and accounting. It suffers from a serious threat due to its use of plaintext passwords for authentication. Recently, a new multicast architecture has been presented in [13], where a centralized Multicast Manager (MM) has been introduced. The Leaf Network Routers or the edgerouters receive IGMPv3 join messages and relay these messages to the MM. The “source filtering” option in IGMPv3 has been used to control the access of the receivers. An architecture that uses CHAP and deploys RADIUS [9] has been proposed in [14] to authenticate both receiver and sender. This approach and all other subsequent ones that we are going to discuss do not provide any authorization and accounting features. Multicast receiver access control based on a one-time token is presented in [15]. This token is digitally signed, and distributed by the Key Server (KS) to the users. This token contains a symmetric key called the IGMP-key that is used by the receiver to authenticate IGMP Report message. The KS also distributes the same token to the multicast router. An Internet Draft (ID) to modify IGMPv3 to authenticate Join message when needed [16] is a work in progress. The goal of this I-D is to protect IGMP reception states from any malicious host or end user by authenticating IGMP messages. A summary of the different approaches regarding AAA issues is presented in Table 1. We have

- Does not support any advanced authentication scheme - Single point of failure - Provides sender authentication also - Does not provide authorization and accounting mechanism - A Group Key Management protocol must be in place beforehand - Adds overhead to end host and multicast routers - Supports source filtering feature - Authentication data is sent in raw bits only once from host to router - Not applicable for CHAP

listed only the methods that are similar to our research goal. A number of researchers have proposed end user authentication in conjunction with group key management, where authentication took place during group key distribution. They have not considered the use of IGMP at all. A complete list of receiver and sender access control mechanisms can be found in [17, 18]. We can conclude this section with the following essential findings: 1. Only a few models deal with authorization and accounting issues in IP multicast. 2. Sender authentication is overlooked most of the time. 3. Some of the methods are based on IGMPv2, which has already been outdated by IGMPv3. 4. Most of the architectures are confined to a specific authentication mechanism, and they do not support a wide range of authentication schemes. 5. The unique advantage of IGMPv3 over IGMPv2 is “source filtering”, which is absent in most cases. 6. Only one of the methods has successfully used AAA protocol (RADIUS). The first two, EUIA and IGAP, intend to use the AAA protocols, but have not presented any detail in the architectural level.

4. Proposed model The problem of adding AAA functionalities is very complex and distributed in nature, and also composed of different protocols and entities. In the literature, we

Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) 0-7695-2522-9/06 $20.00 © 2006 IEEE

have found only a few efforts to define the domain of the problem or to solve a piece of the whole puzzle. In this section, we shall explain some assumptions that we have made before presenting our proposed architecture. Next, the proposed architecture will be described in detail.

7. We are assuming that user authentication data will be sent inside the IGMP/MLD packet.

4.2. Architecture Our proposed architecture is presented in Figure 2, which has four major components: the Content Provider (CP), the Network Service Provider (NSP), the AAA server and the end users. The CP will feed multicast data through the provider-edge router of the NSP. End users will receive that data from the useredge router(s) of the NSP. A connection must exist between these two routers. We have listed different

4.1. Assumptions We have made the following assumptions for successful deployment of the whole system: 1. The Content Provider (CP) and the Network Service Provider (NSP) are different entities and are managed by different authorities.

Registration (Possibly offline)

CP

Update user database

Content Server

NSP Provider Edge

User Database

AAA Servers AAA Protocol

Information Server User Edge/ NAS

AAA Client

User Authentication Data IGMP/MLD

Client End Users Figure 2: Different components of proposed architecture

2. The CP and the NSP trust each other and have agreed to share the revenue on some basis. 3. The user database that resides in the AAA servers is accessible by the CP, and the CP can update that database. 4. The CP has outsourced the end user authentication and delegated the NSP to perform authentication on its behalf. 5. The client component of the AAA protocol is implemented in the edge router of the receiver side. That means, the edge router will act as NAS here. 6. At least one of the AAA protocols can be used for content or service access control as well.

steps from group creation to user joining that should take place. Though we have presented different steps one-by-one, some of them may take place in parallel and the order may be violated. Session Announcement: The CP will announce the schedule of the session. For example, CrickInfo will live multicast the upcoming test cricket match of Bangladesh vs. England from London for five days from 1st to 5th of January 2006. CrickInfo will advertise this live telecast on their website. Registration: The end users must register themselves to the CP prior to the start of the session. The registration may be online using the Internet or may be

Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) 0-7695-2522-9/06 $20.00 © 2006 IEEE

offline (e.g., by phone, fax, etc.). During registration, the end user’s credit will be checked and the user will indicate the type of service he/she is requesting for. For example, an end user is willing to watch the cricket match for the last two days, whereas the other may want to watch for all five days. Account Creation: At the end of the registration process, the CP will create the user's account. The CP will forward the authentication information to the end user. For example, it may be the user's name and the password or the keys of a digital signature. Depending on the nature of the service, authorization information will be created for a newly created account. In our cricket match example, if the user pays for the last two days, he will be allowed (authorized) to view (receive multicast data) for that period only. Updated User Database at AAA Servers: Next, the CP will add the new user account and authorization information of the end user to the user database of the AAA server. IGMP/MLD Join Message: An end user will send its identity and authentication information to the NAS (edge-router of NSP) through an IGMP/MLD join message. User Authentication and Authorization: The NAS will receive the IGMP/MLD join message and extract end user authentication information from this message. The NAS will communicate with the AAA server using an AAA protocol and send authentication information. The AAA server will check the user database and inform the NAS of authentication success or failure. For a successful authentication, the AAA server will send authorization information for that specific user. The NAS will notify the end user of its authentication status. If the user is both authenticated and authorized for the service he/she requested, the NAS (edge-router) will trigger the multicast routing protocol (e.g., PIMSM) to send a join message to its upstream router. The multicast data distribution tree will be expanded up to the edge-router and multicast data will be forwarded to the end user through the edge-router. Accounting: The NAS informs the AAA servers of the start and end of accounting. The NAS will gather accounting information for a session of an end user and at the end of the session will forward the gathered data to the AAA servers. The AAA servers will update the user database to store accounting data. The CP can access this database anytime. The whole model can be divided into different independent pieces and can be developed in modular fashion as follows: 1. Modification of IGMPv3 to carry end user authentication information.

2. Defining router behavior to extract user authentication information from an IGMP message and send this to the AAA server using an AAA protocol. 3. Examining AAA protocols to use in content access control and modify AAA protocols if required. 4. Addressing different e-commerce issues related to registration of end users in CP and update of user database in AAA server.

4.3. IGMP modification All the attempts we have found to modify IGMP have their own shortcomings. We have listed a set of requirements for a successful modification: 1. IGMP messages will carry end user authentication information. This authentication process should support all sorts of authentication -- from simple password based authentication to complex certificate based authentication. 2. IGMP version 3 is the current standard designed by the IETF. Our modification will be based on IGMPv3 and must support “source filtering” as well. 3. The modified IGMP will not disrupt the usual function of IGMPv3 and end user authentication must be optional. 4. We shall try to add the least functionality and add minimal workload to the edge routers and hosts. 5. Authentication is a costly process in terms of CPU cycles and bandwidth. We shall therefore try to minimize the number of times an end user has to send authentication information to the edge-router.

4.4. AAA Protocol in content access control RADIUS and the next generation AAA protocol, Diameter [19], have been developed for network access control. All of these protocols have been developed to authenticate and authorize an end user before granting access to a network resource. Moreover, it is also used to keep track the usage of network resources by an end user. There is a similarity between the use of network resources and the use of service or data content by an end user. At that time, an end user will use both network resources and some specific content. AAA protocols have not been deployed yet to authenticate and authorize end user for content use. It is our strong belief that AAA protocols can be used in such scenarios. Specially, in multicasting, where a large number of end users will join a multicast group, an AAA protocol with some modifications will be the most appropriate one.

Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) 0-7695-2522-9/06 $20.00 © 2006 IEEE

4.5. E-commerce issues During registration, an end user will prove his/her identity and credit (e.g., by credit card number) to the CP, and confirm the service or content he/she wants to purchase. Through an appropriate e-payment protocol the e-transaction will take place, and the end user will receive authentication information (e.g., usernamepassword, key for digital signature, etc.). Different ecommerce issues (e.g., authentication, non-repudiation, money atomicity, etc.) should be addressed for the registration process. Moreover, the CP and the AAA server will authenticate mutually and should trust each other. Finally, a security policy should be enforced through which the CP will be able to update the user database that resides in the AAA server.

5. Conclusion and future work In this paper, a comprehensive framework has been presented to add end user or receiver authentication, authorization, and accounting to the existing multicast architecture. The problem has been identified in detail. What is missing and what issues need to be resolved have been determined. An extensive survey on existing methods and solutions has been carried out. We have observed some significant limitations of these solutions and summarized them with our critical remarks. All other architectures we have found handled the problem partially, and our proposed architecture is the first one (to our knowledge) that addresses every related issue in the deployment of AAA functionalities in multicast. In future, we have to extend our architecture to provide sender authentication and host identification features. The Host Identification Protocol [20] allows a host to identify itself to the edge router. Host identification has not been studied elaborately in IP multicast. We have already identified different pieces of the architecture, which must now be developed independently, and merged to develop the whole system. Using this process, we have to add functionality to some of the existing protocols (e.g., IGMPv3, Diameter). At the end of the development of each piece, we will have to demonstrate the interoperability of them, and the correctness, effectiveness and performance of our proposed architecture.

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 an FQRNT scholarship and of Concordia University.

References [1] T. Hardjono and B. Weis, “The Multicast Group Security Architecture”, RFC 3740, March 2004. [2] Multicast Security (msec) Working Group, IETF. http://www.ietf.org/html.charters/msec-charter.html. [3] B. Fenner, et al., “Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (Revised)”, Internet Draft, work in progress. [4] Salekul Islam and J. William Atwood, "Security Issues in PIM-SM Link-local Messages", LCN 2004, Tampa, FL, November 2004. [5] C. Metz, “AAA Protocols: Authentication, Authorization, and Accounting for the Internet”, IEEE Internet Computing, December 1999. [6] B. Cain, et al., “Internet Group Management Protocol, Version 3”, RFC 3376, October 2002. [7] R. Vida, et al., “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” RFC 3810, June 2004. [8] T. Hayashi, et al., “Accounting, Authentication and Authorization Issues in Well Managed IP Multicasting Services”, Internet Draft, work in progress. [9] C. Rigney, et al., “Remote Authentication Dial In User Service (RADIUS)”, RFC 2865, June 2000. [10] N. Sultana and J.W. Atwood, “Secure Multicast Communication: End User Identification and Accounting”, IEEE Canadian Conference on Electrical and Computer Engineering, Saskatoon, SK, May 2005. [11] T. Hayashi, et al., “Internet Group membership Authentication Protocol (IGAP)”, Internet Draft, work in progress. [12] W. Fenner, “Internet Group Management Protocol, Version 2”, RFC 2236, November 1997. [13] B. Hilt and J. Pansiot, “Using IGMPv3 to manage multicast access”, 4th Conference on Security and Network Architectures, Batz sur Mer, France, June 2005 [14] N. Ishikawa, et al., “An Architecture for User Authentication of IP Multicast and Its Implementation,” IEEE/APAN Internet Workshop, Japan, February 1999. [15] T. Hardjono and B. Cain, “Key Establishment for IGMP Authentication in IP Multicast”, IEEE European Conference on Universal Multiservice Networks, CERF, Colmar, France, September 2000. [16] H. He, et al., “Upload Authentication Information Using IGMPv3”, Internet Draft, work in progress. [17] M. Kellil, et al., “Multicast Receiver and Sender Access Control and Its Applicability to Mobile IP Environments: A Survey”, IEEE Communications Surveys and Tutorials, Second Quarter, vol. 7, no. 2, 2005, pp. 46-70. [18] P. Judge and M. Ammar, “Security Issues and Solutions in Multicast Content Distribution: A Survey”, IEEE Network, January/February 2003, pp. 30-36. [19] P. Calhoun, et al., “Diameter Base Protocol”, RFC 3588, September 2003. [20] R. Moskowitz and P. Nikander. “Host Identity Protocol Architecture,” Internet Draft, work in progress.

Proceedings of the Advanced International Conference on Telecommunications and International Conference on Internet and Web Applications and Services (AICT/ICIW 2006) 0-7695-2522-9/06 $20.00 © 2006 IEEE