Subject: FW: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt

From: "Cruickshank HS Dr (Electronic Eng)" <[email-masked]>
Date: Fri, 29 Oct 2004 17:11:05 +0100

Hi George and all,

I like to add my comment to this threat about the security
considerations.  See comments in-line:

--
Dr. Haitham S. Cruickshank 
Senior Research Fellow 
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: [email-masked] [mailto:[email-masked]] On
Behalf Of George Gross
Sent: 27 October 2004 20:14
To: [email-masked]
Subject: security considerations wrt/ draft-ietf-ipdvb-arch-01.txt

Hi,

	I was reviewing the above draft's security considerations
section
8, and thinking about possible threat models.

	Suppose a rogue DVB-RCS subscriber cracked the terminal's
software
and took control of its behavior. From what I could discern, in the
absence of point to point link layer encryption that adversary could
eavesdrop on any peer subscriber's IP communications, correct? 

Haitham:  Sorry George this is not correct.  If encryption is performed
in the MPE layer (which encapsulates the IP packets), then the hacker
will need the encryption key to see any user data in these PME packets.

Let's assume the hapless peer subscriber is Joe Consumer, for whom IPsec
and TLS
are random letters in the alphabet. This scenario could be a security
exposure similar to what early 802.11b had, which garnered lots of
negative press and rev'ing to fix that standard.

Haitham:  This is true of any wireless link.  This is the reason that
the draft mentions using network layer (IPsec), transport (such as SSL)
or even application layer (such as secure XML, etc..).  Therefore such
solution should be encouraged for users of wireless links (with or
without link layer security).  

	As currently written, the section 8.1 leaves it up to the Access
Network Operator to optionally set up a link layer security service. Yet
there is insufficient definition of what that security service is, and
how
it would be integrated with the IP layer related services, such as DVB
address resolution. 

Haitham: These procedures are defined in standards such as the DVB-CA
(conditional access in broadcast applications such as TV) and DVB-RCS
(two-way satellite communications).  I suppose we can add a sentence to
say the DVB security procedures should be followed.  By the way,
currently there is some work in the DVB community to upgrade the
security procedures, but this is only early days.  Therefore IPsec, SSL,
etc should be encouraged. Finally, this group can not force specific
security requirement on such networks.
Best regards
Haitham

It seems odd to imply that the IPDVB architecture
would depend on those link layer security services, yet not even name
them
by reference and mandate one.

	I would have thought the IPDVB architecture would require at
least
_one_ of those possible choices _must_ be implemented as part of the
IETF
standard. Otherwise, no two IPDVB implementations could inter-operate
unless they happened to understand the same Access Network Operator's
link
layer security service.

	I seem to recall that there was an e-mail thread on this list
wrt/
security last spring, but its conclusion didn't seem to account for the
above security risks and inter-operability issue...

hth,
	George

On Fri, 15 Oct 2004, Gorry Fairhurst wrote:

>
> This note starts the ipdvb WG Last Call for comments for the WG
document
> named below:
>
> draft-ietf-ipdvb-arch-01.txt
>
> The last call will end on 29/10/2002.
>
> Members of the IETF are asked to read the draft and send any issues,
> comments, or corrections to this mailing list. The WGLC procedure is
the
> last chance for this working group to modify/correct this z.
>
> Please do forward any comments to the list.
>
> Best wishes,
>
> Gorry Fairhurst
> (ipdvb WG Chair)
>
>

---

From: George Gross <[email-masked]>
Date: Fri, 29 Oct 2004 13:36:11 -0400 (EDT)

Hi Haitham,

inline below....

> considerations.  See comments in-line:

<snip>

> will need the encryption key to see any user data in these PME packets.

Well yes, but I did say "in the absence of point to point link layer
encryption". If MPE link layer encryption does point-to-point encryption
between head-end transmitter and subscriber (and vica-versa) that would be
secure. But as currently written, the IPDVB arch allows that service to be
optional and it does not even refer to any MPE link layer encryption
standard.

Further, if the MPE link layer encryption used a group key then that would
be insecure in this attack scenario, as cracking the subscriber terminal
would compromise the group key.

> without link layer security).

I think we may have mismatched assumptions about the sophistication of the
IPDVB users. In a public IPDVB access network, used by consumers, the
burden of securing the network's first hop falls on the shoulders of the
Access Network Operator, not the consumer. Yet the IPDVB architecture as
currently written makes that first hop security optional, or at best
vendor-specific.

> (two-way satellite communications).

At the least, the IPDVB arch document should identify its requirements on
these security services: point-to-point encryption between head-end and
individual subscriber, source authentication when binding IP addresses and
MAC addresses, mutual authentication between the subscriber terminal and
head-end, etc.

BTW, isn't DVB-CA primarily a broadcast video encryption scheme?

>  I suppose we can add a sentence to
> security procedures, but this is only early days.

when you say "DVB community" did you mean a SDO? or a private consortia?
are drafts of that work available publically?

> Therefore IPsec, SSL,

ummm... as you know, the IETF has alot of history around this topic:

RFC3365, RFC3552, RFC3631

so it is true that this working group can't force anyone to *use* DVB
security mechanisms, but neither can this working group expect to *create*
an insecure IETF IPDVB standard.  The IESG will bounce it.

The way things stand at the moment in this document, an IPDVB vendor does
not have to implement any security standards. They can produce products
that only transmit cleartext and still they can assert that they are IETF
IPDVB "standards compliant". Further, any two vendors that do implement a
DVB security service are unlikely to inter-operate, since none was
mandated as a must implement.

As I expressed in another e-mail in this thread, there is a case to be
made for an industry-wide IPDVB security service:

- superior security, due to peer review by the IETF community,

- inter-operability, fostering economies of scale like that seen for 802
wireless

This could be a DVB link-layer service or it could a MSEC layer-3 overlay.
The former option makes this group's work dependent on another SDO. The
latter option could be advanced by this working group in cooperation with
MSEC...

br,
	George