Subject: Security-Requirements: alternatives?

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 22 Jun 2006 15:37:03 +0100

Haitham, I-D Authors, List,

One of the issues we need to be clear about in preparing for a WG 
adoption of the security requirements I-D is the possible alternatives 
that have been proposed/implemented in other standards organisations.

Could you summarise the methods that have been proposed for MPEG-2 
transmission networks that provide equivalent L2 security functions, and 
say which to your knowledge has actually have been implemented in systems?

Thanks,

Gorry

---

From: "Allison, Art" <[email-masked]>
Date: Thu, 22 Jun 2006 15:02:27 -0400

See below. 

_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

The National Association of Broadcasters is a trade association that
advocates on behalf of more than 8,300 free, local radio and television
stations and also broadcast networks before Congress, the Federal
Communications Commission and the Courts.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, June 22, 2006 2:09 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Security-Requirements: alternatives?

 Hi Gorry,

This issue has been addressed in the security draft.   Some text has
been added to section 5.1 to this effect: 

Basically, in practice there are not many L2 security systems for MPEG
transmission networks.  Two major examples are:

* Conditional access for digital TV broadcasting is one example that
exists today.  This system is optimised for TV broadcast services only,
and is not suitable for IP packet transmissions and difficult to
interwork with ULE.
AA> See ATSC A/70A. I strongly disagree with assertion about the
difficulty to interwork with ULE. The ULE can be put in a virtual
channel in the ATSC system and the standard directly applied.

* Some other L2 security systems are specified in standards such the MPE
for DVB system . However, MPE security incomplete and there are no known
implementations of such security system.

* For DVB-S2 Generic Streams, where IP encapsulation could be similar to
ULE. The authors believe that ULE security format can be used for
Generic Streams as well.

We would like to ask the ipdvb WG if anybody knows any other existing L2
security systems that might be suitable for ULE.

AA> See ATSC A/70A for ULE when sent in conformance with ATSC Standards.

Haitham
----

Dr. Haitham S. Cruickshank

Lecturer
Communications Centre for Communication Systems Research (CCSR) School
of Electronics, Computing and Mathematics University of Surrey,
Guildford, Surrey GU2 7XH, UK 

Tel: +44 1483 686007 (indirect 689844)
Fax: +44 1483 686011
e-mail: [email-masked]
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]] 
Sent: 22 June 2006 15:37
To: Cruickshank HS Dr (CCSR); [email-masked]; Iyengar S Mr (CCSR);
[email-masked]
Subject: Security-Requirements: alternatives?

Could you summarise the methods that have been proposed for MPEG-2
transmission networks that provide equivalent L2 security functions, and
say which to your knowledge has actually have been implemented in
systems?

Thanks,

Gorry

---

From: <[email-masked]>
Date: Sat, 24 Jun 2006 10:00:33 +0100

Hi Art,
 
Many thanks for your input:
 
********************
*******************
 
I completely agree with you that  A/70A (Conditional Access System for Terrestrial Broadcast, Revision A) can interwork with ULE, where encryption is based on PIDs, which sometimes means bundling many IP flows with one PID.  In our draft (ULE requirements), we aim for more fine grain security and securing every IP flow individually and try to re-use existing work in the IETF on key management.
 
Accidentally reading through A/70A, it looks much better than the  DVB Conditional Access.  I personally do not have much faith in DVB Conditional Access (DVB CA): You might probably know that DVB CA has been surrounded by controversy for many years due to the spread of counterfeit smart cards.  For example, in late 1999, Italy was flooded with cheap counterfeit cards that enabled viewers use Canal Plus for free.  In March 2002 Canal Plus Group filed a  lawsuit against NDS Group, accusing it of cracking its digital television smart cards and putting the confidential information on the Internet.  Since then, I have not seen any major changes in DVB CA to cater for these challenges. 
 
Haitham
----
Dr. Haitham S. Cruickshank 
Lecturer 
Communications Centre for Communication Systems Research (CCSR) 
School of Electronics, Computing and Mathematics 
University of Surrey, Guildford, Surrey GU2 7XH, UK 

________________________________

From: [email-masked] on behalf of Allison, Art
Sent: Thu 22/06/2006 20:02
To: [email-masked]; [email-masked]; Iyengar S Mr (CCSR); [email-masked]
Subject: RE: Security-Requirements: alternatives?

See below.

_____________
Art Allison

-----Original Message-----

 Hi Gorry,

Haitham
----

Lecturer

-----Original Message-----
From: Gorry Fairhurst [mailto:[email-masked]]
Sent: 22 June 2006 15:37
To: Cruickshank HS Dr (CCSR); [email-masked]; Iyengar S Mr (CCSR);
[email-masked]

Thanks,

Gorry

---

From: "Allison, Art" <[email-masked]>
Date: Mon, 26 Jun 2006 11:15:57 -0400

Perhaps I misunderstood, but I thought that the approach chosen in ULE
was for there to be one logical channel per PID ["...locate a specific
ULE Stream (i.e., the PID value of the TS Logical Channel that carries a
ULE Stream)"] as contrasted with multiple logical channels carried in
MPEG-2 TS packets with a single PID.
 
The discovery of 'logical channels' carried in IP packets delivered  via
MPEG-2 TS packets with a single PID appears to not be standardized.
Perhaps this falls into the general case of any IP delivery. If so,
separate security access for each distinct element a functionality that
A/70A would not provide.
 
But then it seems to me to not be different than the functionality
provided for by existing RFCs for security of arbitrary content
delivered using IP encapsulation, i.e., https: and such
 
If it is general purpose IP, then it seems to me that the proposal
should make a case that the current RFCs fail to meet the requirements
asserted to be needed.  If it is 'logical channel' protection, then it
is different that the general case.
 
But perhaps I have not been following this in adequate depth - and I
waste your time,
If so - no need to attempt to educate me.
Regards, 
Art

_____________ 
Art Allison 
Director, Advanced Engineering 
Science & Technology 
National Association of Broadcasters 
1771 N Street, NW 
Washington, D.C. 20036 
Phone: 202.429.5418 
Fax: 202.777.4981 
[email-masked] <mailto:[email-masked]>  

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
	Sent: Saturday, June 24, 2006 5:01 AM
	To: [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
	Subject: RE: Security-Requirements: alternatives?

	Hi Art,

	********************
	* Conditional access for digital TV broadcasting is one example
that
	exists today.  This system is optimised for TV broadcast
services only,
	and is not suitable for IP packet transmissions and difficult to
	interwork with ULE.
	AA> See ATSC A/70A. I strongly disagree with assertion about the
	difficulty to interwork with ULE. The ULE can be put in a
virtual
	channel in the ATSC system and the standard directly applied.
	*******************
	 
	I completely agree with you that  A/70A (Conditional Access
System for Terrestrial Broadcast, Revision A) can interwork with ULE,
where encryption is based on PIDs, which sometimes means bundling many
IP flows with one PID.  In our draft (ULE requirements), we aim for more
fine grain security and securing every IP flow individually and try to
re-use existing work in the IETF on key management.
	 
	Accidentally reading through A/70A, it looks much better than
the  DVB Conditional Access.  I personally do not have much faith in DVB
Conditional Access (DVB CA): You might probably know that DVB CA has
been surrounded by controversy for many years due to the spread of
counterfeit smart cards.  For example, in late 1999, Italy was flooded
with cheap counterfeit cards that enabled viewers use Canal Plus for
free.  In March 2002 Canal Plus Group filed a  lawsuit against NDS
Group, accusing it of cracking its digital television smart cards and
putting the confidential information on the Internet.  Since then, I
have not seen any major changes in DVB CA to cater for these challenges.

	Haitham
	
	----

	From: [email-masked] on behalf of Allison, Art
	Sent: Thu 22/06/2006 20:02
	To: [email-masked]; [email-masked]; Iyengar S Mr
(CCSR); [email-masked]
	Subject: RE: Security-Requirements: alternatives?

	See below.

	_____________
	Art Allison
	
	The National Association of Broadcasters is a trade association
that
	advocates on behalf of more than 8,300 free, local radio and
television
	stations and also broadcast networks before Congress, the
Federal
	Communications Commission and the Courts.
	
	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On
	Behalf Of [email-masked]
	Sent: Thursday, June 22, 2006 2:09 PM
	To: [email-masked]; [email-masked];
[email-masked];
	[email-masked]
	Subject: RE: Security-Requirements: alternatives?
	
	 Hi Gorry,
	
	This issue has been addressed in the security draft.   Some text
has
	been added to section 5.1 to this effect:
	
	Basically, in practice there are not many L2 security systems
for MPEG
	transmission networks.  Two major examples are:
	
	* Conditional access for digital TV broadcasting is one example
that
	exists today.  This system is optimised for TV broadcast
services only,
	and is not suitable for IP packet transmissions and difficult to
	interwork with ULE.
	AA> See ATSC A/70A. I strongly disagree with assertion about the
	difficulty to interwork with ULE. The ULE can be put in a
virtual
	channel in the ATSC system and the standard directly applied.
	
	* Some other L2 security systems are specified in standards such
the MPE
	for DVB system . However, MPE security incomplete and there are
no known
	implementations of such security system.
	
	* For DVB-S2 Generic Streams, where IP encapsulation could be
similar to
	ULE. The authors believe that ULE security format can be used
for
	Generic Streams as well.
	
	We would like to ask the ipdvb WG if anybody knows any other
existing L2
	security systems that might be suitable for ULE.
	
	AA> See ATSC A/70A for ULE when sent in conformance with ATSC
Standards.
	
	Haitham
	----

	Lecturer
School

	
	-----Original Message-----
	From: Gorry Fairhurst [mailto:[email-masked]]
	Sent: 22 June 2006 15:37
	To: Cruickshank HS Dr (CCSR); [email-masked]; Iyengar S Mr
(CCSR);
	[email-masked]

	One of the issues we need to be clear about in preparing for a
WG
	adoption of the security requirements I-D is the possible
alternatives
	that have been proposed/implemented in other standards
organisations.
	
	Could you summarise the methods that have been proposed for
MPEG-2
	transmission networks that provide equivalent L2 security
functions, and
	say which to your knowledge has actually have been implemented
in
	systems?
	
	Thanks,
	
	Gorry

---

From: <[email-masked]>
Date: Wed, 28 Jun 2006 15:54:52 +0100

Hi again Art,
 
May be we should get the terminology right first. 
 
A typical usage is for the ULE Stream sent on a single PID to carry unicast or multicast packets with several different IP destination addresses (and therefore corresponding different MAC addresses). The aim of ULE security is therefore to secure the L2 conversations between each Receiver and the Encapsulator that generates the corresponding ULE stream.  
 
Also it is possible to do a more fine grain security (per IP flow), depending on the security association which is part of a key management system.
Haitham 

----

From: [email-masked] on behalf of Allison, Art
Sent: Mon 26/06/2006 16:15
To: [email-masked]
Subject: RE: Security-Requirements: alternatives?

Perhaps I misunderstood, but I thought that the approach chosen in ULE was for there to be one logical channel per PID ["...locate a specific ULE Stream (i.e., the PID value of the TS Logical Channel that carries a ULE Stream)"] as contrasted with multiple logical channels carried in MPEG-2 TS packets with a single PID.
 
The discovery of 'logical channels' carried in IP packets delivered  via MPEG-2 TS packets with a single PID appears to not be standardized.  Perhaps this falls into the general case of any IP delivery. If so,  separate security access for each distinct element a functionality that A/70A would not provide.
 
But then it seems to me to not be different than the functionality provided for by existing RFCs for security of arbitrary content delivered using IP encapsulation, i.e., https: and such
 
If it is general purpose IP, then it seems to me that the proposal should make a case that the current RFCs fail to meet the requirements asserted to be needed.  If it is 'logical channel' protection, then it is different that the general case.
 
But perhaps I have not been following this in adequate depth - and I waste your time,
If so - no need to attempt to educate me.
Regards, 
Art

_____________ 
Art Allison 

The National Association of Broadcasters is a trade association that advocates on behalf of more than 8,300 free, local radio and television stations and also broadcast networks before Congress, the Federal Communications Commission and the Courts.

	From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
	Sent: Saturday, June 24, 2006 5:01 AM
	To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
	Subject: RE: Security-Requirements: alternatives?

	Hi Art,

	********************

	 
	Haitham
	
	----

	See below.

	_____________
	Art Allison

	-----Original Message-----
	From: [email-masked] [mailto:[email-masked]] On
	Behalf Of [email-masked]
	Sent: Thursday, June 22, 2006 2:09 PM
	To: [email-masked]; [email-masked]; [email-masked];
	[email-masked]
	Subject: RE: Security-Requirements: alternatives?
	
	 Hi Gorry,

	

	

	Haitham
	----

	Lecturer

	
	-----Original Message-----
	From: Gorry Fairhurst [mailto:[email-masked]]
	Sent: 22 June 2006 15:37
	To: Cruickshank HS Dr (CCSR); [email-masked]; Iyengar S Mr (CCSR);
	[email-masked]
	Subject: Security-Requirements: alternatives?

	
	
	Thanks,
	
	Gorry

---

From: "Allison, Art" <[email-masked]>
Date: Wed, 28 Jun 2006 12:35:43 -0400

Thanks.
I agree that to secure some of the flows carried by packets with a
single PID and not others; one could not apply A/70A.  
Art
_____________
Art Allison
Director, Advanced Engineering
Science & Technology
National Association of Broadcasters
1771 N Street, NW
Washington, D.C. 20036
Phone: 202.429.5418
Fax: 202.777.4981
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Wednesday, June 28, 2006 10:55 AM
To: [email-masked]
Subject: RE: Security-Requirements: alternatives?

Hi again Art,

A typical usage is for the ULE Stream sent on a single PID to carry
unicast or multicast packets with several different IP destination
addresses (and therefore corresponding different MAC addresses). The aim
of ULE security is therefore to secure the L2 conversations between each
Receiver and the Encapsulator that generates the corresponding ULE
stream.  
 
Also it is possible to do a more fine grain security (per IP flow),
depending on the security association which is part of a key management
system.
Haitham 

----

 

 
But perhaps I have not been following this in adequate depth - and I
waste your time, If so - no need to attempt to educate me.
Regards,
Art

_____________
Art Allison

	Hi Art,

	********************

	Haitham
	
	----

	See below.

	_____________
	Art Allison

	-----Original Message-----
	
	 Hi Gorry,

	

	

	Haitham
	----

	Lecturer

	
	-----Original Message-----
	From: Gorry Fairhurst [mailto:[email-masked]]
	Sent: 22 June 2006 15:37
	To: Cruickshank HS Dr (CCSR); [email-masked]; Iyengar S Mr
(CCSR);
	[email-masked]

	
	
	Thanks,
	
	Gorry

---

From: <[email-masked]>
Date: Thu, 29 Jun 2006 15:23:26 +0100

Hi again Art,
 
Many thanks Art for your opinion and input about ATSC security system (ATSC A/ 70A).  
 
We will provide an update for the next rev of the requirements I-D that clarifies this point and to include refs to how ATSC provides its security services.
 
Would Art be willing to help check the paragraphs correctly reflect ATSC's specs.

Many thanks
Haitham
 
----

From: [email-masked] on behalf of Allison, Art
Sent: Wed 28/06/2006 17:35
To: [email-masked]
Subject: RE: Security-Requirements: alternatives?

Thanks.

-----Original Message-----

Hi again Art,

----

_____________
Art Allison

        Hi Art,

        ********************

        Haitham
       
        ----

        See below.

        _____________
        Art Allison

        -----Original Message-----
       
         Hi Gorry,

       

       

        Haitham
        ----

        Lecturer

       
        -----Original Message-----
        From: Gorry Fairhurst [mailto:[email-masked]]
        Sent: 22 June 2006 15:37
        To: Cruickshank HS Dr (CCSR); [email-masked]; Iyengar S Mr
(CCSR);
        [email-masked]

       
       
        Thanks,
       
        Gorry