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

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

Hi Prashant,

thanks for your quick reply. See comments inline.

P.Pillai@Bradford.ac.uk wrote:
> Hi Michael,

<snip>

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

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.

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

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.

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

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

<snip>

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

Multiple senders. This is why you want TESLA.
(In multiple sender scenarios MACs can only provide group 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.

<snip>

Best regards,
Michael