IDC’99, Madrid23 Sept. 1999

1Ian Brown, UCL

Secure multicast conferencing

Peter Kirstein, Ian Brown and Edmund Whelan

University College London

IDC’99, Madrid23 Sept. 1999

2Ian Brown, UCL

Multicast conferencing involves...

VideoAudio

Shared whiteboard

IDC’99, Madrid23 Sept. 1999

3Ian Brown, UCL

Security provides...

• Confidentiality: only authorised conference members can access conference data

• Integrity: you can be sure data has not been altered in transit

• Authentication: of conference announcers and participants

IDC’99, Madrid23 Sept. 1999

4Ian Brown, UCL

Point-to-point conferencing security is easy...

GCCProvider

Node 2 Node 3 Node 4

Node 1

MCS Connections

Top GCCProvider

NodeController

ApplicationProtocol

Entity

GCCProvider

GCCProvider

NodeController

NodeController

NodeController

ApplicationProtocol

Entity

• Each link is secured using a standard communications security protocol: IPSEC, SSL/TLS, SSH

• Extremely wasteful of bandwidth

• Multipoint control units are security risks

IDC’99, Madrid23 Sept. 1999

5Ian Brown, UCL

But multicast is more tricky...

• Multicast doesn’t fit the “point-to-point” model of current security protocols

• There is no standard method of sharing keys between group members

IDC’99, Madrid23 Sept. 1999

6Ian Brown, UCL

Insecure conferences

• Use Real-time Transport Protocol (RTP) to send data

• Users announce conferences and invite users by sending a session invitation via e-mail, the Session Announcement or Session Invitation Protocols

IDC’99, Madrid23 Sept. 1999

7Ian Brown, UCL

Secure transport

• RTP allows data to be encrypted with DES - implemented in UCL’s tools

• We want to move to IPSEC to remove need for cryptographic code in applications and take advantage of its wide range of ciphersuites and protocol and implementation security

IDC’99, Madrid23 Sept. 1999

8Ian Brown, UCL

IP security extensions

• Now standardised by IETF (RFC 2411)

• Provides network-layer protection for all packets sent between compatible machines

• Not yet finished for multicast

IDC’99, Madrid23 Sept. 1999

9Ian Brown, UCL

Key distribution problem

• The Internet Key Exchange (IKE) allows two hosts to negotiate security parameters for an IPSEC connection

• But multicast IKE is much harder, and being investigated by the IRTF

IDC’99, Madrid23 Sept. 1999

10Ian Brown, UCL

Conferencing solution

• We use secure session invitations to distribute security parameters

• Sent using secure SAP, SIP, or e-mail (S/MIME) or retrieved via the World Wide Web (TLS)

IDC’99, Madrid23 Sept. 1999

11Ian Brown, UCL

Web distribution

• Session descriptions are stored on a secure Web server

• Authorised conference members can retrieve descriptions over a TLS link

IDC’99, Madrid23 Sept. 1999

12Ian Brown, UCL

Smartcards

• Users don’t like having to remember many long passphrases

• Mobile users need access to keys from many different systems

• Software keys are vulnerable to theft

• Smartcards alleviate all these problems

IDC’99, Madrid23 Sept. 1999

13Ian Brown, UCL

Active services

• In-network code can reduce bandwidth requirements, convert between coding schemes, provide multicast connectivity, etc. etc.

IDC’99, Madrid23 Sept. 1999

14Ian Brown, UCL

Processing encrypted data

Trusted environment

Filter

Plugin filtersCryptoengine

Cryptoengine

Secure, wireless low-bandwidth links

Secure, wired high-bandwidth links

Internet

Mobile Host

• You can give proxies the session keys needed for them to access and process data

• We are developing proxies that can work without this security risk

IDC’99, Madrid23 Sept. 1999

15Ian Brown, UCL

Conclusions

• Multicast conference data can be secured at the network or application layer

• Until multicast key distribution is standardised, lightweight methods based on session descriptions can be used

• New techniques are needed to allow in-network processing of encrypted data