plied by all the intermediate nodes along the whole path to the final destination. Obvi- ously, such a scenario will mandate the existence of a central PKI authority for SIP services as well as the deployment of cross-certification procedures between VoIP providers at a large scale. Moreover, the utilization of TLS pro- tocol by SIP servers comes at a considerable cost as the maintenance of many open TLS connections simultaneously may significantly reduce SIP servers' performance. Moreover, TLS does not support connectionless protocols, like UDP, that are actually implemented by most SIP clients today. In fact only a few clients support TLS today; among them are KPhone (http://www. kphone.org), Minisip (http://www.minsip.org) and hardware phones from Snom (http://www.snom.com). Secure Multipurpose Internet Mail Extensions (S/MIME) [26] is considered one of the most complete security suites for the application layer of the Internet architecture. It supports (a) authentication, (b) mes- sage integrity, (c) non repudiation of origin, and (d) confidentiality. Accord- ing to RFC 3261 [7], SIP messages could also include MIME protected parts. This means that the part of the SIP message that must be protected against any potential manipulation, is replicated in the MIME part (which is the Message Body) of the SIP message, in which S/MIME is applied to offer integrity, authentication or encryption services. However, as a result of spe- cific SIP restrictions [7] the S/MIME can be only applied to the parts of the SIP message that are not processed/modified by intermediate nodes (see also SIP-specific Security Restrictions). Furthermore, it is essential to stress that S/MIME introduces considerable overheads due to the cryptographic func- tions that it mandates. Currently, we are not aware of any commercial SIP clients supporting S/MIME. Summarizing, HTTP digest can only be utilized for client authentication without providing confidentiality or integrity. On the other hand, IPSec and TLS do offer confidentiality, integrity