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

[George Gross <gmgross@nac.net>]

Hi Haitham,

inline below....

On Fri, 29 Oct 2004, Cruickshank HS Dr (Electronic Eng) wrote:

>
>
> Hi George and all,
>
> I like to add my comment to this threat about the security
> considerations.  See comments in-line:
>

<snip>

> 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.

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.

 >
> 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).

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.

 >
> 	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).

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
> 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.

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

> Therefore IPsec, SSL,
> etc should be encouraged. Finally, this group can not force specific
> security requirement on such networks.

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

 > 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)
> >
> >
>
>