[Fwd: Re: Comments on Security requirements/framework for GSE/ULE]

[Gorry Fairhurst <gorry@erg.abdn.ac.uk>]

To ipdvb list:

Thanks Knut, your detialed comemnts are much appreciated!!!

I'll forward this to the list (you are of couyrse welcome to join the 
list, but your comments are much appreciated in whatever form).

List, aurthors, please find his message enclosed,

Gorry

-------- Original Message --------

Subject: Re: Comments on Security requirements/framework for GSE/ULE
Date: Fri, 16 Feb 2007 12:12:53 +0100
From: Knut.Eckstein@esa.int
To: gorry@erg.abdn.ac.uk

Dear Gorry,

I had sent you the following comments earlier as well... I can send them
to the list as well, I guess I would have to join the list first before. 
Right now the message is html-formatted, but I'm wondering whether the 
list might be openly hostile to html-emails
:-)

I sent this message originally on 23 Jan...

--------

Dear Gorry,

as discussed recently on the phone, here are my comments on subject
document:

I. General security analysis comments. The analysis is well structured 
in  general, however I would like to mention the following points:

1. Threat analysis context: I think it would add value to the analysis 
if  one considered a broader context which describes the end-to-end 
overall  communication scenario employed by the user: Often times, the 
user has to secure his communications beyond the satellite link, because 
he is using terrestrial public network links in addition to the 
satellite link.
Therefore, if the user is concerned about loss of confidentiality and 
loss  of integrity of his communication data, he will employ end-to-end 
network security mechanisms like IPSec or TLS. A gov/mil user may be 
forced by regulations to employ specific measures of that type.

Only if satellite link is used to e.g. directly join branch offices to a
HQ, ULE Sec would be the sole provider of confidentiality and integrity
and for gov/mil users this scenario further narrows to circumstances 
where they are not required to employ nationally approved crypto 
equipment (this is assuming that ULE security mechanisms are not 
nationally approved, so users would have to run approved cryptos on top 
even in the case of the satcom link being the only public transmission 
segment.

All of this means that in many cases the confidentiality and integrity 
of the user data will already be taken care of. So ULE security measures
would focus on either providing traffic flow confidentiality for user 
data that has already been encrypted or user data encryption for users 
who don't care about confidentiality/integrity in their other network
segments, i.e. because they (rightly or not) assume those links to be 
fiber optical. So I would argue that in Section 4, traffic flow 
confidentiality should be listed as the first and formost requirement.

Section 8 "Security Considerations" briefly touches upon these points by 
stating that link level encryption is often used to "supplement" L3/L4 
techniques, but for me this is "too late in the document" and the notion 
of "supplementing" should be expanded.

Of those users who already encrypt/sign their data, only a subset will 
be interested in protecting against traffic flow confidentiality. 
Another (overlapping) subset of users will have (strong) availability 
requirements on top of requirements for confidentiality and integrity.

For these people, the first paragraph on page 6 "(In existing MPEG-2 
transmission networks, these messages are broadcasted in the clear (no 
encryption or integrity checks). The integrity of these messages is 
important for correct working of the ULE network. However, securing 
these messages is out of scope for ULE security, because these messages 
are not normally encapsulated with the ULE method.") is crucially 
important to understand, because it explains that their availability 
requirement wrt ULE transmissions cannot be met by the proposed ULE 
security mechanisms.

In the same light, I think that the core statement of the following 
paragraph is not entirely correct: "Securing the ULE source and 
receivers eliminates the need to consider security issues regarding the 
remaining system components, such as multiplexers, re-multiplexers and 
modulators."

The devices mentioned could be attacked (in-band or out-of-band, 
especially if they have an IP-based management interface in addition to 
their MPEG TS interfaces) with the intent to deny service through 
malicious reconfiguration, but also to potentially have an "easier go" 
at listening to or even modifying/inserting MPEG TS messages, usually 
using debugging functionality provided by the device, i.e. threaten 
their confidentiality/integrity in case cryptographic ULE 
countermeasures are limited or do not exist. The existing threat 
analysis from my point of view focuses a bit too much on performing 
these attacks via the air interface, which is not necessarily the only 
way to get to the MPEG TS...

In summary, I think availability is an often sought security requirement 
next to integrity and confidentiality and should thus receive some more 
coverage in this spec. E.g list "protection against loss of service 
through malicious reconfiguration" as a requirement in section 4 and 
discuss inhowfar it can be met by ULE-based security mechanisms.

2. Active threats discussion in section 3.2. Denial of Service is listed
as the last bullet point in the active threats portion of 3.2 which is
thereafter concluded with the following:

"The active threats mentioned above are major security concerns for the 
Internet community. The defence gainst such attacks is data integrity 
using cryptographic techniques and sequence numbers [BELLOVIN]."  I 
think the majority of denial of service attacks cannot be countered 
using cryptography and sequence numbers.

3. I found it quite hard to review this draft while not being a 
non-ULE/MPEG specialist. The reader is assumed to have a lot of detailed 
knowledge of MPE vs ULE to understand the relatively short statements in 
sections 6.1 and 6.2 e.g.  "Encryption of the MPE MAC address is not
permitted in such systems.

Also, I was confused by two statements on page 7 which for me 
contradicted  each other: Network devices may re-number the PID values 
associated with one or more TS Logical Channels (e.g. ULE Streams) to 
prevent clashes at a multiplexer between input streams with the same PID 
carried on different input multiplexes."

While this and preceding text at the bottom of page 6 seem to indicate 
that one cannot rely on the PID to identify a certain network node, 
later on the same page it says: "However there is only one valid source 
of data for each MPEG-2 Elementary Stream, bound to a PID value. This 
observation could simplify the requirement for authentication of the 
source of a ULE Stream".

4. Active threat scenarios: For case 2 it is mentioned that the MPEG
transmission operator may not be aware of such an attack, for case 3 it 
is stated that he will probably detect such an attack. Why then does 
section 4 recommend intrusion detection as a security measure for case 3 
but not for case 2?

5. Section 6 among others discusses the potential to hide the ULE 
receiver identity to allow for traffic flow confidentiality even beyond 
the OSI layer 3 headers. But implementing this to my understanding may 
have consequences which should be discussed, e.g. a common key must be 
used so that every receiver can first decrypt and then see whether the 
packet is really intended to be processed by him. This in turn could 
simplify denial-of-service attacks.

II. Editorial comments:

1. The last three paragraphs of section 3.1 no longer focus on the section
title "system components" but provide an initial attack assessment ('an
attacker that is able to modify'), an initial countermeasure discussion
('one method to provide security is to...', etc.)

2. In section 3.3 (Threat scenarios), "hijacking" is not a well defined
term, the authors probably want to express the attacker's ability to
"conduct active attacks", to stay with the terminology established so 
far. Typo "active actives" instead of "active attacks".

3. Section 4 is titled "Security requirements for IP" but the bullets
contain/discuss both requirements ('data confidentiality', 'protection
against replay attacks') as well as technical security mechanisms ('ULE
source authentication is required'). Ideally security requirements 
should be discussed first and then followed by the security 
services/mechanisms chosen to satisfy the requirements. 'Layer 2 ULE 
Receiver authentication' could need a bit more detail, e.g. is it 
intended to be receiver to receiver or receiver to hub, one-directional 
or bi-directional authentication? Lastly, why is the section title and 
some of the terminology (e.g. 'IP addresses') specific to IP, if ULE can 
encapsulate IP as well as other network protocols?

4. Section 6.2 on providing security at the encapsulation layer lists 
only advantages, not a single disadvantage :-)) Since the section ends 
with "This method does not preclude the use of IPsec at L3 (or TLS 
[RFC4346] at L4)."

I would suggest mentioning that using L3 end-to-end security would 
partially deny the advantage listed just above (use of PEP, compression
etc), since  those techniques could only be applied to TCP packets 
bearing a TCP-encapsulated IPsec packet exchange, but not the TCP 
packets of the original applications, which in particular inhibits 
compression.

Best regards,

Knut
--
Dr. K. Eckstein, Telecommunication System Security Engineer
ESA/TEC-ETC, P.O. Box 299, 2200 AG Noordwijk ZH, Netherlands
Tel: +31 71 565 8894


Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote on 16/02/2007 11:53:45:

> A little whiel ago, I received some oral comments (via the telephone
> from Knut Eckstein) that I would like to relay to the authors/group
> concerning the ULE-SEC requirements draft:

> * Section 6 would benefit from some diagrams.
> * Please make a proposal for a framework, to indicate how the
> requirements could be satisfied, and different entities involved.
> * Network availability seems to be an important driver for this work -
> although these words are may be not used - as a part of this securing
> the control plane is very important. More about this would be useful
> (e.g. using ULE extensions and ULEsec in combination and use in GSE).

> I am bcc'ing this to the Kunt, with the hope that he may be able to add
> more detail and clarity - via the ipdvb mailing list (or perhaps via a
> phone call to Sunni who is currently the document editor).

> Gorry