Subject: I-D ACTION:draft-cruickshank-ipdvb-sec-req-03.txt

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 10 Aug 2006 10:54:07 +0100

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title		: Security requirements for the Unidirectional Lightweight 
Encapsulation (ULE) protocol
	Author(s)	: H. Cruickshank, et al.
	Filename	: draft-cruickshank-ipdvb-sec-req-03.txt
	Pages		: 17
	Date		: 2006-8-9
	
This document provides a threat analysis and derives security
requirements for MPEG-2 transmission links using the
Unidirectional Lightweight Encapsulation (ULE). It also provides
the motivation for ULE link-level security. This work is intended
as a work item of the ipdvb WG, and contributions are sought from
the IETF on this topic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-cruickshank-ipdvb-sec-req-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	mailserv at ietf.org.
In the body type:
	"FILE /internet-drafts/draft-cruickshank-ipdvb-sec-req-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
<ftp://ftp.ietf.org/internet-drafts/draft-cruickshank-ipdvb-sec-req-03.txt>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 10 Aug 2006 11:05:24 +0100

The authors have posted a new revision of their requirements I-D with 
arequest to make this a WG I-D, as discussed at the IETF meeting in 
Montreal.

I have a few questions that I would like to see clarified by the WG via 
this list and/or the authors before this can proceed. These are:

1) Could the people on the mailing list clarify which SPD selectors we 
think should be used (NPA/MAC address, SID, etc), detailing the various 
options and needs, including what happens when we use the bridging 
header, and whether policy also can be determined based on the Type 
field in combination with a NPA/MAC address.

2) Can  we determine precisely what we man by a "Stream". Does a Stream 
always only have ONE originating source? That is, does the PID imply a 
specific intended source?

I'd really like to see a section on what constitutes a stream - for this 
the  list needs to agree if a stream has only one source (or may have 
multiple sources), etc. This section should also elaborate how data can 
be inserted in a stream during an attack and say (if you can) how 
significant this threat is.

3) Is there anything else that may be missing from this document?

Gorry Fairhurst

---

From: Michael Noisternig <[email-masked]>
Date: Mon, 14 Aug 2006 11:50:42 +0200

Hello everyone,

this is my first post here, so just a few words to introduce myself...
I'm a student of computer science and mathematics at the University of
Salzburg, and I've been working as a project assistent in the areas of
ULE and security for a couple of months now. I'm currently working on a
draft that is hopefully going to be released soon.

I've read the current version of the ULE security requirements draft,
and there are few things I want to comment on. The first thing is, it
reads a lot better now than the last version I read (-01). :-)

So here are my other comments:

§3.2, last paragraph:
- data integrity alone does not provide authentication
- the defence statement is oversimplifying and belongs to the
requirements section

§3.3, threat cases 2 and 3:
one can distinguish between two other cases:
(a) insider attacks, i.e. active attacks from adverseries in the know of
certain keys
     -> protection against this attack requires source authentication
(e.g. digitial signatures)
(b) outsider attacks, i.e. active attacks from outside of a VPN
     -> in this case simple MACs are sufficient (i.e. group authentication)

§4: all the references to section 2 should be 3

§4, security requirements list:
- instead of "ULE source authentication is required..." should more
generally say "integrity protection and authentication is required..."
- missing L2 ULE sender and receiver authentication (entitiy authentication)

$4, other general requirements list:
- might mention requirement for policy management
- integrity of control messages (SI tables): as said before, what we
want is authentication

§4, security requirements case 2:
- MACs do NOT provide source authentication for cases 2 and 3 (subcase (a))
- if mentioning TESLA should first speak of digital signatures
(btw, TESLA introduces further latencies at the receiver side and still
requires digital signatures (for signing the head of the hash chains))

§5, first paragraph, last sentence:
...impact on bandwidth?

§5, last list item:
I don't see how the issue of address preservation is of relevance
to the ULE scenario. AFAIK address preservation is important for correct 
routing within multicast trees, but since in ULE networks data is simply 
sent from one L2 point to the next I don't understand the problem.

§6.1, disadvantages:
third item should probably mean "Encryption of the MAC/NPA address is 
not permitted in MPE systems."

§6.2:
- references to section 2 should be 3
- information in first paragraph is redundant, i.e. already in the
requirements section (section 4)

§7, second paragraph:
It should better read "There is an optional requirement for L2
authentication and integrity assurance as well as protection against
insertion of other data into the ULE stream (i.e. replay attacks)."

> specific intended source?

It is my understanding that there can only be at most one designated
sender per PID, basically due to multiple synchronization problems
otherwise. However, this does not preclude the possibility of a 
sophisticated active adversery injecting data on the same PID.

Regards,
Michael Noisternig

---

From: [email-masked]
Date: Mon, 14 Aug 2006 14:25:27 +0100

Hi Michael,

Thanx for your comments. See inline.

> - the defence statement is oversimplifying and belongs to the

Yes, Data integrity is different from data authentication, but the same MAC can
be used to provide both data integrity and data authentication.

> (e.g. digitial signatures)

This is more part of key management techniques. An adversary (even if it knows
the keys) has to still over-ride the original transmission stream and deliver a
modified stream – this is Case 2 as described in the draft.

>      -> in this case simple MACs are sufficient (i.e. group authentication)

Note that the Secure ULE aims to secure only between the ULE encapsulation
gateways and the ULE receivers.
> §4: all the references to section 2 should be 3
Thanx, will modify these.
> generally say "integrity protection and authentication is required..."
Yes, will change this

> - missing L2 ULE sender and receiver authentication (entitiy authentication)
This is part of the initial key exchange and authorisation phase – it is present
in the requirements lists in section 4

> - might mention requirement for policy management
The policy management  should be part of the key management system. Could add a
line for this

> - integrity of control messages (SI tables): as said before, what we
Please see section 3.1. The integrity of the SI tables been discussed in Section
3.1 and it is stated that this is out of scope of the ULE security as these
tables are not encapsulated by ULE.

> - MACs do NOT provide source authentication for cases 2 and 3 (subcase (a))
The MAC is used to make sure that the data has been sent by the correct source –
hence provides source authentication. I am not sure why you say that it does not
provide any source authentication.

> requires digital signatures (for signing the head of the hash chains))
TESLA is only mentioned as an option that may be possible.

> not permitted in MPE systems."
Will change this

> sophisticated active adversery injecting data on the same PID.

Regards
Prashant

-- 
Prashant Pillai
Research Assistant
School of Engineering, Design and Technology
University of Bradford
Bradford, BD7 1DP
West Yorkshire
United Kingdom
Phone: 0044-1274-233720
email: [email-masked]
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to [email-masked]
------------------------------------------------------------

---

From: Michael Noisternig <[email-masked]>
Date: Mon, 14 Aug 2006 17:24:21 +0200

Hi Prashant,

thanks for your quick reply. See comments inline.

> Hi Michael,

<snip>

> be used to provide both data integrity and data authentication.

Integrity of messages is automatically assured by their correct 
authentication, so yes, MACs provide both authentication and integrity. 
But you are not speaking about MACs in that paragraph or section. A CRC 
or any unkeyed hash provides integrity protection but is certainly not 
effective against active adverseries.

> gateways and the ULE receivers.

Well, I speak about the case where a ULE receiver can act as a sender, 
i.e. ULE encapsulator. A valid receiver (i.e. one knowing the shared 
authentication key for MACs) acting as a sender can successfully forge 
messages, but not when digital signatures are used (case a). However, a 
sender who does not know the MAC key (e.g. because he is not part of the 
VPN within the same ULE network) will not be able to forge messages 
(case b).

Note that even when there is only one ULE encapsulator an active 
adversary may invalidate the one-sender assumption, and so you again 
cannot detect forged messages for case a when MACs are used.

> in the requirements lists in section 4

Well, it was just my impression, if you mention authorization separately 
from key management, you should also mention entity authentication.

<snip>

> provide any source authentication.

Multiple senders. This is why you want TESLA.
(In multiple sender scenarios MACs can only provide group authentication.)

> TESLA is only mentioned as an option that may be possible.

<snip>

Best regards,
Michael

---

From: George Gross <[email-masked]>
Date: Tue, 15 Aug 2006 10:44:24 -0400 (EDT)

Hi Michael,

in looking over this thread, I think that there might be confusion about
which threat model is being assumed by you versus the one assumed by
Prashant. The group key management subsystem does the authentication and
authorization of the IPDVB group membership. The network's security policy
administrator decides what constitutes a group's membership and whether
there is an unacceptable risk of an insider attack that the group must be
defended against.

For a basic security policy, group authentication is sufficient because
group members are trusted.  Source authentication using digital signature
or TESLA is not required. In the event that the group's authentication key
is compromised then the scope of the damage is limited to only that group
rather than all groups sharing that MPEG TS. Limiting the size of each
group can help minimize this risk.

For a security policy that considers an insider attack a risk, then source
authentication would be a reasonable mechanism to counter that
vulnerability.  However, I have not heard on this list any use cases that
would need that service at layer-2.

Michael, did you have such an example in mind for IPDVB?

hth,
	George

---

From: Michael Noisternig <[email-masked]>
Date: Tue, 15 Aug 2006 21:47:12 +0200

Hello George,

thanks for commenting on this. See below.

> would need that service at layer-2.

This is exactly what I was talking about. I am fully aware that insider 
attacks are more unlikely than attacks from outside a VPN (or virtual 
LAN, to stay with your terminology) within the ULE network, and that 
most will be fine with group authentication (i.e. MACs). (And there are 
good other reasons why one would want to stick with MACs.)
I was just trying to point out that...

> Michael, did you have such an example in mind for IPDVB?

Yes, I was considering just another threat model in which MACs do not 
provide source authentication. I guess the authors of that draft have 
also considered that threat once because of mentioning TESLA.

Best regards,
Michael