Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt

From: <[email-masked]>
Date: Sat, 20 May 2006 07:59:27 +0100

Many thanks Prashant,

See responses in-line:

----
Dr. Haitham S. Cruickshank 
Lecturer 
Communications Centre for Communication Systems Research (CCSR) 
School of Electronics, Computing and Mathematics 
University of Surrey, Guildford, Surrey GU2 7XH, UK 
 
Tel: +44 1483 686007 (indirect 689844) 
Fax: +44 1483 686011 
e-mail: [email-masked] 
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/ 

________________________________

From: [email-masked] on behalf of [email-masked]
Sent: Tue 16/05/2006 14:33
To: [email-masked]
Subject: Comments on draft-cruickshank-ipdvb-sec-req-01.txt

Hi Gorry and Haitham,

The new version of the draft (draft-cruichshank-ipdvb-sec-req-01.txt) addresses
most of the security requirements that shall/may be required for the ULE links.
I have just a few comments on the draft.

1. Is there a particular reason why the security measurements are only taken for
wireless MPEG2 networks (as indicated in the Introduction section)? Why are the
wireline MPEG2 networks more secure? I think that the security requirements
should be for any MPEG2 networks, wired or wireless.

Haitham: You are right the requirements should cover both wired and wireless environment. However, wireless environment is more vulnerable to security attacks. For example eavesdroping is easier in wireless broadcast networks.

2. Network access control is also an important security requirement. There is no
point to just secure the user traffic, when this user has not been authenticated
and authorised for the connection. This may be coupled with key management.

Haitham: I agree. The draft does address this issues.  May be we need to make it clearer.

3. This document aims to basically highlight the security requirements that are
important for securing (just) the MPEG2 link. Hence this is important from the
point of view of the MPEG2 Network Provider (NP).  As the MPEG2 Network
provider has no control on any end-to-end security mechanism, it is something
that should not directly affect the security requirements on the ULE Link. ULE
Security should aim to provide all the security requirements. The text leads to
confusion where the Section 2, Last paragraph mentions that the ULE
authentication and Integrity are required especially because active attacks are
possible at the receiver end; while Section 3 suddenly states that these are
optional requirements.

Haitham: There are two points here: One, is interworking of end-to-end and ULE link security. The draft highlights the fact that ULE security should not be an obstacle against end-to-end security, if such service exists. For example, if IPsec or transport layer end-to-end security is used, then ULE security should allow passing such traffic as long as it is compliant with general rules and plocies of that MPEG-2 transmission network. The second point is the optional authentication and Integrity: The reason is that we want to leave a flexibility for the MPEG-2 transmission network to implement it depending on the specific policies for each service. Some services might not need authentication or data integrity. Any comments from ipdvb group are welcome on this issue.

There are contradicting sentences in the document, like in Section 5 2nd para,
the documents says that "ULE link security is considered as an additional
security mechanism to IP transport and application Layer security." But the
very next sentence says that "It should provide similar functions to that of
IPsec...". It leads to a confusion as to why to we need same level of security at
two layers.

Haitham: See answers above.

I agree with the fact that ULE security should provide high security similar to
IPSec, but just because their may be end-to-end mechanism present (which the
MPEG2 network provider cannot control anyways) we should not decide that the
other requirements (like source authentication, integrity etc) are optional.

Haitham: See answers above.

4. There are quite a few typo errors in the document, but I guess this is not so
important at this moment and could be looked into when we submit the draft as a
WG item.

Haitham: Thanks.

Regards
Prashant Pillai

Quoting Gorry Fairhurst <[email-masked]>:

> Prashat,
>
> Thanks for submitting your draft. Focussing for the moment on the
> security requirements and architecture:
>
> Are there any issues that you think you should be addressed in the
> security requirements document that are not currently captured in draft -01?
>
> Or any areas that you think should also be considered?
>
> Gorry
>

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

---

From: [email-masked]
Date: Mon, 22 May 2006 13:07:09 +0100

Hi Haitham,

I have a few more comments on the draft:

1. As stated in Section 3 – “Data confidentiality is the major requirement
against passive threats (using encryption).  L2 encryption or L3 (IPsec)
Encryption can satisfy this requirement”.  I disagree with this. L3 (IPSEC)
Encryption would not be able to prevent passice threats like traffic analysis
as the outer IP header is not encrypted. The only drive to provide L2 security
is to provide encryption of the complete higher layer packets to prevent any
traffic analysis.

2. Regarding the optional authentication and integrity. I think we need to be
careful with the wording in the draft.

- Is there a requirement for an “optional authenticity/integrity mechanism”
(like you said that some service may not need it)? or
- Is there a definite requirement for authenticity/integrity mechanism over the
MPEG2 link? This may be optional at the ULE level when other
authentication/integrity mechanisms at other layers may be present (like IPSEC
AH or ESP with Auth).

I prefer the second option which emphasises on the requirement for
authenticity/integrity but keeps it as an optional service at ULE. Could the
other members of the group also voice their opinion on this?

3. Who would be in-charge of selecting the Secure ULE level – the user or the
NCC? Does the NCC decide on the level of security to be used (according to the
user profile, pricing plan, etc) or can the user select the level of security
(so the user can select different security levels for different sessions)?

4. What about content protection? Do we need to address the
support/interoperability with content protection mechanism (like DRM)?

5. What about Interworking with existing lower layer security mechanisms
especially the ones specified in DVB RCS (MKE, EKE, QKE)? Do we expect a user
to perform DVB RCS security setup (using MKE, EKE, QKE), then perform another
set of security setup for Secure ULE (using GDOI/GSAKMP etc) and then a final
end-to-end IPSEC setup (using IKE/ISAKMP or even  GDOI/GSAKMP etc)?

Regards
Prashant

Quoting [email-masked]:

> Haitham: You are right the requirements should cover both wired and wireless
> environment. However, wireless environment is more vulnerable to security
> attacks. For example eavesdroping is easier in wireless broadcast networks.
>
> Haitham: There are two points here: One, is interworking of end-to-end and
> ULE link security. The draft highlights the fact that ULE security should not
> be an obstacle against end-to-end security, if such service exists. For
> example, if IPsec or transport layer end-to-end security is used, then ULE
> security should allow passing such traffic as long as it is compliant with
> general rules and plocies of that MPEG-2 transmission network. The second
> point is the optional authentication and Integrity: The reason is that we
> want to leave a flexibility for the MPEG-2 transmission network to implement
> it depending on the specific policies for each service. Some services might
> not need authentication or data integrity. Any comments from ipdvb group are
> welcome on this issue.
>