[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Network Access Control


It is good to hear from you.
The security requirements document would certainly benefit from additional contributions. I'll cc this to the authors, and hope they can add their own respones to mine.
I'd encourage you to send any contributions you can to the security requirements I-D (to this list), that would be good to start security work. I note that you mention DVB-RCS, examples using a specific technology are always welceome, but please do bear in mind that the document would need to be applicable to a range of MPEG-2 based transmission systems.
If you have other thoughts that could be captured on specific topics, it would be worth trying to first set those out in an email, and if you can find others from the group to work on this, a new I-D would be the easiest way to bring the topic to the attention of others. 

Best wishes,

Gorry

P.Pillai@Bradford.ac.uk wrote:

Hi Gorry,

As mentioned in some of the emails before, I think we should look into the
network access control methods for the IP services over DVB systems. Though
RCST authentication and key exchange mechanisms have been defined by DVB, but
authentication of the users behind the RCST may also be important. This may be
especially required by the service provider depending on their business models.
Do you think it is worthwhile to look into this issue?

RADIUS (running over UDP/IP/ULE/MPEG2-TS) is a light protocol that could be used
for authentication of user terminals. The RCST would have to be a RADIUS Client
forwarding the authentication requests to the DVB gateways in the NCC. The DVB
gateways act as RADIIUS proxies which further forward the requests to an AAA
server. The AAA server would have user profiles. DIAMETER (over
TCP/IP/ULE/MPEG2-TS) could also be used. DIAMETER though a more complex
protocol with larger overheads as compared to RADIUS, one of its main advantage
is its support for mobility.

Interaction of these with the RCS security could be an issue say when different
users connected to the same RCST (maybe in a cyber cafe) join different
multicast groups at different times and the new keys have to be sent to the
RCST.

The draft-cruickshank-ipdvb-sec-00.txt, draft gives a nice starting point for
the security services to be provided. But this draft seems to be very specific
for securing the ULE packets. Maybe a new ID could address the network access
control issue, what do you think?

Regards
Prashant