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

["Cruickshank HS Dr (Electronic Eng)" <H.Cruickshank@surrey.ac.uk>]

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: H.Cruickshank@surrey.ac.uk 
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

-----Original Message-----
From: owner-ipdvb@erg.abdn.ac.uk [mailto:owner-ipdvb@erg.abdn.ac.uk] On
Behalf Of George Gross
Sent: 27 October 2004 20:14
To: ipdvb@erg.abdn.ac.uk
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)
>
>