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

[P.Pillai@Bradford.ac.uk]

Hi Michael,

Thanx for your comments. See inline.

Quoting 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

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

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

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.

> (b) outsider attacks, i.e. active attacks from outside of a VPN
>      -> 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.
>
> §4, security requirements list:
> - instead of "ULE source authentication is required..." should more
> 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

>
> $4, other general requirements list:
> - 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
> want is authentication
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.

>
> §4, security requirements case 2:
> - 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.

> - 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))
TESLA is only mentioned as an option that may be possible.

>
> §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."
Will change this

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

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: p.pillai@bradford.ac.uk
------------------------------------------------------------
This mail sent through IMP: http://webmail.brad.ac.uk
To report misuse from this email address forward the message
and full headers to misuse@bradford.ac.uk
------------------------------------------------------------