2003 February

February 2003

Zoltan Herczegh have set up the \”Free SIP Directory\” where he encourages registration of all that are reachable with SIP over the Internet.
Register Today!

This draft, in it\’s sixth version, introduces a key management scheme for real-time applications. All authors work for Ericsson.

Security protocols for real-time multimedia applications have started to appear. This has brought forward the need for a key management solution to support these protocols. Such a solution has to be suitable to be used in the context of conversational multimedia in a heterogeneous environment. This document describes a key management scheme that can be used for real-time applications (both for peer-to-peer communication and group communication), and shows how it may work together with protocols such as SIP and RTSP. In particular, its use to support the Secure Real-time Transport Protocol, [SRTP], is described in detail.

MIKEY: Multimedia Internet KEYing, February 2003

A new internet draft introduces a scheme for using Kerberos out-of-band authentication in SIP. The introduction in the draft gives a good overview:

Currently, SIP (3) specifies use of either HTTP Digest or S-MIME security mechanisam for providing selective security at SIP level. The key generation is not defined and currently not in scope of SIP(3). Both the mechanisam are not fool-proof security mechanisam, One of them only provides an authenciation feature. The transport level security (TLS), is the recommended (\”SHOULD\”) methodlogy in SIP RFC.

The TLS provides a mechanisam for generating key and provides hop-by-hop transport level security (i.e. transport payload is secured). The cons. of TLS is that on server side it has to maintain multiple TLS sessions. Any break in session or change in address needs a session re-initiation. If using Public/Private key, the algorithmic procedures are computational heavy, thus makes it less scalable (i.e. with large number of subscriber). Since TLS will be a hop-by-hop security mechansim,TLS will be used between starting Node and first intrim proxy, security for remaining path till the end host may not be TLS and depends on intrim proxy, and there is no binding on it to use TLS.

The IPSEC, an application agnostic security at IP level, needs IKE key management to create and maintain secure tunnels between two clients over public internet. The complex nature of IKE makes it more difficult within SIP domain, although it is also recommended(\”MAY\”) in SIP(3) RFC. The rest of the section, will define a new mechanisam of security for SIP domain, which provides end-to-end security, characterized by light weight (i.e. less number of key management messages, ticket controlled authentication, and easy to manage/deploy).

This mechanisam is based on using KERBEROS-PKI as key management for authenticating the end SIP clients and generating ticket on behalf of server. The SIP client uses that ticket to authenticate itself to the end-server and generates the key, which is used for securing the SIP payload. The message exchanges for key generation and providing SIP level security is detailed in following sections.

ntication for SIP, February 2003

Jeff Pulver, CEO of pulver.com and a well-known IP telephony evangelist, yesterday filed a petition with the US FCC to Rule Internet Telephony unregulated. This is a very important move, to assist true convergence and separate traditional telephony over IP from Internet Telephony over broadband IP networks connected to the Internet.

ADVISORY/Jeff Pulver, CEO, pulver.com Petitioned Federal Communication Commission to Rule Internet Telephony Unregulated

« Previous Page