Subject: [MBONED] Proposal for authentication & authorization for multicast streams

From: "ALTOM, MARK W (ATTSI)" <[email-masked]>
Date: Tue, 18 Jan 2011 15:36:50 -0500

On April 19, 2010 AT&T submitted an IETF Patent Disclosure 
and Licensing Declaration with respect to this contribution 
concerning the authentication and authorization of 
end-users to receive multicast streams.

The following is a proposal for authentication and 
authorization of end-users to receive multicast streams.
Mark Altom
AT&T Labs

= authentication & authorization proposal begins here =

Additional functionality for secure content delivery is 
required for multicast over unicast because with unicast 
content delivery, there is a one-to-one relationship 
between the requesting end-point and a unicast stream 
from a unicast media server. With multicast content 
delivery, there is a one-to-many relationship between 
the multicast stream and the requesting end-point 
receivers.

The following outlines AT&T's solution to enforce
authentication and authorization of end-users for secure
delivery of multicast content where the content provider
and the network provider are separate entities.

The feature implementation requires an additional
service-related function at the network resource 
(multicast enabled router or AMT Relay) that enables 
the "join" for a multicast stream.  The additional 
function includes the delivery by service intelligence 
from the network provider of a secure (signed and 
encrypted) secondary token to the end-user.  This 
token is authenticated by the network resource that 
implements the join by using a shared key that only 
the network resource and multicast intelligence 
infrastructure have available.

CP = Third-party Content Provider
EU = End User
SI = Service Intelligence from the network provider
NR = Network Resource (multicast enabled router, AMT Relay)

For the discussion presented here, communication between
the end-user and the network resource could take place
over IGMP v3.  The message types are:
MembRpt:  IGMP v3 Membership Report
MembQry:  Membership Query

When showing IGMP messages, a semicolon is used to set 
off the new, nonstandard parameters.  For example, in 
a Membership Report message, these parameters could be 
carried in the Auxiliary Data Field associated with 
each multicast group.  In a Membership Query message, 
they could be carried as additional data outside of 
the IGMP message itself. (Changes might be required 
to RFC3376 and to the AMT Internet Draft to support 
these enhancements.)   

For IPv6, similar MLD messages would be used.

The End User communicates with the Content Provider and
the Service Intelligence using Transport Layer Security
(TLS).  TLS-protected messages are prefixed with TLS_,
but the notation does not distinguish between different 
TLS sessions.

The Content Provider (CP) has a secret/public key pair
for signing and digital-signature verification, denoted
SK_CP and VK_CP, respectively.  VK_CP is available to and
its authenticity verified by the other entities.

K_Enc and K_Auth are symmetric authorization keys 
shared by service intelligence and the network resource.

For efficiency reasons, the Service Intelligence (SI)
communicates with the Network Resource (NR) through the 
end user (EU).  This is done in a confidential and 
authenticated way using keys that they share.

The following is a step-by-step description of the
proposed protocol.

SK_CP=Secret Key           Symmetric keys shared by SI & NR
VK_CP=Public Key           K_Enc and K_Auth

===========                        ============
|         |                   (4a) |          |
|   CP    |                   (4b) |    SI    |
|         |                   (4c) |          |
|         |                   (4d) |          |
===========                   (4e) ============
    ^ |(2)                           ^  |   |
    | |               (3)            |  |   |
(1) | | ------------------------------  |   |(9)
    | | |                               |   |
    | | |                               |   |
    | | |                   (4f)        |   |
    | | |      --------------------------   |
    | | |      |                            |
    | V |      |                            V
===========    |                   ============
|         |<----                   |          |
|         |            (5)         |          |
|         |----------------------->|          |
|   EU    |                 (6b)   |    NR    |
|         |<-----------------------|          |
|         |----------------------->|          |
===========          (7b)          ============
    (7a)                             (6a)  (8)

(1) The end-user navigates to the content provider's Web
site and requests multicast content (e.g., live video).
The content provider's Web server determines whether or
not secure content delivery is required.  If secure 
content delivery is required, the Web server sends a 
request to the end-user for credentials (e.g., requests
a user ID and password or requests a credit card number).
The end-user supplies the requested credentials.  Combining
these possibly multiple steps, the end user sends to the
content provider a program request with an 
identification (ID) of the end user and the 
identification of the desired content
(ProgID):
EU=>CP
TLS_ProgReq(ID|ProgID)

(2) If the end-user's credentials are authenticated, the
content provider composes a secure token and
appends it to the streaming URL.  The content provider 
may use any algorithm and tracking mechanism for these
secure tokens (e.g., unique for every request, time
based, etc.).  The content provider returns to the end-user
a token signed by the content provider's private key,
SK_CP, where TransID is a transaction ID:
CP=>EU
TLS_ProgAuth(TransID|ID|ProgID|Sig_{SK_CC}(TransID|ID|ProgID))

(3) The end-user requests multicast content 
from the network provider's content delivery service
intelligence.  The request includes the signed token.
EU=>SI
TLS_GroupReq(<contents of TLS_ProgAuth message>)

(4) Content delivery service intelligence authenticates
the end user with the following steps.

(4a) The secure token is authenticated either at the 
service intelligence or by forwarding the credentials
to the content provider's authentication server.
Note, that up to this point, secure content delivery 
would be exactly the same for unicast and for multicast
content delivery.

(4b) Service intelligence maps the content request to a 
Multicast source and group (for Source Specific Multicast),
here denoted as GroupID.

(4c) Service intelligence generates an authorization key,
K_MSK.

(4d) Service intelligence generates the end-user's 
credentials for the multicast stream:
Cred = ID|GroupID|K_MSK|<period of validity>

(4e) Service intelligence encrypts and authenticates the
credentials (Cred) using the symmetric keys, K_Enc
and K_Auth:
Fwd_Cred = E_{K_Enc}(Cred)|MAC_{K_Auth}(E_{K_Enc}(Cred))

(4f) Service intelligence sends the credentials and 
forwardable representation to the end-user:
SI=>EU
TLS_GroupAuth(Cred|Fwd_Cred)

(5) The end-user sends a join request to the network
resource:
EU=>NR
MembRpt(GroupID; ID | Fwd_Cred | N2)
where N2 is a nonce.

(6) The network resource verifies the authenticity and
extracts (decrypts) the credentials from Fwd_Cred.

(6a) If the credentials are valid, the network resource 
caches the credentials.

(6b) The network resource sends to the end-user:
NR=>EU
MembQry(GroupID; ID | N3 | Auth1)
where, Auth1 = MAC_{K_MSK}(N2 | N3 | ID | GroupID)

(7) The end-user verifies AUTH1 using K_MSK.

(7a) The end-user uses its copy of the credentials to 
compute:
AUTH2 = MAC_{K_MSK}(N3 | N2 | ID | GroupID)

(7b) The end-user sends a response to the network
resource's challenge:
EU=>NR
MembRpt(GroupID; ID | AUTH2)

(8) The network resource uses its copy of the
credentials to verify AUTH2 and adds the 
end-user to the multicast group.

(9) Service intelligence periodically updates the
network resources with the shared keys:
SI=>NR
MPLS_KeyUpdate(K_Enc, K_Auth)

=============AAA proposal ends here ==========