Internet Engineering Task Force Internet Draft K. Umschaden J. Stadler I.Miladinovic draft-umschaden-smime-midcom-sip-proxy-00.txt IKN, Vienna University of Technology Expires: October 2003 May 2003 End-to-end Security for Firewall/NAT Traversal within the Session Initiation Protocol (SIP) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes an extension for the Session Initiation Protocol (SIP), which enables end-to-end security of the Session Description Protocol (SDP) together with firewall/Network Address Translation (NAT) traversal. This solution relies on Secure Multipurpose Internet Mail Extension (S/MIME) and the middlebox communications (MIDCOM) protocol. The user authorises a proxy server to encrypt the session description on behalf of the user. The proxy determines the capabilities of the receiving party and encrypts the SDP for a SIP proxy server in the receiving domain. Using MIDCOM, each proxy can dynamically control its firewall to open pinholes or request NAT bindings for the media flows. As long as each end-user may contact its trustworthy SIP proxy via a secure connection and authorise this proxy to encrypt the signalling data, the session information is secured end-to-end. Umschaden, et al. Expires - November 2003 [Page 1] End-to-end Security and FW/NAT within SIP May 2003 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. Overview of the Encryption Authentication Mechanism............3 4. Description of the Encryption Authentication Extension.........4 4.1 Architecture...............................................5 4.2 Registration...............................................5 4.3 Session Establishment......................................8 4.3.1 Session Establishment Example.........................9 5. SIP Extension Syntax..........................................32 5.1 New SIP Header Field......................................32 5.2 New Response Code.........................................34 Security Considerations..........................................34 References.......................................................35 1. Introduction On the one hand, Network Address Translation (NAT) and firewall traversal for the Session Inititation Protocol (SIP) [3] is a task that is very complex itself. Most solution proposals like Application Layer Gateways (ALGs) and the Middlebox Control (MIDCOM) Protocol [4] rely on the inspection or even modification of session information carried by SIP. According to the session information carried by SIP a proxy server or an ALG opens and closes firewall pinholes or generates and destroys NAT bindings. On the other hand, session data is sensitive information that end- users and primarily domain administrators would like to keep hidden to protect their privacy. SIPS, which enforces a secured path only works hop-by-hop for SIP. This provides proxies in potential untrusted domains, residing between the communication endpoints, with session information that can be altered or just collected. The only way to prevent this is to use end-to-end security. Secure Multipurpose Internet Mail Extension (S/MIME) allows the users to encrypt SIP messages end-to-end. In that case, no intermediary proxy or ALG can inspect the session data and control the firewall/NAT respectively. As long as end-to-end encryption with Secure Multipurpose Internet Mail Extension (S/MIME) secures SIP from sending UA to the receiving UA, no intermediary proxy or ALG can inspect the session data and control the firewall/NAT respectively. K. Umschaden, et. al. Expires - November 2003 [Page 2] End-to-end Security and FW/NAT within SIP May 2003 These two goals, firewall/NAT traversal and end-to-end security seem to contradict. However, this is the critical goal that has to be achieved in some manner. There exist other solution proposals for middlebox traversal that rely on the UA to control the middlebox with firewall or NAT service via MIDCOM or get around this problem using Simple Traversal of UDP NAT (STUN) [8] or Traversal Using Relay NAT (TURN) [9] environments. These attempts would allow the UA to encrypt SIP end-to-end. Indeed, the implementation of STUN/TURN need a solution that every UA can open and close firewall pinholes. This decentralization of firewall/NAT control is not favorable from a security point of view. This would open the protected network for viruses and backdoors, which could abuse the firewall/NAT traversal abilities. Our solution is based on S/MIME [5] for the encryption of session information. Indeed, it is not the UA of the communicating party that encrypts the Session Description Protocol (SDP) [6], which rather authorises a so-called security proxy that performs this operation on the communicating partyÆs behalf. Additionally, the security proxy is responsible for the preparation of the firewall/NAT. Therefore, it might be co-located with a middlebox, which results in an ALG. Another variant is to control the middlebox via MIDCOM protocol. 2. Terminology This document uses the terminology of SIP [3] and MIDCOM [4]. Additionally, the following term is specified: Security Proxy, Sec-Proxy: A SIP proxy server that with registrar functionality that supports the proposed extension. This means that the SIP proxy possesses a X.509 server certificate whose common name (CN) attribute of the subject matches the server name. Furthermore, the proxy is capable to encrypt and sign SDP using the S/MIME standard and to control a middlebox that implements a firewall or a NAT service. 3. Overview of the Encryption Authentication Mechanism This SIP extension helps to secure SIP messages end-to-end. Participated parties are the sending UA, the S/MIME capable security proxy that can control the middleboxes of the sending domain, a security proxy in the receiver domain and the receiving UA. This overview outlines basically how end-to-end security of SDP can be guaranteed, in cases a firewall and/or NAT resides between the communicating UAs. We assume that the SDP is carried only in INVITE and 200 OK messages, not in provisional responses or ACK requests. K. Umschaden, et. al. Expires - November 2003 [Page 3] End-to-end Security and FW/NAT within SIP May 2003 As long as the sending UA and the respective security proxy reside in the same domain, they may secure their interactions in an arbitrary way. Arkko, et. al. describe a way to agree upon such a security mechanism.[10] The UA authorises its security proxy to encrypt messages for the sender. This is performed by adding a new header field that contains the hostname of the security proxy. The UA is responsible for the tunnelling of the integrity of this header field to the receiving UA. The security proxy that is authorised to encrypt the message on the userÆs behalf will determine the receiving UAs capabilities and configuration. Additionally, it queries NAT bindings for the session to establish at the middlebox of the sender domain. The security proxy will replace all private IP addresses and TCP/UDP ports in the SDP. Afterwards, it encrypts the SDP for the security proxy in the receiving domain. Each SIP proxy forwards the message downstream until it arrives at the security proxy responsible for the receiving domain. This proxy decrypts the SDP and pastes the server name of the security server that encrypted the SDP into an additional header field. It controls the middlebox according to the encrypted SDP. Using a secure connection, it forwards the message to the receiving UA. The receiving UA is capable of checking the integrity of the sending security proxy. If the SIP message was encrypted by a security proxy that has not been authorised by the sending UA, it will generate a warning message for the user, who will most probably refuse the request. However, if the sender authorised the security proxy that encrypted the SDP, the receiver can be sure that the SDP message was neither read nor modified by any untrusted third party. The receiving UA generates a response including a header field that authorises its security proxy to encrypt the SDP of the response. The security proxy opens the firewall pinholes and queries NAT bindings according to the SDP. It substitutes private IP addresses and UDP/TCP ports of the SDP by global ones according to the result of the NAT query. Afterwards, it encrypts the SDP for the security proxy of the caller domain and forwards the SIP response upstream. The security proxy in the caller domain decrypts the SDP, updates the middlebox and forwards the SIP message to the calling UA. This UA generates an ACK message and transmits it to the receiving UA in an unencrypted manner. 4. Description of the Encryption Authentication Extension This section illustrates the encryption authentication extension in more detail. Firstly, we will outline the architecture of this K. Umschaden, et. al. Expires - November 2003 [Page 4] End-to-end Security and FW/NAT within SIP May 2003 extension. Secondly, the registration process for this extension is described. Thirdly, the session setup will be described. We will illustrate the session establishment with SIP example messages. We do not provide a call termination scenario, as this is just a removal of the created middlebox rules for the SIP session and described in [4] section 7. 4.1 Architecture Figure 1 illustrates the basic architecture of encryption authentication. In the caller domain as well as in the receiver domain there exists a UA, a SIP proxy that supports this extension and most probably a firewall and/or NAT. The SIP proxy is capable to control the firewall/NAT; e.g. using the MIDCOM protocol. It is possible that the extension aware SIP proxy server is co- located with the firewall/NAT. Then the firewall/NAT is capable of processing SIP, which is equivalent to a SIP ALG. Furthermore, the SIP proxy may be located outside the user domain. As long as the UA can contact its SIP proxy directly via a secure connection, the SIP proxy may reside outside the user domain. The signalling path from the UA to the SIP proxy MUST be secured in this scenario to maintain the desired end-to-end security. Again, the proxy must be capable of controlling the firewall/NAT in such manner. ............................ ........... ............................ . . . . . . . Caller domain . . Un- . . Receiver domain . . . . trusted . . . . . . domain . . . . . . . . . .+--+ +-----+ +---+ +---+ +-----+ +--+. .| || SIP |<-SIP-->|FW |<-SIP->|FW |<--SIP->| SIP |<-SIP>| |. .| | |Proxy| |and| |and| |Proxy| | |. .|UA| | |MIDCOM=>| / | | / |<=MIDCOM| | |UA|. .| | +-----+ |or | |or | +-----+ | |. .| |<~~~~~~~RTP~~~~~~~~~>|NAT|<~RTP~>|NAT|<~~~~~~~~~RTP~~~~~~~>| |. .+--+ +---+ +---+ +--+. . . . . . . ............................ ........... ............................ Figure 1: Basic architecture 4.2 Registration K. Umschaden, et. al. Expires - November 2003 [Page 5] End-to-end Security and FW/NAT within SIP May 2003 SIP gracefully offers terminal mobility, which is very powerful. However, indicating that the end-user is available at different terminals requires that the registration process occurs at a central point which is independent of the actual terminal. This is the registrar server of the user. We assume that this registrar is located in the domain of the userÆs personal VoIP service provider. Another option might also be the registrar of the user's enterprise or any other publicly available registrar. It is possible that the user resides in a different domain than his registrar server, as he updates the location with his enterprise desktop in the morning and with his home terminal in the evening, which will - most probably - be not the same domain. A security proxy MUST be able to act as registrar. Therefore, the user may use its security proxy as registrar server. As the necessary processing power for the encryption and decryption of SDP is processing power intensive, it would be a good approach to use a registrar server for global availability and the security proxy for middlebox traversal. Figure 2 illustrates this architecture. This allows that the registrar of the user does not need to support the proposed extension nor the MIDCOM protocol. It is the security proxy that performs the processing power intensive encryption and decryption of SDP and MIDCOM control. As all the signalling messages MUST traverse the security proxy to enable it to investigate the SDP to provide end-to-end security, a two-step registration is required. ............................... ................................. . . . . . VoiIP Service Provider . . Enterprise . . or . . . . Global Availability Server . . . . . . . . +---------+ +---+ +-----+ +--+ . . |SIP |<--SIP-->|FW/|<--SIP-->|Sec- |<--SIP-->|UA| . . |Registrar| |NAT| |Proxy| | | . . +---------+ +---+ +-----+ +--+ . . . . . ............................... ................................. Figure 2: Registration architecture The two-step registration is performed in the following manner: As outlined before, a security proxy offers registrar functionality. First, the UA registers at a security proxy. Afterwards, the userÆs address-of-record at this security proxy is used as contact address to register at the userÆs registrar. This procedure ensures that incoming session invitations traverse the security proxy. To assure K. Umschaden, et. al. Expires - November 2003 [Page 6] End-to-end Security and FW/NAT within SIP May 2003 that SDP of outgoing requests are encrypted, outgoing session invitations MUST also be routed via this proxy. First, the UA sends an OPTIONS request to obtain the certificate of the security proxy. As this requests MUST contain a certificate, the UA SHOULD structure the body as an S/MIME "multipart/signed" CMS SignedData body, as declared in [3], section 23.2. Additionally, the UA discovers whether the SIP proxy supports the proposed extension. When the UA already holds a certificate of the security proxy and knows that it supports the extension, this request can be omitted. The security proxy responds with a 200 OK. This message will contain the server certificate of the proxy in an S/MIME "multipart/signed" CMS SignedData body. The common name (CN) attribute in the subject of the received certificate contains the server name of the SIP security proxy. If the security server supports the proposed extension, it has to indicate this in the supported header field in the response to the OPTIONS request. This looks like Supported: Encr-Src If the sec-proxy does not declare that it supports the Encr-Src extension, the UA SHOULD assume that the proxy does not support the extension and alert the user about this. If the security proxy supports the extension, it is able to act as security proxy. The user registers at the security proxy, which MUST be able to process REGISTER requests. It is RECOMMENDED that the UA uses a secure connection for the registration. The registration process is explained in detail in [3], section 10. If the userÆs registrar is the security proxy of the user, the registration process is terminated. If the user's registrar is located at a different machine - maybe even in a different domain than the user's security proxy - until now, the UA is only registered at its security proxy. Therefore, it is necessary to register at the userÆs registrar too. The UA sends a second register message, this time the destination of the request is the user's registrar. The user tries to register at its registrar with the address-of-record from the security proxy. This will result in a routing of all incoming SIP messages for the user towards the user's security proxy. We RECOMMEND that both, the security proxy and the registrar, challenge the user for authentication before updating the location data. After this two-step registration, all incoming SIP messages will traverse the user's security proxy. Note, that all outgoing SIP messages MUST be routed via the security proxy too. K. Umschaden, et. al. Expires - November 2003 [Page 7] End-to-end Security and FW/NAT within SIP May 2003 4.3 Session Establishment ............................... ................................ . . . . . atlanta.com . .biloxy.com . . . . . UA1 Sec-Proxy1 FW/NAT1 FW/NAT2 Sec-Proxy2 UA2 Alice sec-proxy gateway middlebox sip-bastion bob | | | | | | |--F1.INVITE--->| | | | | | |++++++++++++F2.OPTIONS++++++++++++>| | | | | | |+++++++F2+++++>| | | | | |<++++++F3++++++| | |<+++++++++++F3.200 OK++++++++++++++| | | | | | | | | |++++++++++++F4.OPTIONS++++++++++++>| | | |<+++++++++++F5.200 OK++++++++++++++| | | | | | | | | |=F6.MIDCOM==>| | | | | | | | | | | |************F7.INVITE*************>| | | | | | | | | | | |<=F8.MIDCOM==| | | | | | |---F9.INVITE-->| | | | | |<--F10.200 OK--| | | | |<=F11.MIDCOM=| | | | | | | | | |<***********F12.200 OK*************| | | | | | | | | |=F13.MIDCOM=>| | | | |<--F14.200 OK--| | | | | |---F15.ACK---->| | | | | | |------------F16.ACK--------------->| | | | | | |----F17.ACK--->| | | | | | | |<~~~~~~~~~~~~~~~~RTP~~~~~~~~>|<~RTP~>|<~~~~~~~~RTP~~~~~~~~~~~~~~~~>| | | | | | | +++ ... SIP message, S/MIME signed *** ... SIP message, SDP S/MIME encrypted --- ... not encrypted SIP message ~~~ ... RTP/RTCP === ... MIDCOM protocol Figure 3: Two-step registration This section treats the establishment of a session. In the case where the callee resides behind a middlebox and supports the proposed extension and the caller uses S/MIME encrypted SDP to establish a K. Umschaden, et. al. Expires - November 2003 [Page 8] End-to-end Security and FW/NAT within SIP May 2003 call, the call setup will fail because the middlebox cannot prepare the media path. Therefore, the callee SHOULD respond with a 421 Extension Required response that contains a require header field indicating that the sender SHOULD use this proposed extension for a secure session setup. Alternatively, if the caller does not support this extension, the caller can use SIPS for hop-by-hop security or use plain SDP for the session establishment. If the caller supports the proposed extension, figure 3 describes the message flow according to the architecture from figure 1. The example does not include any intermediary proxies between the security proxy of the sender domain and the security proxy of the receiver domain. Most probably all requests will be routed through several other SIP proxies, which are not drawn in figure 3. These proxies do not influence the behaviour in any case, as they cannot read or modify the encrypted SDP. They will just forward the SIP messages down- resp. upstream. Further, the scenario does not contain any provisional responses (response code 1xx). They are omitted to keep the example more intuitive. 4.3.1 Session Establishment Example In the following paragraphs, we will explore the message flow in more detail. UA1 resides behind a firewall and/or NAT. We assume that it has registered as described above. Additionally, we make the assumption that each middlebox forwards incoming traffic on port 5060 to the security proxy of the domain. If UA1 tries to set up a media session securely, it will send an INVITE to its sec-proxy. The UA authorises its sec-proxy by adding a new header field Encr-Src (Encryption Source) to the request. This header field contains only the server name of the proxy that is authorised to encrypt the SDP on behalf of the UA. The host header field value MUST match the common name attribute of the subject in the sec-proxy's S/MIME server certificate that has been received during registration. The UA MUST tunnel the integrity of Encr-Src header field to the receiving UA in order that the callee can determine if the encrypting proxy server was authorised to perform the encryption. Together with the Encr-Src header field the UA MUST tunnel the Date header field to prevent that an authorised server can reuse the authorisation for other requests it is not authorised anymore, e.g. some kind of replay attack. Beside the Encr-Src and the Date header field, the UA MAY additionally tunnel other SIP header fields that need end-to-end encryption to the callee. The sensitive "message/SIP" MIME body MUST be signed with a CMS detached signature as described in RFC 2361, section 23.4.2. The general integrity tunnelling of SIP header fields is described in RFC 2361, section 23.4. K. Umschaden, et. al. Expires - November 2003 [Page 9] End-to-end Security and FW/NAT within SIP May 2003 UA1 wants to transmit the SDP, which is of type "application/sdp". Moreover, UA1 wants to send the "multipart/signed" MIME body containing the tunnelled SIP header fields. Therefore, it MUST create a "multipart/mixed" content, which carries the SDP and a signed "message/sip" MIME body. The structure of the message is illustrated in figure 4. UA1 is responsible for a secure transmission of the INVITE to its security proxy. SDP investigations from trusted parties have to occur on the path between UA1 and its sec-proxy. It is obvious, that after the encryption of the SDP, it is not possible to inspect or alter the SDP data. The sec-proxy SHOULD challenge the UA for authentication purpose. +----- multipart/mixed | | application/SDP (plain SDP) | +----- | +-- multipart/signed | | | | message/sip (tunnelled SIP header fields) | | | +-- | | signature of tunnelled SIP header fields | +-- +----- Figure 4: Structure of SIP message body carrying SDP and tunnelled header fields The following example is an INVITE from Alice to Bob. Alice routes the INVITE towards her security proxy using a pre-loaded Route header field. Additionally, she authorises this security proxy to encrypt the SDP for her by adding an Encr-Src header field. The signed message contains a date and the Encr-Src header fields with the name of the authorised server. The content-length of the example has not been calculated; therefore this header field value is set to "...". F1 INVITE UA1 -> Sec-Proxy1 INVITE sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TLS 192.168.0.133;branch=z9hG4bKnas12f8 Max-Forwards: 25 To: From: ; tag=456222 Call-ID: df49df90s8d Contact: K. Umschaden, et. al. Expires - November 2003 [Page 10] End-to-end Security and FW/NAT within SIP May 2003 CSeq: 1 INVITE Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sec-proxy.atlanta.com Route: Content-Type: multipart/mixed; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: application/sdp v=0 o=Alice 2890844111 2890844222 IN IP4 192.168.0.133 s=Session SDP c=IN IP4 192.168.0.133 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --outer-boundary Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=header-boundary --header-boundary Content-Type: message/sip Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sec-proxy.atlanta.com --header-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --header-boundary- --outer-boundary- The sec-proxy receives the INVITE with the Encr-Src header field containing its hostname. Therefore, it is authorised to modify and encrypt the SDP on behalf of the user. K. Umschaden, et. al. Expires - November 2003 [Page 11] End-to-end Security and FW/NAT within SIP May 2003 First it is necessary to discover whether the opposite UA supports the proposed extension. If the callee also resides behind a firewall or NAT, it is necessary to receive additional information regarding its security proxy. Therefore, sec-proxy1 queries the receiver about its capabilities. This OPTIONS contains a require header field indicating that the opposite UA MUST support the Encr-Src extension to successfully process the request. This happens - to prevent downgrade attacks - with a signed message. If the public key of the target user is known, sec-proxy1 MAY additionally encrypt the message. Finally, sec-proxy1 appends its S/MIME server certificate. Note that the certificate is included in the CMS SignedData body and therefore not shown. Again, the content-length of the example has not been calculated; the content-length header field value is set to "...". F2 OPTIONS Sec-Proxy1 -> UA2 OPTIONS sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKnappe1 Max-Forwards: 25 To: From: ; tag=990099 Call-ID: rs8943jdf804s Contact: CSeq: 1 OPTIONS Date: Thu, 25 Mar 2003 13:23:13 GMT Require: Encr-Src Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: message/sip OPTIONS sip:bob@biloxy.com SIP/2.0 To: From: ; tag=990099 Call-ID: rs8943jdf804s Contact: CSeq: 1 OPTIONS Date: Thu, 25 Mar 2003 13:23:13 GMT Require: Encr-Src --outer-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required K. Umschaden, et. al. Expires - November 2003 [Page 12] End-to-end Security and FW/NAT within SIP May 2003 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --outer-boundary- UA2 receives a signed message carrying a server certificate. However, note that traditional SIP UAs do not know S/MIME server certificates. If UA2 does not support the required Encr-Src extension, it will respond with 420 Bad Extension and enumerate the unsupported extensions of the request. If the receiving UA supports the required extension, but the server certificate of the security proxy has been revoked or is expired, the root certification authority (CA) of the certificate is not known and the validity of the certificate can therefore not be checked, or the common name attribute of the certificate subject does not match the name of the security proxy, the UA SHOULD render an appropriate warning message to the user. If the UA supports the extension, succeeds with the certificate check (or the user has explicitly accepted the certificate) and is idle for new calls, the response will be an encrypted 200 OK. This response SHOULD include a supported header field containing the Encr-Src tag. If the receiving UA does not reside behind a firewall and/or NAT, it MUST NOT add an Encr-Src header field. This will indicate that it supports the extension, but is not located behind a NAT. On the other hand, if the UA is located behind a firewall and/or NAT, it MUST append an Encr-Src header field containing the hostname of the proxy server that is authorised to encrypt the SDP for UA2. The header field value MUST be identical with the common name (CN) attribute of the subject of the sec-proxy's server certificate. UA2 SHOULD respond with a signed message. This ensures that intermediaries cannot change the message, especially the Encr-Src header field value, because sec-proxy1 can verify the integrity of the message. In the example, the content length is not provided; we inserted "..." instead. F3 200 OK UA2 -> Sec-Proxy1 SIP/2.0 200 OK Via: SIP/2.0/TCP sip-bastion.biloxi.com;branch=z9hG4bKowboy1 ;received=100.100.100.103 Via: SIP/2.0/TCP 1984.globalfind.com;branch=z9hG4bKanne1 ;received=100.100.100.102 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKnappe1 K. Umschaden, et. al. Expires - November 2003 [Page 13] End-to-end Security and FW/NAT within SIP May 2003 ;received=100.100.100.101 To: ; tag=234ff234 From: ; tag=990099 Accept: application/sdp, multipart/* Accept-Encoding: gzip Accept-Language: en Allow: ACK, BYE, CANCEL, INVITE, OPTIONS Call-ID: rs8943jdf804s Contact: CSeq: 1 OPTIONS Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com Supported: Encr-Src Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: message/sip SIP/2.0 200 OK To: ; tag=234ff234 From: ; tag=990099 Accept: application/sdp, multipart/* Accept-Encoding: gzip Accept-Language: en Allow: ACK, BYE, CANCEL, INVITE, OPTIONS Call-ID: rs8943jdf804s Contact: Contact: CSeq: 1 OPTIONS Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com Supported: Encr-Src --outer-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --outer-boundary- K. Umschaden, et. al. Expires - November 2003 [Page 14] End-to-end Security and FW/NAT within SIP May 2003 When the result of the OPTIONS request to the receiving UA is 420 Bad Extension, the security proxy MUST generate a 420 Bad Extension response for UA1. In this case, UA1 will never succeed to establish a connection using this extension, as long as the receiver does not move to another terminal that supports this extension. However, it is possible to contact the receiver using a SIPS URI. Then the signalling path will be secured hop-by-hop. Alternatively, the user can skip the encryption of SDP. When sec-proxy1 receives a 200 OK from the receiver, it checks the integrity of the message. If the identity of the callee cannot be determined because of a problem with the certificate, the security proxy will respond to its UA with a new error code 610 Potential Security Breach. This response code is described in section 5.2. Additionally, the security proxy will indicate the reason through a cert-warning in the Encr-Src header field, which is described in section 5.1. The relevant certificate is a user certificate, therefore the value of cert-type is set to usercert. If the certificate is self-signed, the sec-proxy will set the value of cert- problem to selfsigned, if the root CA of the certificate is unknown to the security proxy, it will set the value of cert-problem to unknownroot. If the certificate is expired or revoked, the sec-proxy will set the value of cert-problem to the respective value. The message flow in these cases is illustrated in figure 5. UA1, which receives this response, MUST render an appropriate warning to the user who wants to establish the session. The user MAY also use SIPS to contact the receiver. In this case, the signalling path will be secured on a hop-by-hop basis. Alternatively, the user MAY decide to setup the session regardless of the problems with the certificates. Then the UA will start with F1.INVITE again, explicitly indicating that broken certificates shall be ignored. The user can set the optional sec-flag of the Encr-Src header field. The value "offensive" indicates that the security proxy MUST establish a session even if a certificate poses problems. If the sec-flag is set to "secure" or left out, this indicates that the security proxy MUST NOT proceed the session establishment when a certificate is not OK. The sec-flag is described in section 5.1. If the certificate is valid and UA2 supports the Encr-Src extension, but no Encr-Src header field is contained in the signed "message/sip" MIME type, UA2 is not located behind a firewall/NAT. However, it supports the extension and may be contacted directly by the sec- proxy. The security proxy will send the F7. INVITE including the encrypted SDP directly to UA2. This UA will check the certificates of both, the sender and the security proxy of the sender domain. The certificate of the security proxy MUST contain the server name of the security proxy in the common name (CN) attribute of the subject. Otherwise, the certificate is not valid and UA2 SHOULD render an K. Umschaden, et. al. Expires - November 2003 [Page 15] End-to-end Security and FW/NAT within SIP May 2003 appropriate warning message to the callee. If both certificates are valid or the user explicitly accepts the certificates, UA2 responds with a 200 OK containing an SDP encrypted for the security proxy. The security proxy will control the middlebox and create a response to UA1 containing the SDP. If the certificate of the callee poses problems, the security proxy will add appropriate cert-warnings to the Encr-Src header field. This scenario is illustrated in figure 6. ............................... ............................... . . . . . atlanta.com . .biloxy.com . . . . . UA1 Sec-Proxy1 FW/NAT1 FW/NAT2 Sec-Proxy2 UA2 Alice sec-proxy gateway middlebox sip-bastion bob | | | | | | |----F1.INVITE->| | | | | | |++++++++++++F2.OPTIONS++++++++++++>| | | | | | |+++++++F2+++++>| | | | | |<++++++F3++++++| | |<+++++++++++F3.200 OK++++++++++++++| | |<---610--------| | | | | |----ACK------->| | | | | | | | | | | +++ ... SIP message, S/MIME signed --- ... not encrypted SIP message Figure 5: Unsuccessful session establishment If UA2 supports the Encr-Src extension and the response additionally contains an Encr-Src header field, its value contains the hostname of the server that is authorised to act as sec-proxy for the receiving party. This hostname was extracted from the certificate the callee got from its sec-proxy at registration. Sec-proxy1 performs a lookup at its internal keyring, whether it knows the public key of the authorised proxy. In this case, F4 and F5 may be skipped. The message F2 can be left out if the certificate of the callee is already known and the callee is definitely located behind a known security proxy that supports this extension. If the certificate is not known or the user may not be located behind a particular security proxy, F2 and F3 cannot be omitted. When the public key of sec-proxy2 is unknown, an OPTIONS request containing the certificate of sec-proxy1 is needed to obtain the certificate of sec-proxy2. Sec-proxy1 SHOULD send a signed OPTIONS request to receive the certificate of the sec-proxy residing in the receiver domain. The certificate is contained in the CMS of the "multipart/signed" message body. K. Umschaden, et. al. Expires - November 2003 [Page 16] End-to-end Security and FW/NAT within SIP May 2003 F4 OPTIONS Sec-Proxy1 -> Sec-Proxy2 Sec-proxy2 receives a request that is signed by another server. Therefore, it MUST be capable of validating S/MIME server certificates. Sec-proxy2 MUST check the certificate for validity. As UA2 already inspected the certificate, it should not happen that the certificate has been revoked or the root CA is unknown. If the certificate is not valid, it is up to the security server policies whether it generates a response to the request or not. ............................... .............. . . . . . atlanta.com . . biloxy.com . . . . . UA1 Sec-Proxy1 FW/NAT1 . UA2 Alice sec-proxy gateway . bob | | | . | |---F1.INVITE-->| | . | | |++++++++++F2.OPTIONS++++++++++>| | |<+++++++++F3.200 OK++++++++++++| | | | . | | |=F6.MIDCOM==>| . | | | | . | | |**********F7.INVITE***********>| | |<*********F12.200 OK***********| | | | . | | |=F13.MIDCOM=>| . | |<--F14.200 OK--| | . | |---F15.ACK---->| | . | | |----------F16.ACK------------->| | | | . | |<~~~~~~~~~~~RTP~~~~~~~~~~~~~>|<~~~~~RTP~~~~~~~>| | | | . | +++ ... SIP message, S/MIME signed *** ... SIP message, SDP S/MIME encrypted --- ... not encrypted SIP message ~~~ ... RTP/RTCP === ... MIDCOM protocol Figure 6: Session establishment without midlebox in one domain Because UA2 included the hostname of sec-proxy2 in the Encr-Src header field value, this server should support the proposed extension. Usually, sec-proxy2 responds with a signed 200 OK. The signed MIME body SHOULD contain all sensitive information to prevent a downgrade attack. Sec-proxy2 MUST indicate that it supports this K. Umschaden, et. al. Expires - November 2003 [Page 17] End-to-end Security and FW/NAT within SIP May 2003 extensions. It SHOULD respond with a "multipart/signed" message body that includes its server certificate in the CMS SignedData body. F5 200 OK Sec-Proxy2 -> Sec-Proxy1 The security proxy has identified the security proxy of the callee and received its server certificate. Whether the session setup continues or not depends on the user intentions, which are expressed using the encr-flag of the Encr-Src header field in F1. INVITE. If the value of the encr-flag is set to "offensive", the user wants to continue the session establishment, even if a certificate is invalid. Therefore, the security proxy will continue the session establishment. It will just append a cert-warning in the Encr-Src header field in F14. 200 OK to inform the caller. ............................... ................................ . . . . . atlanta.com . .biloxy.com . . . . . UA1 Sec-Proxy1 FW/NAT1 FW/NAT2 Sec-Proxy2 UA2 Alice sec-proxy gateway middlebox sip-bastion bob | | | | | | |----F1.INVITE->| | | | | | |++++++++++++F2.OPTIONS++++++++++++>| | | | | | |+++++++F2+++++>| | | | | |<++++++F3++++++| | |<+++++++++++F3.200 OK++++++++++++++| | | | | | | | | |++++++++++++F4.OPTIONS++++++++++++>| | | |<+++++++++++F5.200 OK++++++++++++++| | |<---610--------| | | | | |----ACK------->| | | | | | | | | | | Figure 7: Unsuccessful session establishment If the encr-flag is absent or its value is set to "secure", the user does not want that the sec-proxy continues the session establishment if a certificate might be broken. Therefore, sec-proxy1 will act in the following way: If the identity of the proxy in the receiver domain cannot be determined because of a problem with the certificate, the security proxy MUST respond to its UA with a new error code 610 Potential Security Breach. This response code is described in section 5.2. Additionally, the security proxy will indicate the reason through an cert-warning in the Encr-Src header field, which is described in section 5.1. The relevant certificate is a server certificate; therefore the value of cert-type is set to servercert. If the certificate is self-signed, the sec-proxy will set the value of cert-problem to selfsigned, if the root CA of the K. Umschaden, et. al. Expires - November 2003 [Page 18] End-to-end Security and FW/NAT within SIP May 2003 certificate is unknown to the security proxy, it will set the value of cert-problem to unknownroot. If the certificate is expired or revoked, the sec-proxy will set the value of cert-problem to the respective value. These scenarios are illustrated in figure 7. It is evident, that messages F4 and F5 are only necessary if the security proxy does not hold a proper certificate of the opposite security proxy. Depending on the policies and the architecture of the sender domain, sec-proxy1 will reserve some NAT bindings or prepare firewall pinholes for the requested media sessions carried in the SDP of F1. This is performed using a protocol that conforms to the MIDCOM protocol architecture. In the case of a middlebox implementing NAT service, the SDP contains private, only locally valid IP addresses and TCP/UDP ports. The security proxy will create a port binding via MIDCOM to assign these local ports to global ones. Then the sec-proxy MUST substitute the private IP addresses in the SDP with the assigned global ones. Otherwise, the UA will not receive any media. Additionally, confidential information about the internal network structure could get publicly available. In the case of a firewall, the corresponding UDP/TCP ports have to be opened that media streams can traverse the firewall and are not dropped. F6 MIDCOM - NAT/firewall control These functions can be performed concurrently with F2-F5. Then it MUST be assured, that when the session establishment is cancelled, the NAT bindings are removed and the firewall pinholes are closed. After the SDP changes the security proxy MUST encrypt the SDP with the key of sec-proxy2. Then it MUST sign the encrypted SDP. This "multipart/signed" body and the "multipart/signed" body containing the tunneled SIP header fields from F1 are packed into a "multipart/mixed" message. The structure of this message is illustrated in figure 8. Additionally, it MUST remove Record-Route and Via header fields from the message for privacy reasons. These header fields will be restored when the response traverses sec-proxy1. The Contact header field MUST NOT provide secret data about the sender. Therefore, the private IP addresses MUST be substituted by global ones or the Contact header field MUST be removed. The sec-proxy SHOULD also remove the Encr-Src header field. Then it forwards the message to the next SIP proxy downstream towards sec-proxy2. Each proxy on the route forwards the message until sec-proxy2 is reached. K. Umschaden, et. al. Expires - November 2003 [Page 19] End-to-end Security and FW/NAT within SIP May 2003 +------- multipart/mixed | +---- multipart/signed | | +- application/pkcs7-mime; smime-type=enveloped-data | | | | | | application/SDP (encrypted SDP) | | | | | +- | +---- | | signature of encrypted SDP | +---- +------- | +---- multipart/signed | | | | message/sip (tunnelled SIP header fields) | | | +---- | | signature of tunnelled SIP header fields | +---- +------- Figure 8: Structure of SIP message body between security proxies F7. IVITE contains the encrypted SDP. The text boxed in asterisks ("*") is encrypted by sec-proxy1 for sec-proxy2. Note that the IP address and the ports have changed in the SDP. Additionally, the contact header field has changed, as Alice is globally available at the security proxy. The Via header field that contains only local valid IP addresses has been removed from the request too. Sec-proxy1 has added a Record-Route header field, as it desires to get all the messages that belong to this session. The content length has not been calculated. Instead, we use three points. F7 INVITE Sec-Proxy1 -> Sec-Proxy2 INVITE sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKnappe3 Max-Forwards: 24 To: From: ; tag=456222 Call-ID: df49df90s8d Contact: CSeq: 1 INVITE Date: Thu, 25 Mar 2003 13:23:13 GMT Record-Route: Content-Type: multipart/mixed; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: multipart/signed; K. Umschaden, et. al. Expires - November 2003 [Page 20] End-to-end Security and FW/NAT within SIP May 2003 protocol="application/pkcs7-signature"; micalg=sha1; boundary=SDP-boundary --SDP-boundary Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m; handling=required Content-Length=... ******************************************************* * Content-Type: application/sdp * * v=0 * o=Alice 2890844111 2890844222 IN IP4 gateway.atlanta.com * s=Session SDP * c=IN IP4 gateway.atlanta.com * t=0 0 * m=audio 27002 RTP/AVP 0 * a=rtpmap:0 PCMU/8000 * ******************************************************* --SDP-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --SDP-boundary-- --outer-boundary Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=header-boundary --header-boundary Content-Type: message/sip Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sec-proxy.atlanta.com --header-boundary K. Umschaden, et. al. Expires - November 2003 [Page 21] End-to-end Security and FW/NAT within SIP May 2003 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --header-boundary-- --outer-boundary-- A security proxy handles all incoming requests for its registered users that carry an encrypted and signed SDP for the security proxy. If the incoming request does not contain an Encr-Src header field, sec-proxy2 MUST add an Encr-Src header field. If the request contained an Encr-Src header field, the header field value has to be modified. The corresponding Encr-Src header field value MUST be set to the server name of the proxy that encrypted the request. This is the common name attribute in the subject of the verified server certificate of the server that encrypted the message. Note, that in most cases, the outer and inner Encr-Src header field values will be identical. If this it not the case, it is likely that the server that has encrypted the message was not authorised to do so. In any case, the proxy SHOULD NOT refuse to forward the message because of this circumstance. Only the callee decides whether to accept or refuse an incoming session invitation. The security proxy decrypts the SDP of the request and substitutes the encrypted SDP of the incoming INVITE request with a plain version. If the certificate of the sec-proxy that encrypted the SDP poses a problem, the security proxy will add a cert-warning to the Encr-Src header field, which is described in detail in section 5.1. The security proxy MUST set the value of cert-type to servercert, as the server certificate of the opponent security server poses the problem. Depending on this problem, the value of cert-problem will be set to expired, revoked, selfsigned or unknownroot respectively. Note, that certificate problems should not occur, as an OPTIONS request with the certificate of the security proxy of the caller domain should have arrived before. The security proxy has to open the firewall and request a NAT binding for the private-to-external RTP/RTCP flows before the INVITE is relayed to UA2. It performs this to allow "early media" from UA2 before UA responds with 200 OK. Details are described in [4]. K. Umschaden, et. al. Expires - November 2003 [Page 22] End-to-end Security and FW/NAT within SIP May 2003 F8. MIDCOM - NAT/firewall control Sec-proxy2 SHOULD forward the INVITE over a secure connection to UA2. As the message contains SDP and tunnelled SIP header fields, the security proxy MUST structure the message as "multipart/mixed" as illustrated in Figure 4. If any mandatory SDP investigations have to occur, this can only be performed between sec-proxy2 and UA2. In our example, sec-proxy2 has added a Record-Route header field, as it needs to get all the messages that belong to this session. F9 INVITE Sec-Proxy2 -> UA2 INVITE sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TCP sip-bastion.biloxi.com;branch=z9hG4bKugel3 Via: SIP/2.0/TCP 1984.globalfind.com;branch=z9hG4bKanne3 ;received=100.100.100.102 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKnappe3 ;received=100.100.100.101 Max-Forwards: 22 To: From: ; tag=456222 Call-ID: df49df90s8d Contact: CSeq: 1 INVITE Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sec-proxy.atlanta.com Record-Route: Record-Route: Content-Type: multipart/mixed; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: application/sdp v=0 o=Alice 2890844111 2890844222 IN IP4 middlebox.biloxi.com s=Session SDP c=IN IP4 middlebox.biloxi.com t=0 0 m=audio 22022 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --outer-boundary Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=header-boundary --header-boundary Content-Type: message/sip K. Umschaden, et. al. Expires - November 2003 [Page 23] End-to-end Security and FW/NAT within SIP May 2003 Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sec-proxy.atlanta.com --header-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --header-boundary-- --outer-boundary-- UA2 receives the INVITE. First it will notice cert-warnings in the Encr-Src header field if the certificate of the security proxy residing in the caller domain was invalid or could not be revised. In these cases, the UA MUST render an appropriate warning to the callee. The INVITE contains the certificate of the sender, as the sender signed at least the Encr-Src and the Date header fields. The UA MUST check the certificate and render appropriate warnings if necessary to the callee. UA2 also verifies the integrity of the inner, tunnelled header fields that have been signed by the originator. The UA MUST compare the inner and outer Encr-Src header fields according to section 5.1. Note that only the hostname part of the header field MUST be identical in a case-sensitive way. If the inner (signed) and outer Encr-Src header field values do not match, UA2 SHOULD render an appropriate warning to the callee. [3], section 23.4.1.1 describes details for the integrity check of tunnelled header field values. For the Date header field, all rules from [3] apply. If the user accepts the call, UA2 sends a 200 OK to its sec-proxy2. An Encr-Src header field MUST be added. The header field value MUST contain the common name attribute of the subject from the server certificate the UA got from its security proxy at registration. This header field value contains the server names of all servers that are authorised to encrypt SDP on behalf of the UAÆs user. If any SDP investigations have to occur, these have to be performed before the request is forwarded to Sec-Proxy2. However, the UA is responsible for a secure transmission of the 200 OK to its security proxy. K. Umschaden, et. al. Expires - November 2003 [Page 24] End-to-end Security and FW/NAT within SIP May 2003 UA2 adds a Route header field that indicates that the message is routed directly to the security proxy of the callee. The message carries again plain SDP and integrity tunnelled SIP header fields. Therefore UA2 MUST structure the message as illustrated in figure 4. The content-length of the message is not provided. F10 200 OK UA2 -> Sec-Proxy2 SIP/2.0 200 OK Via: SIP/2.0/TLS sip-bastion.biloxi.com;branch=z9hG4bKugel3 ;received=10.0.0.10 Via: SIP/2.0/TCP 1984.globalfind.com;branch=z9hG4bKanne3 ;received=100.100.100.102 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKnappe3 ;received=100.100.100.101 To: ; tag=2344hz2 From: ; tag=456222 Call-ID: df49df90s8d Contact: CSeq: 1 INVITE Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com Record-Route: Record-Route: Route: , Content-Type: multipart/mixed; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: application/sdp v=0 o=Bob 2890844112 2890844223 IN IP4 10.0.0.44 s=Session SDP c=IN IP4 10.0.0.44 t=0 0 m=audio 44004 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --outer-boundary Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=header-boundary --header-boundary Content-Type: message/sip Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com K. Umschaden, et. al. Expires - November 2003 [Page 25] End-to-end Security and FW/NAT within SIP May 2003 --header-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --header-boundary- --outer-boundary- As it was the case for the originating domain, the destination domain also has to prepare the middleboxes for incoming media sessions. Therefore, sec-proxy2 has to demand IP address and port bindings for NAT or firewall pinholes in the case of a firewall. If the domain relies on both techniques, the security proxy has to perform both. F11 MIDCOM - NAT/firewall control Afterwards, sec-proxy2 updates the SDP according to the firewall/NAT state and encrypts it for sec-proxy1. Then it signs the SDP. As the resulting message will transport a "multipart/signed" encrypted SDP body and a "multipart/signed" body containing the tunnelled SIP header fields, the security proxy MUST combine these two parts to a "multipart/mixed" MIME body as illustrated in figure 8. For privacy reasons, the security proxy MUST remove Record-Route and Via header fields. These header fields will be re-added to the ACK request, when it passes at this security proxy. Additionally, sec- proxy2 SHOULD remove the Encr-Src header field. The example below illustrates that the Contact header field value has changed to a global available SIP addresss. The content-length is not calculated for the example. After these modifications, sec-proxy2 forwards the 200 OK to the next SIP proxy upstream. Proxies on the route between the security proxies just forward the message until sec-proxy1 is reached. F12 200 OK Sec-Proxy2 -> Sec-Proxy1 SIP/2.0 200 OK Via: SIP/2.0/TCP 1984.globalfind.com;branch=z9hG4bKanne3 ;received=100.100.100.102 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKnappe3 ;received=100.100.100.101 K. Umschaden, et. al. Expires - November 2003 [Page 26] End-to-end Security and FW/NAT within SIP May 2003 To: ; tag=2344hz2 From: ; tag=456222 Call-ID: df49df90s8d Contact: CSeq: 1 INVITE Date: Thu, 25 Mar 2003 13:23:13 GMT Record-Route: Record-Route: Route: Content-Type: multipart/mixed; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=SDP-boundary --SDP-boundary Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m; handling=required Content-Length=... ******************************************************* * Content-Type: application/sdp * * v=0 * o=Bob 2890844112 2890844223 IN IP4 mediagw.biloxy.com * s=Session SDP * c=IN IP4 mediagw.biloxy.com * t=0 0 * m=audio 27808 RTP/AVP 0 * a=rtpmap:0 PCMU/8000 ******************************************************* --SDP-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --SDP-boundary-- K. Umschaden, et. al. Expires - November 2003 [Page 27] End-to-end Security and FW/NAT within SIP May 2003 --outer-boundary Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary=header-boundary --header-boundary Content-Type: message/sip Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com --header-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --header-boundary-- --outer-boundary-- Sec-proxy1 receives a SIP response that has been signed and encrypted by sec-proxy2. If sec-proxy1 cannot decrypt the SDP, it will terminate the call. This SHOULD be performed by sending an ACK request immediately followed by a BYE to UA2. Besides, it will respond to UA1 with a 420 Bad Extension. Otherwise, the sec-proxy decrypts the SDP of the response and substitutes the encrypted SDP with a plain version. If the response does not contain an Encr-Src header field, it MUST add an Encr-Src header field. On all accounts, the Encr-Src header field value MUST be set to the server name from the certificate of the encryption source. This is the common name attribute of the server certificateÆs subject attribute. If the user initiated the request with an encr-flag "offensive" and a certificate of the receiver domain was invalid or could not be checked, the security proxy continues with the call establishment. Therefore the information about broken certificates has to be transported to the caller. The security proxy will add an appropriate cert-warning to the Encr-Src header field. It will set the value of cert-type to usercert or servercert and the value of cert-problem to expired, revoked, selfsigned or unknownroot respectively. K. Umschaden, et. al. Expires - November 2003 [Page 28] End-to-end Security and FW/NAT within SIP May 2003 Additionally, sec-proxy1 MUST add the Record-Route and Via header fields that have been removed from F1.INVITE. The response may contain an SDP that contains different session information than the request. Therefore, sec-proxy1 MUST update the firewall/NAT according to the returned, decrypted SDP. F13 MIDCOM - NAT/firewall control The security proxy updates the SDP according to the results from the middlebox implementing firewall or NAT service. As the response contains this plain SDP body and a "multipart/signed" CMS SignedData body carrying the SIP header fields, these bodies will be collected in a "multipart/mixed" MIME body as illustrated in figure 4. Sec-proxy1 forwards the response to its UA. This SHOULD happen in a secure manner. The example below demonstrates that TLS is an example for such a secure connection. The security proxy MUST re-add all stripped Via header fields. F14 200 OK Sec-Proxy1 -> UA1 SIP/2.0 200 OK Via: SIP/2.0/TLS 192.168.0.133;branch=z9hG4bKnas12f8 To: ; tag=2344hz2 From: ; tag=456222 Call-ID: df49df90s8d Contact: CSeq: 1 INVITE Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com Record-Route: Record-Route: Content-Type: multipart/mixed; boundary=outer-boundary Content-Length: ... --outer-boundary Content-Type: application/sdp v=0 o=Bob 2890844112 2890844223 IN IP4 gateway.atlanta.com s=Session SDP c=IN IP4 gateway.atlanta.com t=0 0 m=audio 25880 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --outer-boundary Content-Type: multipart/signed; K. Umschaden, et. al. Expires - November 2003 [Page 29] End-to-end Security and FW/NAT within SIP May 2003 protocol="application/pkcs7-signature"; micalg=sha1; boundary=header-boundary --header-boundary Content-Type: message/sip Date: Thu, 25 Mar 2003 13:23:13 GMT Encr-Src: sip-bastion.biloxy.com --header-boundary Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --header-boundary-- --outer-boundary-- First of all, UA1 inspects potential cert-warning parameters in the Encr-Src header field. If the F1. INVITE request has been sent using the sec-flag "offensive", the security proxy continued with the session setup even if a certificate was invalid. It just appended adequate cert-warning parameters in the Encr-Src header field. These warnings SHOULD be rendered to the caller. Secondly, UA1 has to check the validity of the certificates from the response. If one of the certificates is expired or has been revoked, or the root CA is unknown, an appropriate warning SHOULD be rendered to the user. If the Encr-Src header field contains a cert-warning, the UA SHOULD render an appropriate warning to the user too. Additionally, the UA checks the integrity of the inner SIP header fields. For this purpose, the UA MUST remove all header parameters of the inner and outer Encr-Src header field. Subsequently, the UA MUST compare the two header fields, which just contain the hostname of the authorised security server. This comparison is described in [3], section 23.4.1.1. Additionally, the Date header field and other integrity protected header fields MUST be checked. For the Date header field, all rules from [3] apply. If the caller decides that he does not want to proceed with the call because of a rendered warning (cert-warning, broken header field integrity), the UA will terminate the call by sending an ACK request followed by a BYE. K. Umschaden, et. al. Expires - November 2003 [Page 30] End-to-end Security and FW/NAT within SIP May 2003 In any case, UA1 sends an ACK to UA2. As long as no SDP packets are carried by an ACK request, the Encr-Src header field is not needed here. Therefore, UA1 SHOULD NOT send the ACK with an Encr-Src header field. Note that the ACK MUST NOT be sent end-to-end encrypted, as long as stateful proxies like the security proxies on the signalling path wait for the ACK. F15 ACK UA1 -> Sec-Proxy1 ACK sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TLS 192.168.0.133;branch=z9hG4bKnockOut1 Max-Forwards: 25 To: ; tag=2344hz2 From: ; tag=456222 Call-ID: df49df90s8d CSeq: 1 ACK Date: Thu, 25 Mar 2003 13:23:13 GMT Route: , Content-Length: 0 F16 ACK Sec-Proxy1 -> Sec-Proxy2 ACK sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKumKum1 Max-Forwards: 24 To: ; tag=2344hz2 From: ; tag=456222 Call-ID: df49df90s8d CSeq: 1 ACK Date: Thu, 25 Mar 2003 13:23:13 GMT Route: Content-Length: 0 Sec-proxy2 has to restore the Record-Route and Via header fields that have been removed from F12. 200 OK. F17 ACK Sec-Proxy2 -> UA2 ACK sip:bob@biloxy.com SIP/2.0 Via: SIP/2.0/TLS sip-bastion.biloxi.com;branch=z9hG4bKugel21 Via: SIP/2.0/TCP sec-proxy.atlanta.com;branch=z9hG4bKumKum21 ;received=100.100.100.101 Max-Forwards: 22 To: ; tag=2344hz2 From: ; tag=456222 Call-ID: df49df90s8d CSeq: 1 ACK Date: Thu, 25 Mar 2003 13:23:13 GMT K. Umschaden, et. al. Expires - November 2003 [Page 31] End-to-end Security and FW/NAT within SIP May 2003 5. SIP Extension Syntax This section describes the changes to the current protocol. We will introduce the Encr-Src header field that is used by UAs to authorise a security proxy to encrypt the SDP for the user. Additionally, we will specify a new response indicating a potential security breach. 5.1 New SIP Header Field This extension introduces a new header field that authorises a proxy server to encrypt and decrypt SDP on behalf of the user. This authorisation is granted using the Encr-Auth header field. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [7]. Encr-Src = "Encr-Src" HCOLON host [";" encr-flag] *( ";" cert-warning ) encr-flag = "offensive" / "secure" cert-warning = cert-type EQUAL cert-problem cert-type = "usercert" / "servercert" cert-problem = "expired" / "revoked" / "selfsigned" / "unknowroot" / "mismatch" In this extension, the values of encr-flag are restricted to the above option, although further options may be defined in the future. If the encr-flag is present in the Encr-Src header field, it can only take one of the above values. These values are: offensive: The user requests that the security proxy MUST try to establish the session, even if the certificates of the callee or the security proxy in the receiving domain are invalid or cannot be validated. If these certificates pose a problem, an appropriate cert-warning will be added to the header field of the result to inform the user about the state of each certificate. secure: The user requests that the security proxy MUST NOT continue with the session establishment if the security proxy cannot validate a certificate or the certificate is invalid. A 610 Potential Security Breach response will be generated containing the appropriate cert-warning. A missing encr-flag indicates that the user wants the "secure" solution. The security proxy MUST NOT contact the callee if a certificate is possibly broken. A cert-warning indicates that a problem with a certificate occurred. If a security proxy detects an abnormality with a certificate, it transfers this information to its UA. It is possible that either the K. Umschaden, et. al. Expires - November 2003 [Page 32] End-to-end Security and FW/NAT within SIP May 2003 certificate of the communication partner or the certificate of the opposite security proxy poses the problem. The cert-type defines which certificate is not OK. usercert: The certificate of the communication partner is not OK. servercert: The certificate of the security proxy of the communication partner poses problems. The cert-problem can be one of the following: expired: The certificate is expired, it is not valid anymore. revoked: The certificate is revoked, therefore it is not valid. selfsigned: The certificate is valid, but it is self signed, which indicates that the identity of the certificate holder cannot be determined. unknownroot: The certificate is valid, but the root certification authority is not known. Therefore it cannot be determined if the certificate is trustworthy or not. The identity of the certificate holder is not assured. mismatch: The server name does not match the common name (CN) attribute of the server certificate subject, or the end-user certificate does not identify the address-of-record of the communication partner, respectively. Each combination of the cert-type and cert-problem is possible, even multiple cert-warnings can occur. A UA receiving a request or response that contains a security warning MUST inform the user about the security risk of the broken certificate chain. Note that the integrity check of this header field MUST be performed in the following manner: All header field parameters, i.e. encr-flag and cert-warning MUST be removed. The result will be just the header field name and the hostname of the authorised server. After removing the header field name, which is case-insensitive, the result is solely the hostname. This value MUST be compared simply byte-by-byte. This document adds the following entry to Table 2 of [3]: Header field where proxy ACK BYE CAN INV OPT REG MSG ------------ ----- ----- --- --- --- --- --- --- --- Encr-Src R amdr - - - o - - - Encr-Src 2xx amdr - - - o o - - K. Umschaden, et. al. Expires - November 2003 [Page 33] End-to-end Security and FW/NAT within SIP May 2003 SUB NOT REF INF UPD PRA --- --- --- --- --- --- - - - - - - - - - - - - We have decided that this extension does not support encryption of SDP in provisional responses, ACK and UPDATE requests. Maybe this will be added in later in the future. 5.2 New Response Code There is a new approach in this document that authorises a server with the encryption and decryption of S/MIME messages. Until now, the UA of the user performed these operations and could directly alert possible security breaches to the user. This is not possible for this extension. Therefore, we introduce a new response code 610 Potential Security Breach. 610 Potential Security Breach This response indicates that there has been a potential security hazard that cannot be detected by the UA itself. Therefore, this message is returned to the caller. For this extension, a 610 response carries at least one cert-warning in the Encr-Src header field. This status response does not indicate in any sense whether a communication partner is willing to accept a request or not, it just outlines potential security problems. Security Considerations It is necessary to analyse possible security holes that this document introduces. First of all, it is obvious, that the introduction of server certificates might bring some incompatibilities with existing UA implementations. Existing UA receive messages that contain message bodies that are signed by two different parties. Anyway, the UA should be capable of verifying at least the user certificate. If both communication partners support this extension, the SDP is secured end-to-end. Each UA communicates via a secure connection, preferably TLS or IPSec with its security proxy. There are no attack scenarios on IPSec or TLS, as long as the server uses a certificate to prove its identity for the TLS connection establishment and challenges the client via digest authentication. The particular security proxy inspects the SDP and controls the middleboxes with firewall and NAT service using the MIDCOM protocol. This procedure is as safe as the respective protocol in use for K. Umschaden, et. al. Expires - November 2003 [Page 34] End-to-end Security and FW/NAT within SIP May 2003 MIDCOM. If the network administrator does not like to use a MIDCOM protocol, it is possible to co-locate security proxy and middlebox. Then the middlebox control is performed locally on the middlebox, which resembles a traditional ALG. The security proxy queries the callee for its capabilities using a signed SIP message. This signed message proves that the request cannot be changed. The result will again be signed which prevents downgrade attacks - intermediaries cannot change the response that the security proxy cannot determine the UAÆs capabilities. The same procedure is performed for the security proxy in the receiver domain. Note again that these messages can be omitted if all certificates are known and the security proxy in the caller domain knows the security proxy of the receiver. The security proxy will alert the user if any certificates are not valid or cannot be checked. The user may try to contact the receiver via SIPS in such a case, if he thinks that this is more secure. If the identities of the receiver and its security proxy have been proven or the user explicitly likes to establish the session even if the certificates are potentially broken, the security proxy encrypts the SDP and signs it. This message is forwarded through the untrusted domain until it reaches the receiver domain. Each intermediary is able to record signalling messages that have passed, but session information is kept secret. If TLS is selected as transport medium via SIPS URIs, intermediaries like routers that are no SIP proxy servers cannot log any signalling information as this is secured between the SIP proxies residing on the signalling path. The caller signs the Encr-Src header field together with a Date header field. This helps the user to revoke the authorisation from the security server and move e.g. to an alternate provider. As long as the Date header field informs the sender about the date and time of the authorisation, the authorisation is needed for each SIP session and cannot be reused for another session after some time. Clearly, the security server could use the authorisation to setup another simultaneous session with the authorisation of the user. Therefore it is necessary to really trust the security server. Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. K. Umschaden, et. al. Expires - November 2003 [Page 35] End-to-end Security and FW/NAT within SIP May 2003 3 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. 4 Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox Communication Architecture and Framework", RFC 3303, August 2002. 5 Ramsdell B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. 6 Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. 7 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997. Informative References 8 Rosenberg, J.,Weinberger, J, Huitema, C, Mahy, R, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003 9 Rosenberg, J.,Weinberger, J, Mahy, R, Huitema, C, "Traversal Isng Relay NAT(TURN)", Work in Progress 10 Arkko, J., Torvinen, V., Camarillo, G., Niemi A. and T. Haukka, "Security Mechanism Agreement for the Session Initiation Protocol (SIP)", RFC 3329, January 2003. Author's Addresses Klaus Umschaden Institute of Communication Networks Vienna University of Technology Favoritenstrasse 9/388 A-1040 Vienna, Austria Email: Klaus.Umschaden@tuwien.ac.at Johannes Stadler Institute of Communication Networks Vienna University of Technology Favoritenstrasse 9/388 A-1040 Vienna, Austria Email: Johannes.Stadler@tuwien.ac.at K. Umschaden, et. al. Expires - November 2003 [Page 36] End-to-end Security and FW/NAT within SIP May 2003 Igor Miladinovic Institute of Communication Networks Vienna University of Technology Favoritenstrasse 9/388 A-1040 Vienna, Austria Email: Igor.Miladinovic@tuwien.ac.at Umschaden, et. al. Expires - November 2003 [Page 37]