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

[<H.Cruickshank@surrey.ac.uk>]

Hi Prashant,

Many thanks for your comments.  See replies 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: H.Cruickshank@surrey.ac.uk
http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/




-----Original Message-----
From: P.Pillai@Bradford.ac.uk [mailto:P.Pillai@Bradford.ac.uk] 
Sent: 22 May 2006 13:07
To: Cruickshank HS Dr (CCSR)
Cc: ipdvb@erg.abdn.ac.uk
Subject: RE: Comments on draft-cruickshank-ipdvb-sec-req-01.txt


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.

Haitham: As you know that if IPsec is used in Tunnel mode then it will
protect the inner IP header from traffic analysis.  Of course, we have
to live with the overheads of IPsec tunnel mode.

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

Haitham: The draft states that the ULE link security focuses on security
between the Encapsulation Gateways (ULE source) and Receivers.  The
level of security such as encryption key length and data integrity
methods are part of key management exchange that should happen before
ULE encryption or data integrity is performed.


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

Haitham:  I think this is out of scope for ipdvb group.

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

Haitham:  The specific link layer system (DVB-RCS) is just one type of
MPEG2- transmission networks.  MKE, EKE and QKE are key agreement
protocols for DVB-RCS.  The ULE security draft mentions that key
management (or key agreement protocols) should be decoupled from the ULE
encryption/integrity.  The reason is that the implementers of ULE
security will be free to choose a suitable key management.  Of course,
the MSEC related protocols (GSAKMP/GDOI ...) are the best choices, in my
opinion.

Haitham



Quoting H.Cruickshank@surrey.ac.uk:

> 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: H.Cruickshank@surrey.ac.uk 
> http://www.ee.surrey.ac.uk/Personal/H.Cruickshank/
>
> ________________________________
>
> From: owner-ipdvb@erg.abdn.ac.uk on behalf of P.Pillai@Bradford.ac.uk
> Sent: Tue 16/05/2006 14:33
> To: ipdvb@erg.abdn.ac.uk
> 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
>


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