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

[George Gross <gmgross@nac.net>]

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

On Mon, 14 Aug 2006, Michael Noisternig wrote:

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