Internet DRAFT - draft-atwood-mboned-mrac-pana
draft-atwood-mboned-mrac-pana
MBONED W. Atwood
Internet-Draft Concordia University/CSE
Intended status: Informational B. Li
Expires: April 30, 2015 Normal College of Shenzhen University
S. Islam
North South University
October 27, 2014
Receiver Access Control using PANA in IP Multicast
draft-atwood-mboned-mrac-pana-00
Abstract
Multicast Receiver Access Control must be enforced at both the
application level and at the network level. The control at the two
levels must be correlated, to ensure that only a legitimate group
member at the application level is permitted to join group at the
network level. We assume that authentication and authorization at
the application level are provided by Extensible Authentication
Protocol (EAP) exchanges. We describe how to use Protocol for
carrying Authentication for Network Access (PANA) to transport the
EAP packets in such a way that authententication and authorization
can be easily achieved at the network level and that the necessary
coordination is achieved.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Atwood, et al. Expires April 30, 2015 [Page 1]
Internet-Draft MRAC using PANA October 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Framework for Multicast Receiver Access Control . . . . . . . 3
2.1. PANA Role Description . . . . . . . . . . . . . . . . . . 3
2.2. MRAC Role Description . . . . . . . . . . . . . . . . . . 4
2.3. Framework . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Receiver Access Control Process in IP Multicast . . . . . . . 6
3.1. Handshake Phase . . . . . . . . . . . . . . . . . . . . . 6
3.2. Authentication and Authorization Phase . . . . . . . . . 6
3.3. Access Phase . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Re-authentication Phase . . . . . . . . . . . . . . . . . 7
3.5. Termination Phase . . . . . . . . . . . . . . . . . . . . 7
4. Cryptographic Keys . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
This document is part of a series that proposes a solution for
Multicast Receiver Access Control (MRAC). The reader is encouraged
to read the other documents in the series to gain insight into how
the various components of the solution interact.
A list of desirable properties for MRAC is presented in
[I-D.atwood-mboned-mrac-req]. A possible architecture for achieving
these properties is presented in [I-D.atwood-mboned-mrac-arch]. The
use of the keys described in this document by a secure version of
IGMP is presented in [I-D.atwood-pim-sigmp]. The corresponding use
of the keys for a secure version of MLD will be presented in draft-
atwood-pim-smld (not yet published). The required coordination of
keys and security associations among the End User(s) and the
router(s) on a network segment is described in [I-D.atwood-pim-gsam].
MRAC can be viewed at two levels: the application level and the
network level. At the application level, an End User will obtain
permission to subscribe to a group session. This permission will
Atwood, et al. Expires April 30, 2015 [Page 2]
Internet-Draft MRAC using PANA October 2014
contain at least two components: a description of how the session is
to be accessed and a certification that the End User is authorized to
access the session.
The certification will be presented at the application level. If it
is valid the End User will be permitted to join the group.
At the network level, the session descriptor will be used to issue
the network level join, which allows the session data to flow to the
End User device.
To prevent the End User from presenting an arbitrary session
descriptor, it is necessary to coordinate the application level join
and the network level join.
This draft describes how to achieve receiver access control at the
application level, using Protocol for carrying Authentication for
Network Access (PANA) [RFC5191] in IP multicast. The approach
uncouples the receiver access control from the process of joining a
multicast group. An End User is authenticated and authorized at the
application level while he/she shows his/her interest in a multicast
group at the network level.
This draft does not conflict with or intend to replace [RFC3740]
published by the Multicast Security (MSEC) working group. Encryption
for multicast data could also be implemented in addition to receiver
access control if the multicast application requires it.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC2119].
2. Framework for Multicast Receiver Access Control
2.1. PANA Role Description
There are four roles in a PANA environment: the PANA client (PaC),
the PANA authentication agent (PAA), the AAA server (AAAS) and the
enforcement point (EP). They are briefly described as follows:
PaC: It is the client implementation of PANA. A PaC runs on a device
operated by an End User that wishes to be authorized to perform some
action.
PAA: It is the server implementation of PANA. The PAA interacts with
a PaC to convey the EAP exchanges that are necessary for
Atwood, et al. Expires April 30, 2015 [Page 3]
Internet-Draft MRAC using PANA October 2014
authentication, authorization and accounting. The location of a PAA
may be one or more IP hops away from the PaCs that it is responsible
for.
AAAS: It is a server that handles authentication, authorization and
accounting service. The AAAS interprets the certification presented
by a PaC. According to the interpreted information, the AAAS
authenticates and authorizes a PaC to perform the action that it has
requested.
EP: It is the point in the network where the limitations on the
desired action are enforced.
2.2. MRAC Role Description
In the architecture described in [I-D.atwood-mboned-mrac-arch], the
End User is required to obtain a ticket from a multicast service
provider, which authorizes him/her to participate in the multicast
group. The ticket contains the certification and the session
descriptor mentioned in Section 1. The certification is carried as a
payload by EAP, and the EAP message is presented to the PaC for
transmission to the PAA. The certification will be (in most cases)
validated by the AAAS.
The PAA is responsible for managing the negotiation with a PaC,
usually with the help of the AAAS, that will authorize the End User
to join the multicast group. Once the authorization has been
achieved, the PAA is responsible for informing the EP that the access
to the multicast group can be permitted, and what its
responsibilities are with regard to accounting.
The AAAS is responsible for validating the certification, and
determining what accounting information must be collected related to
the received multicast traffic.
The EP is responsible for allowing authorized PaCs to receive the
multicast data while preventing others from doing so. In the case of
controlling access to multicast groups, the EP is actually the access
router (AR) that is one hop away from the PaC. In a multicast
network, the multicast routing protocol designates one AR, called the
Designated Router (DR), to join multicast groups on behalf of an End
User device. It is clear that the DR takes the role of the EP to
enforce the access to multicast groups. Since any AR is potentially
designated as a DR, all ARs are considered as (potential) EPs.
To distinguish the role of the EP in this MRAC case from the role of
EPs in general in the PANA environment, we will use the designator
Atwood, et al. Expires April 30, 2015 [Page 4]
Internet-Draft MRAC using PANA October 2014
mEP. In the simple case, there is only one mEP in the network
segment (on the DR) and the PAA resides on the DR.
2.3. Framework
------- PANA ------- API/AAA Protocol --------
| PaC |<--------->| PAA |<----------------->| AAAS |
------- ------- --------
^ ^
| |
| ------- |
GSAM +--->| mEP |<-----+ API/
and SIGMP ------- PAA-to-EP protocol
Figure 1: Receiver Access Control Framework
In an IP multicast network, the MRAC framework is as shown in
Figure 1. A PaC interacts with a PAA using PANA, which carries the
EAP authentication method to request the authorization for a
multicast group. A PAA consults a AAAS for authentication and
authorization of a PaC according to the EAP method carried in PANA.
Moreover a PAA also communicates with the pertinent mEPs to forward
the authorization attributes (mainly including the key derived from
the EAP authentication method) of a PaC to the pertinent mEPs if a
PaC is authorized. The mEPs establish IPsec SAs [RFC4301] with the
authorized PaC according to the authorized attributes using a
protocol called group security association management (GSAM)
[I-D.atwood-pim-gsam]. A PaC then shows its interest in a multicast
group to its mEP using the Secure IGMP (SIGMP) protocol
[I-D.atwood-pim-sigmp] in an IPv4 network or using the Secure MLD
(SMLD) protocol in an IPv6 network. The SIGMP packet or the SMLD
packet is secured by an IPsec SA established during the GSAM
negotiations. The mEP will join the multicast group on behalf of the
authenticated and authorized PaCs and then send the multicast data to
them. Usually the PaC is not allowed to forward the multicast data
to any other device. The way to prevent forwarding is out of scope
for this document.
If the PAA and the AAAS reside in the same device, an API is used to
communicate between the PAA and the AAAS. Otherwise, a AAA protocol
is usually needed, e.g., Diameter. Similarly, if the PAA and the mEP
reside in the same device, an API is used to communicate between the
PAA and the mEP. Otherwise, a PAA-to-EP protocol is needed.
Possible candidates include, but are not limited to, COPS, SNMP,
Diameter, etc.
Atwood, et al. Expires April 30, 2015 [Page 5]
Internet-Draft MRAC using PANA October 2014
This draft shows how to share the authorization attributions between
a PaC and its mEP. The creation of the IPsec SAs and the protocols
SIGMP and SMLD are out-of-scope for this draft. These topics are
discussed in [I-D.atwood-pim-gsam], [I-D.atwood-pim-sigmp] and draft-
atwood-pim-smld (not yet published) respectively.
3. Receiver Access Control Process in IP Multicast
As defined in [RFC5191], a PANA session has five phases. In our MRAC
system, the five phases are explained as follows.
3.1. Handshake Phase
The handshake phase is triggered when a PaC receives the request to
establish IPsec SAs in its local GSAM instance. In this phase, a PaC
sends a PANA-Client-Initiation message to the PAA to initiate a PANA
session. In MRAC, only PaC may initiate a PANA session rather than
both a PAA and a PaC as described in [RFC5191]. A PaC may use its
local configuration or DHCP to discover its PAA.
3.2. Authentication and Authorization Phase
Immediately following the handshake phase, a PAA and a PaC interact
using both PANA-Auth-Request message and PANA-Auth-Answer message in
the authentication and authorization phase. The EAP method is
carried in the PANA message. The certification that the PaC
possesses is encapsulated in one of the EAP packets and is delivered
from a PaC to a PAA. A PAA will consult the AAAS using an API or a
AAA protocol for authentication and authorization based on the EAP
method and then convey the result to a PaC.
On successful authentication, a PANA Master Session Key (PANA MSK)
becomes known to the PAA and the PaC as a result of the EAP
exchanges. At the network side, the PAA must combine the PANA MSK
with EP-specific information to produce the PaC-EP Master Key (PEMK),
which is then forwarded (securely) to the pertinent mEP(s) using an
API (when the PAA and the mEP are located in the same device) or a
PAA-to-EP protocol (when the PAA and mEP are located in different
devices). The rules for doing this are specified in [RFC5807]. The
mEP must, in turn, combine this PEMK with group-specific information
to produce the Multicast Session-Specific Key (MSSK), which will be
used in GSAM to establish an IPsec SA to permit the network-level
joining of the End User. On the End User device, the PaC must store
the PANA MSK itself, since it does not know the identification of its
mEP at this time. On the End User device, the work to calculate the
MSSK based on the PANA MSK is assigned to GSAM. The details of how
to calculate the PEMK and the MSSK will be shown in Section 4.
Atwood, et al. Expires April 30, 2015 [Page 6]
Internet-Draft MRAC using PANA October 2014
In order to achieve strong security, the EAP method carried in the
PANA messages is required to provide the function of dynamic key
exchange. Here the EAP-FAST method is recommended.
At the end of this phase, both a PaC and its mEP have calculated the
keys (PaC calculates PANA MSK and mEP calculates MSSK) for
authentication and authorization at the network layer. For the
network layer join, the PaC will use an SIGMP message protected by an
IPsec SA to show its interest in a specific group that has been
authorized at the application layer. The details of the network
layer interactions may be found in [I-D.atwood-pim-sigmp] and
[I-D.atwood-pim-gsam].
3.3. Access Phase
On the one hand, a PaC and a PAA use the PANA message to test peer
liveness in a PANA session. On the other hand, the multicast data is
distributed from the mEP to the network on which the PaC resides.
3.4. Re-authentication Phase
The re-authentication phase is triggered when the access lifetime
specified as the PANA session lifetime needs to be extended. In this
phase, the EAP authentication carried in PANA messages is re-executed
between a PaC and a PAA.
Upon successful re-authentication, access control re-enters the
access phase. The lifetime of the PANA session is extended.
Moreover a PAA notifies the pertinent mEPs to extend the lifetime of
the authentication attributes of the PaC. However, if re-
authentication fails, the PANA session must be terminated. Moreover,
a PAA notifies mEPs to revoke the access authorization of a PaC.
3.5. Termination Phase
Either a PaC (i.e., disconnect indication) or a PAA (i.e., session
revocation) may initiate the termination of the access authorization
at any time. On the one hand, they use PANA-Termination-Request and
PANA-Termination-Answer message exchanges to terminate the PANA
session between them. On the the other hand, a PAA uses an API or a
PAA-to-EP protocol to notify mEPs to revoke the access authentication
of a PaC.
4. Cryptographic Keys
At the end of the authentication and authorization phase, a PaC and a
PAA share the same secret key (PANA MSK). A PAA will derive a
separate PaC-EP-Master-Key (PEMK) as follows [RFC5807]:
Atwood, et al. Expires April 30, 2015 [Page 7]
Internet-Draft MRAC using PANA October 2014
PEMK = prf+(MSK,"IETF PEMK"|SID|KID|mEPID)
Here, "|" means concatenation of different fields and prf+ is a
pseudo-random function defined in [RFC5996]. "IETF PEMK" is the
ASCII code representation, SID is a four-octet Session Identifier,
KID is associated with the MSK and mEPID is the identifier of the
mEP.
A PaC may be authorized to join more than one multicast group in one
PANA session. For each multicast group, a separate Multicast Group-
Specific Key (MSSK) is derived from the PEMK using the following
method:
MSSK = HMAC-SHA-1(PEMK,"MSSK"|MSSInf|SID|KID|mEPID).
Here, "MSSK" is the ASCII code representation, SID is a four-octet
Session Identifier, KID is associated with the PEMK and mEPID is the
identifier of the mEP. MSSInf is the multicast group-specific
information.
5. IANA Considerations
This document has no actions for IANA.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", RFC 5191, May 2008.
[RFC5807] Ohba, Y. and A. Yegin, "Definition of Master Key between
PANA Client and Enforcement Point", RFC 5807, March 2010.
6.2. Informative References
[I-D.atwood-mboned-mrac-arch]
Atwood, B., Li, B., and S. Islam, "Architecture for IP
Multicast Receiver Access Control", draft-atwood-mboned-
mrac-arch-01 (work in progress), July 2014.
Atwood, et al. Expires April 30, 2015 [Page 8]
Internet-Draft MRAC using PANA October 2014
[I-D.atwood-mboned-mrac-req]
Atwood, B., Islam, S., and B. Li, "Requirements for IP
Multicast Receiver Access Control", draft-atwood-mboned-
mrac-req-01 (work in progress), July 2014.
[I-D.atwood-pim-gsam]
Atwood, B. and B. Li, "Group Security Association
Management Protocol", draft-atwood-pim-gsam-00 (work in
progress), July 2014.
[I-D.atwood-pim-sigmp]
Atwood, B. and B. Li, "Secure Internet Group Management
Protocol", draft-atwood-pim-sigmp-01 (work in progress),
July 2014.
[RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security
Architecture", RFC 3740, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
"Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
5996, September 2010.
Authors' Addresses
William Atwood
Concordia University/CSE
1455 de Maisonneuve Blvd, West
Montreal, QC H3G 1M8
Canada
Phone: +1(514)848-2424 ext3046
Email: william.atwood@concordia.ca
URI: http://users.encs.concordia.ca/~bill
Bing Li
Normal College of Shenzhen University
Nanhai Ave 3688
Shenzhen, Guangdong 518060
China
Phone: +86(0755)26558364
Email: libingice@szu.edu.cn
Atwood, et al. Expires April 30, 2015 [Page 9]
Internet-Draft MRAC using PANA October 2014
Salekul Islam
North South University
House 80, Road 8/A, Mirza Golam Hafiz Road
Dhanmondi, Dhaka 1209
Bangladesh
Email: salekul@northsouth.edu
Atwood, et al. Expires April 30, 2015 [Page 10]
