Re: [MBONED] I-D Action:draft-ietf-mboned-multiaaa-framework-10.txt

"ALTOM, MARK W (ATTLABS)" <ma697r@att.com> Sun, 07 March 2010 14:59 UTC

Return-Path: <ma697r@att.com>
X-Original-To: mboned@core3.amsl.com
Delivered-To: mboned@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7FB33A8708 for <mboned@core3.amsl.com>; Sun, 7 Mar 2010 06:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqxKonbKU5iM for <mboned@core3.amsl.com>; Sun, 7 Mar 2010 06:59:04 -0800 (PST)
Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 1E48B3A7B89 for <mboned@ietf.org>; Sun, 7 Mar 2010 06:59:03 -0800 (PST)
X-VirusChecked: Checked
X-Env-Sender: ma697r@att.com
X-Msg-Ref: server-2.tower-161.messagelabs.com!1267973946!18090527!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [144.160.20.146]
Received: (qmail 19534 invoked from network); 7 Mar 2010 14:59:06 -0000
Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-2.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Mar 2010 14:59:06 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o27Ewu1V008127 for <mboned@ietf.org>; Sun, 7 Mar 2010 09:58:56 -0500
Received: from misout7msgusr7c.ugd.att.com (misout7msgusr7c.ugd.att.com [144.155.43.105]) by mlpd194.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id o27EwqOe008116 for <mboned@ietf.org>; Sun, 7 Mar 2010 09:58:52 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 07 Mar 2010 09:59:02 -0500
Message-ID: <3580159D7E3D824780C0B52AFC6D32E403264879@misout7msgusr7c.ugd.att.com>
In-Reply-To: <4B7D2DF6.5050201@lab.ntt.co.jp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [MBONED] I-D Action:draft-ietf-mboned-multiaaa-framework-10.txt
Thread-Index: Acqwk0RJVCy+fiJIRrO23E43w4U0wQNcp6jA
References: <20090805044502.1510F3A6DA3@core3.amsl.com> <4A791383.9040503@lab.ntt.co.jp> <3580159D7E3D824780C0B52AFC6D32E40326481F@misout7msgusr7c.ugd.att.com> <3580159D7E3D824780C0B52AFC6D32E403264824@misout7msgusr7c.ugd.att.com> <4B7D2DF6.5050201@lab.ntt.co.jp>
From: "ALTOM, MARK W (ATTLABS)" <ma697r@att.com>
To: Hiroaki Sato <satou.hiroaki@lab.ntt.co.jp>, mboned@ietf.org
Subject: Re: [MBONED] I-D Action:draft-ietf-mboned-multiaaa-framework-10.txt
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mboned>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Mar 2010 14:59:05 -0000

Hiroaki,

Please see below:

>
> Hiroaki,
> Here a few notes that we had on AAA and Admission Control Framework
for
> Multicasting (draft-ietf-mboned-multiaaa-framework-10).
>
> 1.  Is there a mechanism to prevent the sharing of authorization
(e.g.,
> sharing an S,G among end users)?
>

-> Our assumption is that the NSP identifies the user on L2 (such as 
-> VLAN or PPP) And it would be
-> problematic for NSP if more than two receivers for the same user 
-> accessed the same channel and one
-> is accepted but the other is rejected on L2 or L3.   Prevention of 
-> unauthorized content sharing could be
-> handled on the application layer by the CP: e.g. could distinguish
among 
-> receivers and distribute encryption
-> keys so that non-authorized receivers can not make use of the
content.
->
-> Do you have any ideas related to preventing the sharing of 
-> authorization?  Do you have any proposals of
-> how the NSP might effectively distinguish among receivers on the same

-> line (is it necessary)?

In investigating this issue, we uncovered some AT&T intellectual
property that addresses preventing the sharing of authorization 
among end-users.  We are working with AT&T legal to determine 
the licensing conditions for this intellectual property.  
We will be filling an intellectual property disclosure as 
soon as possible with the IETF.

Mark Altom
Andy Huang
Tom Imburgia
Pat McCrink
Han Nguyen
Doug Nortz
AT&T Labs
(Contact Mark Altom: ma697r@att.com; +1 732 420 9073)