Re: WG/Authors Opinions please :draft-cruickshank-ipdvb-sec-req-03.txt

[Michael Noisternig <mnoist@cosy.sbg.ac.at>]

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

Gorry Fairhurst wrote:
> 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?

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