Multicast Receiver Access Control Using PANA

Multicast Receiver Access Control Using PANA Salekul Islam

J. William Atwood

Department of Electrical Engineering & Computer Science North South University, Dhaka, Bangladesh Email: [email protected]

Computer Science & Software Engineering Department Concordia University, Montreal, Quebec, Canada Email: [email protected]

At the network layer, the session descriptor will be used to issue the network layer join, which allows the session data to flow to the end user host. This network layer join is done using the Internet Group Management Protocol (IGMP) for IPv4, or the Multicast Listener Discovery (MLD) protocol for IPv6. This paper discusses only the IGMP-based solution, although the ideas apply equally for MLD. To prevent the end user from presenting an arbitrary session descriptor, it is necessary to coordinate the application layer join and the network layer join. Two possible ways of achieving the necessary coordination are:

Abstract—Access control for multicast groups requires enforcement at both the application layer and at the network layer. Previous work has shown how to achieve this enforcement by extending the network layer join protocol (IGMP). In this paper, we show how to achieve the enforcement by using PANA and derived session keys. This solution has the advantage that no modification to IGMP is required. Index terms—Multicast security; Receiver access control; IGMP; PANA; EAP

I.

I. INTRODUCTION

Many new applications (e.g., video streaming, Internet TV, multi-player games, distance learning, video conferencing) rely on one-to-many or many-to-many communications [1], where one or more sources are sending data to multiple receivers. Network Service Providers (NSP) could save a significant amount of bandwidth by using IP multicast for these types of applications. However, multicast, with all its advantages, is not widely deployed yet, although it was standardized by the Internet Engineering Task Force (IETF) many years ago. We have seen significant progress in the last decade in the area of multicast security, which is composed of two orthogonal planes: the data plane and the control plane. The data plane protects multicast data and the control plane secures multicast routing protocol messages. One example for data plane control is the Group Security Architecture [2] developed by the MSEC Working Group (WG) at the IETF. The security of link-local control-plane messages for Protocol Independent Multicast-Sparse Mode (PIM-SM) is addressed in [3]. However, large scale deployment of multicast has not yet materialized, which suggests the existence of a hole in multicast security, and that is lack of access control over the multicast groups. Access control is used in this paper to mean authentication, authorization and accounting (AAA) functionalities for both sender(s) and receivers of a multicast group, although we are limiting our focus to receiver access control in this paper. Access control can be viewed at two levels: the application layer and the network layer. At the application layer, an end user will obtain permission to join a group session by purchasing that permission from a Merchant. He/she will be given a ticket, which describes how the session is to be accessed and his/her rights relative to that session. This rights certification will be presented at the application layer, and if it is valid the necessary decryption keys will be supplied.

© ICCIT 2012

1. Carry the application layer rights certification in an extended network layer join exchange; 2. Provide separate application layer join and network layer join functions, along with a method for explicitly coordinating them. In [4] and [5] we have explored the approach of extending the network layer join operation to carry the certification. This approach requires that a new version of IGMP be deployed, which is difficult to achieve operationally. In this paper, we show how to achieve the same coordination by using the Protocol for carrying Authentication for Network Access (PANA) and derived session keys. This approach has the advantage that no modification to IGMP (or MLD) is necessary. The rest of the paper is organized as follows: Section II gives background information on our access control architecture, IGMP, PIM-SM, Extensible Authentication Protocol (EAP) and Protocol for Carrying Authentication for Network Access (PANA). Section III defines the problem that we are addressing. Section IV gives a brief outline of our previous solution. Section V proposes our new solution. Section VI compares the attributes of the two solutions. Section VII concludes our paper. II.

BACKGROUND

In this section we present the participant access control architecture we have developed for IP multicast followed by the related protocols including IGMP, EAP and PANA. A.

Access control architecture The architecture shown in Figure 1 was proposed in [6]. A number of parties that participate in a multicast session, either before the session or during it, have been identified.

816

Group Owner

Updates Database Participants Database AAAS AAA Protocol CR

Content Provider

Financial Institution

While IGMP is the protocol used between an end user host and its AR, a multicast routing protocol (typically PIM-SM [8]) is used to build the data distribution tree among the core routers and the ARs. An IGMP join message will cause the grafting of one or more new edges (if there are no existing clients on the same AR for that group) and an IGMP leave message will cause the data distribution tree to be pruned if this is the last client on the AR. The extent of possible damage due to a forged IGMP report message depends on the type of the message accepted by the AR. In the IGMPv3 specification [7], a list of attacks has been summarized that might be generated due to forged IGMP messages. The consequences of these attacks are wastage of the local subnet’s bandwidth and of the resources of the hosts and the routers. IGMPv3 recommends the use of IP security (IPsec) [9] with Authentication Header (AH) [10] to authenticate IGMP messages. The suggested security features of IGMPv3 are unable to enforce the access control for the IGMP report messages. It should be noted that the attacks due to forged report messages could only be prevented by implementing access control and not by message authentication alone [11].

AAA Protocol

AR1 / NAS

IGMP AAA info

NSP AR2 / NAS Authenticate & Authorize CP IPsec SA

CR

End user

Fig. 1. Access control architecture for multicast participants [6]

The content provider offers the product to be delivered to the multicast group. The end user receives the content. The Network Service Provider (NSP) delivers the data, making use of Access Routers (ARs), Core Routers (CRs), one or more instances of a AAA Server (AAAS) and a Network Access Server (NAS) associated with each AR. We will assume that the ability of the end user to pay for services will be certified by a financial institution. The group owner is responsible for the creation and overall activities of the group. Participant access control can be further divided into receiver and sender access controls. Receiver access control will be implemented at the end users’ end. AR2 will receive and process the IGMP messages and the messages carrying AAA information. It will also act as a NAS by communicating with the AAAS. It is assumed that the group owner had supplied the user authentication information or AAA information when the user purchased the service. Hence, each end user would be authenticated and authorized by the one-hop AR before allowing him/her to join a secured group. Sender access control will be deployed at the sender’s end, where AR1 will authenticate and authorize the content provider with the proper interaction of the AAAS. On successful authentication and authorization, an IPsec SA will be established between the Content Provider and AR1 to cryptographically authenticate each packet before forwarding it to the multicast distribution tree.

C. EAP In recent years, the specific aspects of (end user) authentication and authorization have been delegated to EAP [12], which is a versatile framework that facilitates the use of multiple authentication methods, such as pre-shared secret, one time password, public key authentication, etc. EAP is also useful for managing access at the application layer, for cases where authorization to access the network does not automatically include access to a particular application or service. In particular, EAP procedures can be adapted for use in multicast-based applications, to authenticate the users, to authorize them, and to account for their group-level activity. EAP does not run directly over the IP layer. The mechanism for carrying the EAP packets will be discussed in Sections IV and V. EAP supports multiple authentication mechanisms. The EAP runs between an authenticator and a peer, where the authenticator can act as a pass-through, and a back-end authentication server (or EAP server) may be connected with the authenticator. The actual authentication will be performed by the back-end server. The pass-through authenticator is nothing but a NAS and the back-end server is a AAAS. In such an environment, the EAP will be used by the end user (or 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. EAP has not been developed for a specific authentication mechanism. It is an authentication framework to provide some common functions and a negotiation of the desired authentication mechanism. Such a mechanism is called an EAP method. Although EAP is standardized in RFC 3748 [12], the specification only supports some ―legacy methods‖.

B. IGMP and PIM-SM Internet Group Management Protocol (IGMP) [7] has been standardized by the IETF for IPv4 systems (host or router) to inform the neighboring router(s) about the multicast group memberships of these systems. IGMP performs three main operations:  A system sends a join message (through a Membership Report Message) when it wants to join a multicast group or some specific sources of a group.  A system sends a leave message (through a Membership Report Message) when it wants to unsubscribe from a multicast group.  A router periodically checks (through a Membership Query Message) which multicast groups are of interest to the hosts that are directly connected to that router.

817

To satisfy present needs, a number of EAP methods have been developed, which have better security properties and provide more flexibility. A justification for using the method EAPFAST in our application may be found in [13].

unsecured, and the information on the legitimacy of the group membership is not network layer information. We must therefore provide a way to use application layer information to (securely) control access to a network layer group.

D. PANA The IETF has standardized Protocol for carrying Authentication for Network Access (PANA) [14], a network access authentication protocol that carries EAP authentication methods (encapsulated inside EAP packets) between a client node and a server in the access network. To establish an indirect coupling between the PANA/EAP-based authentication and IGMP join/leave operations, the secret key (or a key derived from that secret key) established during PANA session could be used to protect IGMP messages (following the security guidelines of the IGMPv3 [7] specification). PANA is a network access authentication protocol that works as a link-layer protocol for transmitting EAP information. PANA carries EAP authentication methods (encapsulated inside EAP packets) between a client node and a server in the access network. The PANA framework [15], comprised of four functional entities, is shown in Figure 2. The PANA Client (PaC) residing on a requesting node (e.g., an end host) interacts with the PANA Authentication Agent (PAA) in the authentication process using the PANA protocol [14]. The server implementation of PANA is the PAA, which consults an Authentication Server (AS) for authentication and authorization of a PaC. If the PAA is separate from the AS, a AAA protocol (e.g., Diameter) will be used for their communication. The PAA resides on a node that is typically called a NAS in the access network. The AS is a conventional back-end AAAS that terminates the EAP and the EAP methods.

IV.

In our previous studies ([18] and [19]), we designed an overall access control architecture for secure and accountable multicasting that provides sender and receiver access control by incorporating the AAA framework into the exiting multicast model. Receiver or user access control is implemented at the receivers’ end, i.e., between the users and the one-hop access router (AR). To permit coupling network level forwarding control with group-level access control, and since the present standard of the IGMP protocol does not make any provision of carrying AAA information, we also developed an extension to IGMP, which we called Internet Group Management Protocol with Access Control (IGMPAC) [4]. The extension provides a method to encapsulate EAP [12] packets, i.e., to carry group level authorization data. While the IGMP-AC proposal is not flawed from the technical point of view, it requires a redesign of the IGMPv3 protocol while the older version of IGMP (i.e., IGMPv2 [20]) is still being used in many networks. Given the slow uptake of IGMPv3, getting acceptance of what would essentially be IGMP version 4 is not likely to be easy. V.

PROPOSED SOLUTION

This paper proposes an alternative to the IGMP-AC that satisfies the following goals as well: 1.

2. 3.

Fig. 2. PANA framework

4.

The Enforcement Point (EP) allows (blocks) data traffic of authorized (unauthorized) clients. When the PAA and EP reside on the same node, they use an API for communication, otherwise, a protocol (e.g., SNMP) is required. A secure association protocol (e.g., IKEv2 [16]) is required to run between the PaC and the EP to establish an IPsec [9] Security Association (SA) [17], which may provide integrity protection, data origin authentication, replay protection and optional confidentiality protection. III.

PREVIOUS SOLUTION

The proposed model retains the foundation of IGMPAC: coupling end user authentication and authorization with joining multicast group. However, the new solution is distinct from IGMP-AC in transporting authentication/authorization tokens outside IGMP. The proposed solution does not make any modification to the existing IGMP specification. The solution is compatible with our access control architecture [4] and also with the ongoing effort in the IETF MBONE Deployment (MBONED) Working Group [21]. The solution is based on commonly used and standard protocols (e.g., EAP) to increase the chance of its future adoption by the standardization bodies (e.g., IETF).

A. Receiver access control without disturbing IGMP One of the major weaknesses of the existing multicast service model is the IGMP protocol, which fails to provide any sort of receiver access control. However, IGMP is the only means to join/leave (not considering the silent leave) an IP multicast group. Therefore receiver access control must be enforced by the access routers during the join/leave operation (which is performed by the IGMP protocol) of a multicast group. Therefore, receiver access control mechanisms should be deployed at the access routers, which will enforce a mandatory authentication and authorization of end users before joining or leaving a group through IGMP. Therefore, each time an end

PROBLEM STATEMENT

Our goal is to ensure that an end user that issues an IGMP join message has in fact obtained permission to join the group. Unfortunately, the basic IGMP join message is itself

818

user sends a state-change join/leave message, it will trigger an authentication session between the end user and the access router. If a current-state message comes from an end user who had not been authenticated and authorized previously, the message will be dropped by the access router. The problem we are addressing in this paper is composed of two closely related sub-problems: deploying receiver access control and protecting a multicast group from the vulnerabilities raised due to the unprotected IGMP reception states. The problem could be solved by performing access control (i.e., authenticating and authorizing an end user) each time she wants to join/leave a group. The proposed model transports any authentication/authorization tokens outside IGMP, while the foundation of IGMP-AC, i.e., coupling end user authentication and authorization with joining/leaving the multicast group, is retained. One way to establish that coupling is to produce a secret key during the end user authentication and later incorporate that key to authenticate IGMP messages.

A PANA session consists of five phases. In the following we have explained how the entities will behave in our architecture during these phases: 1) Handshake phase: The PaC (multicast host), on receiving a request from the upper layer to join a multicast group while no PANA session had been completed yet, initiates a PANA session by sending a PANA-Client-Initiation message to the PAA (access router). 2) Authentication and authorization phase: Immediately following the handshake phase, EAP packets, carrying EAP method messages, will be exchanged between the PaC and the PAA. The PAA conveys the result of authentication and authorization to the PaC at the end of this phase. On successful authentication, both the AS and the PaC calculate the same secret key, which is forwarded to the PAA by the AS. 3) Access phase: Next, the PaC and the PAA derive the same multicast session-specific key from the previously generated secret key (during the PANA authentication phase). Some multicast session specific information (e.g., (*, G) for Group-Specific or (S, G) for Group-andSource-Specific join/leave) could be incorporated in deriving the multicast session key. Later, this session key is used in establishing a Security Association (SA) between the PaC (multicast receiver) and the EP (access router). The SA authenticates IGMP messages sent from the multicast router following the security guidelines of the IGMPv3 specification. 4) Re-authentication phase: If PANA re-authentication is required, this phase will trigger a EAP re-authentication, which returns to the access phase upon successful reauthentication. 5) Termination phase: The receiver (e.g. on receiving multicast leave request from the upper layer) or the AR (e.g. the receiver’s authorized access has been expired or revoked) may choose to discontinue the access service at any time. At the end of this phase, the AR will gather accounting data for the receiver and communicate these data to the AAAS (using Diameter) for updating the receiver’s account.

B. Use of PANA in our model AAA Server

Access Router/NAS

Multicast Receiver

EP

Host/PaC

PAA

AS

Request from upperlayer to join multicast group first time If no PANA session had been completed yet PANA-Client-Initiation PANA-Auth-Request(EAP-Request) PANA-Auth-Answer(EAP-Response)

PANA-Auth-Request(Key-Id, AUTH) PANA-Auth-Answer(Key-Id, AUTH)

Diameter-EAP-Request (EAP-Response) Diameter-EAPAnswer (EAP-Success, Authorization AVP) Calculate necessary keys Diameter(secret key)

Calculate multicast session-specific key Calculate necessary keys

API (multicast session-key)

Establish SA using Session-key. IGMP Report

C. Different key generations The successful operation of our model depends on different key generation in different stages. Figure 4 presents the key generation steps performed by the end host. The end host maintains a long-term security relationship with the AS (AAAS), and this will be maintained by the PANA authentication session. When the end host receives a request from upper-layer to join a multicast group from the first time, it initiates a PANA session. At the end of the PANA session, the end host and the AAAS generates the same Master Session Key (MSK). No new PANA session will be required for the subsequent requests to join other multicast groups. The MSK can be exported to the PAA (or AR) using a AAA protocol [22]. On receiving the MSK the PAA generates separate 64 octets PaC-EP Master Key (PEMK) for

API (change reception state)

Change in reception state

Fig. 3. Using PANA to authenticate IGMP messages

The PANA framework resembles our proposed architecture, and the functionalities PANA provides match our requirements. How PANA will be accommodated in our architecture is shown in Figure 3. The proposed model implements a PANA Client (PaC) inside the multicast receiver. Both the PAA and the Enforcement Point (EP) (which performs the actual access control) are implemented inside the IGMP access router. The PAA consults a back-end Authentication Server (AS) for authentication and authorization of a PaC.

819

case the authentication token could not be included in IKE MSSK, no UAUTH will be present. Note that both the end host and the EP will calculate the same PEMK and IKE MSSK. At this moment, the end host and the EP open an IKEv2 session for mutual authentication using IKE MSSK, and eventually establish an IPsec SA, which is used for cryptographic protection of IGMP messages.

Request from upper-layer to join a multicast group from the first time

Any Master Session Key (MSK) had been generated in previous PANA session?

yes

D. Authenticating IGMP messages Depending on the required security services (i.e., secrecy, integrity, authentication, replay protection, etc.) the appropriate SA protocol (i.e., ESP [24] or AH [10] protocol) will be used by the network administrator. By incorporating MSSInf in calculating the IKE MSSK, a direct coupling between the multicast session and the established IPsec SA (between the end host and the EP/AR) is ensured. Thereby, a separate SA will be established for each multicast group, and IGMP messages addressing a specific multicast group should be sent through that SA. The access router will never process an IGMP message if it is not sent through the proper SA or if it fails to be authenticated.

no Complete PANA session, calculate MSK.

Any PEMK had already been generated?

yes

no

Calculate PaC-EP Master Key (PEMK) from MSK

Calculate IKE MulticastSession-Specific Key (IKE MSSK) from PEMK

Complete an IKE seesion with the EP and establish an IPsec SA

VI.

COMPARISON WITH IGMP-AC

A comparison of the proposed solution based on PANA and derived session keys with our previous solution based on extending IGMP is shown in Table I.

Send IGMP join report to the AR/EP through the SA

VII. CONCLUSION

Fig. 4. Key generations by the host

We have presented a new solution to the problem of enforcing receiver access control for multicast groups. This solution separates the application layer and network layer enforcement actions, while providing a simple means to coordinate them so that the network layer enforcement is based on application layer criteria. We believe that the new solution is easier to manage, and much more likely to be accepted by the IETF community.

each EP [23]. One way of calculating this key is, PEMK = prf+(MSK,"IETF PEMK"|SID|KID|EPID) Here, ―|‖ means concatenation of different fields and prf+ is a pseudo-random function defined in [16]. "IETF PEMK" is the ASCII code representation, SID is a four-octet Session Identifier, KID is associated with the MSK and EPID is the identifier of the EP. The end host may join more than one multicast groups. For each multicast group, a separate IKE Multicast Session-Specific Key (IKE MSSK) must be derived from the PEMK using the following method [17]:

ACKNOWLEDGEMENTS This research was supported by North South University and by the Natural Sciences and Engineering Research Council of Canada, through its Discovery Grants program. REFERENCES [1]

IKE MSSK = HMAC-SHA-1(PEMK,"IKE MSSK"| [UAUTH]|MSSInf|SID|KID|EPID).

[2]

Here, "IKE MSSK" is the ASCII code representation, SID is a four-octet Session Identifier, KID is associated with the PEMK and EPID is the identifier of the EP. MSSInf is the multicast session-specific information. UAUTH, an optional field, is user authentication information supplied by the Group Owner (see Figure 1) as authentication token. Some advanced user authentication techniques (e.g., PKI based authentication) may preclude the incorporation of the authentication token (supplied by the Group Owner) in calculating IKE MSSK. In

[3]

[4] [5]

[6]

820

B. Quinn and K. Almeroth, ―IP Multicast Applications: Challenges and Solutions,‖ RFC 3170, Sep. 2001. T. Hardjono, and B. Weis, ―The Multicast Group Security Architecture,‖ RFC 3740, Mar. 2004. J. William Atwood, S. Islam and M. Siami, ―Authentication and Confidentiality in PIM-SM Link-local Messages,‖ RFC 5796, Mar. 2010. S. Islam and J. William Atwood, ―Multicast Receiver Access Control by IGMP-AC,‖ Computer Networks, vol. 53, no. 7, pp. 989–1013, 2009. ——, ―The Internet Group Management Protocol with Access Control (IGMP-AC),‖ in Proc. of 31st IEEE Conference on Local Computer Networks, Tampa, Florida, USA, Nov. 2006, pp. 475–482. S. Islam, Participant Access Control in IP Multicasting. PhD Thesis, Concordia University, Montr´eal, Canada, 2008.

TABLE I COMPARISON BETWEEN IGMP WITH PANA AND IGMP-AC Issue

IGMP with PANA

IGMP-AC

Protocol used

Depends on PANA for transporting EAP packets, IKEv2 for establishing IPsec SA and SA protocols (AH or ESP) for cryptographic services.

Depends on IGMP-AC for transporting EAP packets. No IPsec SA has been established.

Modification in IGMP

The IGMP messages and protocols states remain unchanged. However, IGMP messages are sent through the appropriate SA.

Protecting IGMP message

All IGMP Membership Report messages (sent by the end host) are authenticated and protected by the IPsec SA. Membership Report messages are responsible for IGMP state change at the ARs.

A number of new messages and protocol states have been added. Thus, a new version of IGMP named IGMP-AC has been introduced. None of the IGMP messages are authenticated or protected.

Coupling user authentication and IGMP

All IGMP Report messages are protected by IPsec SA, which is established using IKE MSSK (and user authentication token when UAUTH is absent). Thus, the user’s authentication token supplied by the group owner is needed to establish the SA, which indirectly couples the user authentication with the IGMP group the Report message is requesting to join/leave. Fully compatible with the existing version of IGMP, i.e., IGMPv3.

End user authentication information (i.e., EAP method messages) is transmitted inside IGMP messages. Thus, user authentication is directly coupled with IGMP join/leave Report messages.

PANA session will be completed once while individual IPsec SA (which requires separate IKEv2 session) will be established for each multicast group. Number of times–authentication session will be completed–is proportional to the number of multicast groups the end host joins, which usually should be a small number By sending IGMP messages through SAs, some extra processing will be introduced.

User authentication through EAP methods will be triggered and completed by each time a end user sends IGMP join/leave Report message. Thus, a quite large number of user authentication should be needed. However, no extra processing is needed for IGMP messages.

Compatibility with present IGMP Complexity

[7]

[8]

[9] [10] [11]

[12] [13]

[14]

[15]

[16]

A new version of IGMP is needed, which makes IGMP-AC less attractive to the network service providers.

[17] M. Parthasarathy. (2005) ―PANA Enabling IPsec based Access Control‖. Internet Draft, Work in progress. [Online]. Available: http://tools.ietf.org/id/draft-ietf-pana-ipsec-07.txt [18] S. Islam and J. William Atwood, ―A Framework to Add AAA Functionalities in IP Multicast,‖ in Proc. of the Advanced International Conference on Telecommunications, Guadeloupe, French Caribbean, Feb. 2006. [19] J. William Atwood, ―An Architecture for Secure Multicast,‖ in Proc. Of 32nd Annual Conference on Local Computer Networks, Dublin, Ireland, Oct. 2007, pp. 73–78. [20] W. Fenner, ―Internet Group Management Protocol, Version 2,‖ RFC 2236, Nov. 1997. [21] T. Hayashi, H. He, H. Satou, H. Ohta and S. Vaidya. (2010) Requirements for Multicast AAA coordinated between Content Provider(s) and Network Service Provider(s). Internet Draft, Work in progress. [Online]. Available: http://tools.ietf.org/id/draft-ietfmbonedmaccnt-req [22] B. Aboba, D. Simon and P. Eronen, ―Extensible Authentication Protocol (EAP) Key Management Framework,‖ RFC 5247, Aug. 2008. [23] Y. Ohba and A. Yegin, ―Definition of Master Key between PANA Client and Enforcement Point,‖ RFC 5807, Mar. 2010. [24] S. Kent, ―IP Encapsulating Security Payload (ESP),‖ RFC 4303, Dec. 2005.

B. Cain, S. Deering, I. Kouvelas, B. Fenner and A. Thyagarajan, ―Internet Group Management Protocol, Version 3,‖ RFC 3376, Oct. 2002. B. Fenner, M. Handley, H. Holbrook and I. Kouvelas, ―Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),‖ RFC 4601, Aug. 2006. S. Kent and K. Seo, ―Security Architecture for the Internet Protocol,‖ RFC 4301, Dec. 2005. S. Kent and R. Atkinson, ―IP Authentication Header,‖ RFC 4302, Dec. 2005. B. Coan, H. He and B. Weis. (2002) IGMP Security Problem Statement and Requirements. Working Group Meeting of Group Security (GSEC), Co-located with IETF 53. [Online]. Available: http://www.securemulticast.org/GSEC/gsec3 ietf53 SecureIGMP1.pdf B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson and H. Levkowetz, ―Extensible Authentication Protocol (EAP),‖ RFC 3748, Jun. 2004. M. Parham and J. William Atwood, ―Validation of Security for Participant Control Exchanges in Multicast Content Distribution,‖ in Proc. of the 9th Annual Conference on Privacy, Security and Trust (PST), Montreal, Quebec, Canada, Jul. 2011, pp. 156–163. D. Forsberg, Y. Ohba, B. Patil, H. Tschofenig and A. Yegin, ―Protocol for Carrying Authentication for Network Access (PANA),‖ RFC 5191, May 2008. P. Jayaraman, R. Lopez, Y. Ohba, M. Parthasarathy and A. Yegin, ―Protocol for Carrying Authentication for Network Access (PANA) Framework,‖ RFC 5193, May 2008. Y. N. C. Kaufman, P. Hoffman and P. Eronen, ―Internet Key Exchange (IKEv2) Protocol,‖ RFC 5996, Sep. 2010.

821