Session Description Protocol fragment message
Technical Field
The present invention relates to a method for establishing a telecommunication session of streamed media, where the session is established by exchanging information about the session between at least two parties, said information about the session includes at least a session identifier and further session information with de- and encryption information for said streamed media. Furthermore, the present invention is also related to a computer executable software code for establishing a telecommunication session of streamed media, the code comprises code for establishing that session by exchanging information about the session between at least two parties, said information about the session includes at least a session identifier and further session information with de- and encryption information for said streamed media. The present invention concerns also a client computer to be connected to the IP-network and comprising a communication unit for a party to perform a telecommunication session of streamed media via that IP-network, the client computer comprising a computer readable medium having a computer program recorded thereon, the computer program comprising code for establishing that session.
Background of the invention
Internet Protocol IP telephony also known as Voice over Internet Protocol (VoIP) is getting more and more popular. Such evolution sustains the base of multimedia telecommunications like videoconferencing based on IP. IP-telecommunications is based on the use of the Internet Protocol to transmit e.g. voice packets over an IP network. Usually, the connection of a call is made by two endpoints opening communications sessions between each other. In the Public Switched Telephone Network (PSTN), the basis network for connection-oriented telecommunications, the public (or private) switch connects logical channels through the network to complete the calls. In a VoIP implementation, this connection is a multimedia stream (audio, video, or both) transported in real time. This connection is the bearer channel and represents the voice and/or video content being delivered.
They are two competing standardized protocols for VoIP operations, ITU-T H.323 and IETF Session Initiation Protocol (SIP). These two protocols describe the signalling and the control of multimedia conferences over packet based networks by different ways. Due to its simple and fast session setup mechanism, the SIP has quickly made large inroads into the VoIP market previously dominated by implementations adhering to the rather complex H.323 ITU-T Internet telephony standard. Whereas H.323 is closely modelling a traditional ISDN Layer 3 call setup and uses ASN.l-coded binary messages for signalling, SIP is based on an HTTP-like request/response transaction model using human-readable ASCII messages with a syntax nearly identical to HTTP/1.1.
SIP user identification is based on a special type of Uniform Resource Identifier (URI) called a SIP URI with a form similar to an email address. In order to establish a multimedia connection over the Internet between two parties User Agents (UAs) which can be either hardware SIP phones or PC based soft phones, one party SIP URI must first be resolved into the IP address of the UA under which that party is currently registered. SIP address resolution and routing is usually not done by the UA itself but delegated to the proxy sen/er responsible for the domain the UA is attached. Thus, the typical message flow during a SIP session takes on the form of a trapezoid starting from the UA of the first party towards the corresponding proxy continuing to the proxy corresponding to the UA of the second party while aften/vards a direct path is setup for the media stream between the two UAs. From the point of view of network security, this means that both the individual hops (UA from the first part>' to proxy, proxy to proxy, proxy to
the UA of the second party) must be secured on a hop-by-hop basis as well as the direct path between the two UAs. SIP session management messages are usually embedded into User Datagram Protocol (a connectionless protocol running on top of IP-networks) datagrams but can also be transported over a Transmission Control Protocol stream. On the other hand, the Real-Time Transport Protocol (RTP) employed in media sessions exclusively uses non-reliable UDP datagrams to transport real-time audio and video packets over the Internet.
The Session Description Protocol (SDP) transports information related to media in Multimedia over IP sessions. SDP can be used to transport encryption keys for secured media establishment. But SDP is clear-text, and encryption keys must be protected i.e. be unreadable to a third party when forwarded through IP-network. Such a protection can be obtained applying Secure Multipurpose Internet Moil Extension (S/MIME) encryption. The problem is that once the SDP body is S/MIME encrypted, some innocuous parts of the SDP messages are not readable anymore by intermediaries. Therefore, sessions that use S/MIME protected SDP do not work through firewalls or Network Address Translator (NAT) controlled by Application Layer Gateways (ALG) that need to read and modify the SDP parts related to addresses and ports.
Nowadays exist already few solutions to treat the above problem. It is possible to use clear-text SDP and transport the encryption keys elsewhere. But that means that an external mechanism must be setup for the key exchange. This is costly and difficult to correlate to the contents of the SDP body e.g. if there are different keys for audio and video streams. An alternative is described in RFC3261which defines hop-by-hop security services (e.g TLS - transport-layer security - or IPsec). The transport of signalling is secure, but the whole SDP (including keying material) is exposed to the intermediaries (e.g. proxy servers or ALG). It is also possible to use S/MIME protected SDP (as described in RFC3261) where the SDP body is encrypted. Consequently, such solution will simply not work with infrastructure using ALG for firewall and NAT traversal since ALG must have access to the SDP. It is also possible to copy SDP parts that are of interests to intermediaries in the signalling part of the message. The IETF Session Policy working documents (draft-hilt-sipping-session-spec-policy-00) indeed defines SIP header fields in which parts of the SDP body are copied. The SDP body can be encrypted but intermediaries con read or modify the SIP header fields. While being powerful, this pro-
posal is complex and does not re-use the semantics of SDP (e.g. definition of multiple media streamsj.This proposal requires that the SDP data that is to be read and modified by intermediaries is duplicated ( in the SDP body and in the SIP headers). Therefore the UA of the receiving party may have to cope v/ith a discrepancy between the two place where the information is. Furthermore such a solution will not work with basic clients that only understand SDP.
In a SIP Internet-draft proposal from C. Jennings dated February 11, 2005 with the title "SIP Offer/Answer with Multipart MIME" is addressed the issues around using multipart with the SIP offer/answer framework. There is specified a way to make an offer with a multipart/alternative MIME body and for the answer to indicate which of the parts were selected for the answer. This is needed for general backwards compatibility to allow migrations in situations such as moving from SDP to SDPng or moving from non-and-to-and encrypted SDP to encrypted SDP. Such proposal only deals with backwards compatibility of SIP and points that can not deal with S/MIME. It does not take into account session border controllers.
Summary of the invention
In view of the above, it is an object of the present invention to provide a method for establishing a telecommunication session of streamed media while ensuring backward compatibility and providing that session border controllers work with SIP communications when exchanging de- and encryption information for media protection. It is also an object of the present invention to provide a computer executable software code as well as a client computer with such a code for establishing such a telecommunication session of streamed media.
This object is achieved in accordance of the invention by a method for establishing a telecommunication session of streamed media where the session is established by exchanging information about the session between at least two parties. Latter information about the session includes at least a session identifier and further session information with de- and encryption information for the streamed media. The method comprises the step to de- or encrypt the information about the session when exchanged between the two parties. Such step to de- or encrypt is performed in a particularly way keeping the session identifier in clear-text. In fact, only the de- or encryption information is de- or encrypted. Thereby, the
packets comprising the session identifier in clear-text when exchanged can be processed by the firewalls. Advantageously, this is possible by including into the session identifier which is kept in clear-text when exchanged address and port enabling the opening of pin-holes in the firewalls for letting through the streamed media of the telecommunication session. Such a method is particularly adapted for the establishment of telecommunication session of a streamed media being a SIP based VoIP telecommunication.
In an embodiment according to the invention, the session identifier and session information are defined using a description protocol, possibly Session Description Protocol (SDP). Advantageously, the de- or encryption information is exchanged in ciphertext as a description fragment. Possibly but not exclusively, the de- and encryption information includes a master key to be distributed between the parties in ciphertext i.e. to be unreadable by a third party when exchanged.
in accordance with another aspect of the invention, its object is achieved by a computer executable software code for establishing a telecommunication session of streamed media. The software code comprises code for establishing the session by exchanging information about the session between at least two parties. That information to be exchanged includes at least a session identifier and a further session information with de- and encryption information for said streamed media. The software code comprises further code to de- or encrypt the information about the session to be exchanged while keeping the session identifier in clear-text. In such a way, the most sensible information i.e. the de- and encryption information possibly but not exclusively including a master key will be exchanged in ciphertext. And the de- or encryption information is exchanged in ciphertext as a description fragment.
In accordance with a further aspect of the invention, its object is achieved by a client computer to be connected to the IP-network and comprising a communication unit for a party to perform a telecommunication session of streamed media via that IP-network. The client computer comprising a computer readable medium having a computer program recorded thereon. Such a computer program comprises advantageously the above code for establishing that telecommunication session.
Advantageous developments of the invention are described in the dependent claims, the following description and the drawings.
Description of the drawings
An exemplary embodiment of the invention will now be explained further with the reference to the attached drawings in which:
Fig. la and lb are schematic views of the establishment of a telecommunication session according to the prior art;
Fig. 2 is a schematic view of the establishment of a telecommuni-
cation session according to the present invention;
Fig. 3 is an example (listing) of the exchanged information about a
telecommunication session according the invention.
Detailed description of preferred embodiments
On figure la is shown two terminals 1, 2 corresponding to a telecommunication unit of each party to be used when establishing a telecommunication session of a streamed media. Such telecommunication unit 1, 2 can be a IP-phone or PC-based soft phones or any other kind of telecommunication unit even mobile one supporting SIP. In between the two telecommunication units 1, 2 defined as end points A respectively B is shown a wall depicting an application layer gateway (ALG) over firewall 3. According to the state of the art, when a telecommunication session of a streamed media is established signalling message with media description in SDP body has to be exchanged between the two endpoints A, B over the IP-network. Such signalling message will have to traverse at least one if not several firewalls like the one 3 shown on figure la. When reaching a firewall, the ALG reads the SDP boy and opens ports to let through the signalling for the establishment of the telecommunication session between the two end points A, B, i.e. the two telecommunication units 1, 2. Only then, the telecommunication session of a streamed media can be set up.
On figure lb is shown an alternative to the establishment of a telecommunication session according to figure la now with the exchange of de- and encryption
information for the streamed medio. The de- and encryption information here as an encryption key is defined as an SDP body itself protected using Secure Multipurpose Internet Mail extension (S/MIME) i.e. exchanged in ciphertext. Since the whole SDP body is S/MIME protected i.e. encrypted, the ALG of the firewall cannot read it. In that case, the firewall will not be able to open a port for letting through the streamed media of that telecommunication session. The establishment of such a telecommunication session of streamed media requiring de-and encryption information will simply fail.
In figure 2 is described schematically the way a telecommunication session of streamed media must be established according to the invention. In the present case, the information to be exchanged about the session includes at least a session identifier and further session information with de- and encryption information for said streamed media. Of course, the de- and encryption information must be still unreadable to o third party. This is obtained by encrypting the SDP body with the de- and encryption information here the key (possibly but not exclusively as master key required for the establishment of a secure telecommunications session) using S/MIME. But now and according to the invention the session identifier is kept in clear-text when exchanged. On the embodiment according to figure 2, such session identifier is exchanged in clear-text in a SDP body while the de- or encryption information is exchanged in ciphertext as a description fragment. The ALG is then able to read the required information from the SDP body. And this will allow to open a port on the corresponding firewall for letting through the secured streamed media of that telecommunication session.
The SDP fragment according to an embodiment of the invention is a subset of a SDP MIME body. It can be inserted in a message body that already contains a SDP body. It allows to let intermediaries read parts of SDP without compromising secured information that is in the SDP fragment. A SDP fragment is a MIME body of type 'message/sipfrog' (see RFC3420). It is required that this body has a Content-Disposition disposition-type of 'sipfrag', indicating that o fragment of a SIP message is enclosed. The Content-Disposition header should also contoin a 'handling' parameter indicating that this MIME body is optional (i.e. if this mechanism is not supported by the user agent server, it can still attempt to process the request).
On fig. 3 is shown an example in form of a listing of a request with a SDP fragment according to the invention comprising a full SIP invite request. The structure of the SIP message is defined in RFC3261/ RFC3264. It is a SIP message that is sent in order to start a media communication. The media shall be protected with secured RTP. The keys to secure the SRTP communication are sent within the SIP document.
The SIP message contains a SIP message body defined in RFC3420, emphasized with 11 on fig. 3. This message body "message/sipfrag" means that parts of a SIP message are enclosed as an attachment in a body of a SIP message. Typically, it can be used to copy a part of a SIP message and sign it or encrypt it. On fig. 3 is shown with 12 and 13 the multipart MIME format defined in RFC2387. This RFC defines how to enclose/nest attachments of various contents inside a message body (an email or a SIP message). Basically a multipart MIME encloses each attachment within boundaries and adds some headers in front of the attachment itself. These headers define the encoding (binary, base64, plain text, etc.) of the attachment and its nature (SDP, word document, fragment of a SIP message, ...]. These headers may also include information about the way the attachment is signed or encrypted. The Content-ID header defined in RFC1873 is shown with 14. This header contains a string of characters that is unique within a message body and that tags a MIME attachment. This string enables other attachments in the body to refer to this specific attachment. For instance, imagine that you include a MS-Word document as a MIME body in the message, and that you sign the document in order to ensure integrity protection. The signature of the document may be enclosed as a MIME body as well. The first MIME shall refer to the signature MIME thanks to a Content-ID string. Therefore the tool that reads the body upon reception of the message knows that the signature is related to the MS-Word document.
defines how a SDP parameter (a=crypto: shown in 15) transports SRTP keys inside a SDP message.
!n 16 and 18 of figure 3 are shown the main characteristics of on embodiment according to the present invention;
The inclusion of a cid parameter (16 is cid="bCYTG@secured.example.com") n the SDP parameter for SRTP keys that refers to a encrypted attachment (17) nstead of providing the SRTP keys. If the SRTP keys are enclosed plainly in the SDP body, then the whole SDP body would have to be S/MIME encrypted as defined in RFC3261. If the SDP body is encrypted, the Session border controllers that control NAT and firewalls cannot read/modify the ports/IP address of the SDP message and in consequence do not work. Therefore and according to the present invention, it is proposed to keep the SDP in deartext and put the really sensitive information (the SRTP keys) in a encrypted attachment, ii) The transmission of the SDP parameter with the SRTP keys that are to be protected (19) inside a sipfrag attachment (18) that is encrypted and signed .
***** : indicates that the contents inside the box are encrypted i.e. exchanged in cyphertext.
When a SDP offer or answer is sent, a SDP description should be inserted in the body. And the Secure SDP information must not be copied in the SDP body otherwise not being encrypted. The keying materiel is encrypted in another part of the body. The SDP body in clear text refers to the encrypted body. When receiving a SDP offer or answer, an intermediary may read the SDP body. The SDP body contains media addresses like IP-addresses and ports in clear text so that intermediaries (firewalls) may read it. The intermediar/ cannot read the SRTP keying material. If an attacker removes part of the SDP body then a firewall intermediary will not be able to open pin-holes. If an attacker changes the SDP fragment, it may force a firewall intermediary to open other pin-holes. Besides that, this mechanism is fully compatible with using a secure transport protocol (TLS or IpSec).
The implementation of the present invention has the advantage to ensure not only backward communication compatibility but also provide that session border controllers when present work with SIP communications that exchange SRTP keys for media protection. Session border controllers are necessary for protecting customer or operator data and voice networks from attacks by malicious parties.

Claims
1. A method for establishing a telecommunication session of streamed media, where the session is established by exchanging information about the session between at least two parties, said information about the session includes at least a session identifier and further session information with de- and encryption information for said streamed media, the method comprises the step to de- or encrypt the information about the session when exchanged, the method being further characterized by keeping the session identifier in cleartext, especially enabling firewalls to open a port for letting through the streamed media of that telecommunication session.
2. The method for establishing a telecommunication session according to claim 1 characterized by including into the session identifier in cleartext address and port enabling the opening of the required pin-hole in the firewalls.
3. The method for establishing a telecommunication session according to claim 1 characterized by the telecommunication session of streamed media being a Session Initiation Protocol based Voice over IP telecommunication.
4. The method for establishing a telecommunication session according to claim 1 characterized by including into the de- and encryption information a master key to be distributed between the parties possibly using Secure Real Time Protocol.
5. The method for establishing a telecommunication session according to claim 1 characterized by the session identifier and session information being defined using a description protocol, possibly Session Description Protocol, while
the de- or enciyption information is exchanged in ciphertext as a description fragment.
6. A computer executable software code for establishing a telecommunication
session of streamed media, the code comprises code for establishing the ses
sion by exchanging information about the session between at least two par
ties, said information about the session includes at least a session identifier
and further session information with de- and encryption information for said
streamed media, the software code comprises further code to de- or encrypt
the information about the session to be exchanged characterized in that
the code keeps the session identifier in cleartext, especially enabling firewalls
to open 0 port for letting through the streamed media of that telecommunica
tion session.
7. The computer code includes executable software code according to claim 6
characterized in that, the session identifier and session information being de
fined using a description protocol, possibly Session Description Protocol, while
the de- or encryption information is exchanged in ciphertext as a description
fragment.
8. A client computer to be connected to the IP-network and comprising a com
munication unit for a party to perform a telecommunication session of
streamed media via that IP-network, the client computer comprising a com
puter readable medium having a computer program recorded thereon, the
computer program comprising code for establishing the session by exchong-
ing information about the session with at least a further party, said informa
tion about the session includes at least a session identifier and further session
information with de- and encryption information for said streamed media, the
software code comprising further code to de- or encrypt the information
about the session to be exchanged characterized in that the code keeps
the session identifier in cleartext, especially enabling firewalls to open a port
for letting through the streamed media of that telecommunication session.
9. The client computer according to claim 8 characterized in that the session
identifier and session information being defined using a cleartext protocol,
possibly Session Description Protocol, while the de- or encryption information
is exchanged in ciphertext as a description fragment.