Anexo I. Entrevistas a Docentes
ENTREVISTA A ESTUDIANTES HOJA DE RESPUESTAS
The Digest authentication scheme is based on a simple challenge-response paradigm. The digest authentication scheme challenges the remote end using a nonce value. SIP digest authentication is based on the digest authentication defined in RFC 2617 [18]. Here, a valid response contains a checksum (by default, the MD5 checksum) of the user name, the password, the given-once value, the HTTP method, and the requested URL. In this way, the password is never sent in the clear.
3.4.4
S/MIME Usage within SIP
SIP messages carry MIME bodies. MIME itself defines mechanisms for the integrity protection and the encryption of the MIME contents. SIP may
70 3.4 Session Initiation Protocol
utilize S/MIME to enable mechanisms such as public-key distribution, authentication and integrity protection, or confidentiality of SIP signaling data. S/MIME may be considered as a replacement for PGP used in RFC 2543 to provide means for integrity protection and encryption of SIP mes- sages. To be able to protect SIP header fields as well, tunneling of SIP mes- sages in MIME bodies is specified. Generally, the proposed SIP tunneling for SIP header protection will create additional overhead. S/MIME requires certificates and private keys to be used, whereas the certificates may be issued by a trusted third party or may be self-generated. The latter case may not provide real user authentication but may be used to provide a limited form of message integrity protection. The following sections explain the usage of S/MIME more deeply.
The current document RFC 3261 recommends that S/MIME be used for UAs. Moreover, if S/MIME is used to tunnel messages, it is recom- mended to use a TCP connection because of the larger messages. This is to avoid problems that may arise by the fragmentation of UDP packets. Ser- vices such as authentication, integrity protection, and confidentiality of sig- naling data are possible.
3.4.5
Confidentiality of Media Data in SIP
SIP itself does not consider the encryption of media data. Using the RTP encryption as defined in RFC 1889[19] may provide confidentiality for media data. Another option for media stream security is the use of SRTP (DSRTP). For key management, SDP (RFC 2327 [20]) may be used. SDP can convey session keys for media streams. Note that using SDP for the key exchange provides no method to send an encrypted media stream key (Appendix A). Therefore, the signaling request should be encrypted, prefer- ably by using end-to-end encryption.
3.4.6
TLS Usage within SIP
RFC 3261 mandates the use of TLS for proxies, redirect servers, and regis- trars to protect SIP signaling. Using TLS for UAs is recommended. TLS is able to protect SIP signaling messages against loss of integrity, confidential- ity, and replay. It provides integrated key management with mutual authen- tication and secure key distribution. TLS is applicable hop-by-hop between UAs/proxies or between proxies. The drawback of TLS in SIP scenarios is the requirement of a reliable transport stack (TCP-based SIP signaling). TLS cannot be applied to UDP-based SIP signaling.
3.4 Session Initiation Protocol 71
Chapter 3
3.4.7
IPsec Usage within SIP
IPsec may also be used to provide security for SIP signaling at the network layer. This type of security is most suited to securing SIP hosts in a SIP VPN scenario (SIP user agents/proxies) or between administrative SIP domains. IPsec works for all UDP, TCP, and Control Transmission Protocol (SCTP) SIP signaling. IPsec may be used to provide authentication, integrity, and confidentiality for the transmitted data and supports end-to-end as well as hop-by-hop scenarios. At this time there is no default cipher suite for IPsec defined in SIP. Note: RFC 3261 does not describe a framework for the use of IPsec. Especially, no information is given as to how the key management is to be realized or which IPsec header and mode are to be used.
3.4.8
Security Enhancements for SIP
Currently, within the IETF several drafts concerning security are being dis- cussed, with a view toward providing a general security solution to SIP sce- narios. Several drafts have been produced concerning authentication, integrity, and confidentiality for SIP. The following sections provide a short overview of Internet drafts, which may be of interest for a discussion of security enhancements for common SIP scenarios. The list of Internet drafts considered here is not complete and should rather reflect that this is an important topic, where work remains to be done.
3.4.9
SIP Authenticated Identity Body
SIP Authenticated Identity Body (AIB) defines a generic SIP authentication token. The token is provided by adding an S/MIME body to a SIP request or response in order to provide reference integrity over its headers. The doc- ument defines a format for this message body named as authenticated iden- tity body (AIB). This is a digitally signed SIP message (SIP/message) or message fragment (SIP/FRAG).
3.4.10
SIP Authenticated Identity Management
The existing mechanisms for expressing identity in SIP often do not permit an administrative domain to verify securely the identity of the originator of a request. This document recommends practices and conventions for authenticating end users and proposes a way to distribute cryptographically secure authenticated identities within SIP messages by including an authen-
72 3.4 Session Initiation Protocol
tication token (as a MIME body). This token is added to the message. There are basically three ways to add a MIME body to a request. They are:
Redirection
Authentication service acts as B2BUA
Content indirection
3.4.11
SIP Security Agreement
SIP has a number of security mechanisms. Some of them have been built in to the SIP protocol directly, such as HTTP authentication. These mecha- nisms have even alternative algorithms and parameters. The idea originates from the Third Generation Partnership Project (3GPP), a collaboration of telecommunications companies, and provides a mechanism for selecting which security mechanisms to use between two entities. RFC 3261 itself does not provide any mechanism agreement options. Moreover, even if some mechanisms, such as OPTIONS, were used to perform a mechanism agreement, the agreement would be vulnerable to bidding-down attacks. Three header fields are defined for negotiating the security mechanisms within SIP between a SIP entity and its next SIP hop. Five mechanisms are currently supported:
TLS
HTTP Digest
IPsec with IKE
Manually keyed IPsec without IKE
S/MIME
Connection Reuse
Connection reuse defines a method to reuse TCP connections that have already been established between a user agent and a proxy for the backward direction from the proxy to the client. The TLS security approach can also leverage from this, since clients often do not possess a certificate and corre- sponding private key. Thus, it would not be possible to open a TLS connec- tion to these clients (except via TLS anonymous mode).
3.4 Session Initiation Protocol 73
Chapter 3