SIP Security Roadmap SIP-based systems are subject to a number of attacks: - modification and replay of messages in transit; - denial-of-service attacks on proxy servers and UAs; - spam, i.e., unwanted, unauthenticated and untraceble requests; - REGISTER spoofing. Security threats can be divided into 'inside' and 'outside' threats (draft-thomas-sip-sec-framework-00). Inside threats are those caused by proxies or rogue UAs, while outside threats are posed by those able to listen to or modify messages in transit between SIP entities. In general, inside threats are not completely avoidable as long as the message requests an action from an intermediary, but the UAC cannot verify whether the action was taken. Currently, we have two security mechanisms, namely Basic and Digest authentication. A basic question is whether we develop a single security mechanism at the SIP level, e.g., based on encapsulation, or re-use and extend the existing mechanisms, namely - transport-layer - Authorization/WWW-Authenticate - encapsulation A particular concern is that there is likely going to be a range of trade-offs between - backward compatibility - message size (this, in particular, arises with encapsulation and duplication of information in variants of Digest) - implementation complexity * REGISTER spoofing Problem: An intruder can fake the Contact, From or To headers when replaying a REGISTER message and thus corrupt the registration entries, e.g., to cause SIP requests to be misrouted. Have: Digest authentication to authorize REGISTER requests. However, neither Basic nor Digest authentication protect request headers. Even in auth-int mode, they only protect the request URI, method and entity-body. Mechanisms for protecting other headers have been proposed, e.g., draft-undery-sip-digest-00 or [JR draft]. The former includes selected headers in the request, the latter prevents some kinds of replay attacks without modifying Digest, but does not prevent man-in-the-middle attacks. * Spam Protection Problem: For direct client-to-client messages, it is easy to send SIP requests with spoofed IP addresses. Standard authentication is not generally useful for unknown callers, as they don't share a secret with the callee. Thus, at minimum, it is desirable to be able to ascertain IP addresses, to allow blocking of such messages, e.g., from compromised hosts. This is also useful for handling denial-of-service attacks without committing state on the UAS. Have: ? Need: Simple authentication (e.g., draft-schulzrinne-sip-null-00.txt or a pre-defined Digest realm (e.g., "anonymous") with a zero-length password. However, it is more difficult in this mode to indicate both a real challenge for those callers who know the secret and an anonymous challenge, except by including two WWW-Authenticate lines. It may also be sufficient to redirect the request to a different URL, e.g., redirect alice@server.com to alice-H(some-headers:secret)@server.com. As long as a 3xx is returned immediately, without a 1xx, the server does not have to keep any state. The message overhead is the same. A third solution may be the use of To tags. Action: recommend in bis draft? * Additional authentication mechanism Problem: It may be desirable to allow additional challenge-response mechanisms, such as CHAP, in a SIP system. Have: draft-sterman-sip-radius-00, draft-byerly-sip-radius-00 Need: Discussion as to whether a direct support of CHAP in end systems is desirable. This clearly adds complexity without increase in security functionality. Given that existing implementations don't support this, it may be too late. (CHAP only makes sense if the RADIUS server does not also need to support Digest, so it forces every single device to use CHAP.) Action: resolve. * Securing messages in transit Problem: Messages between UA and proxies need to be secured against eavesdropping, replay and alteration. Have: IPsec and TLS offer this functionality. We have mechanism to discover transport protocols via DNS SRV, including TLS (draft-ietf-sip-srv-02.txt allows any transport protocol). Need: We need some mechanism to discover whether a path can be secured. This is difficult since one would need to establish a SIP meta-session ahead of time to ensure that the path of the 'real' request is the same as that of the 'scouting' request. It is probably easiest to add a Proxy-Require: SecureTransport, for example, as long as at least the first hop is secured. (Request-URIs can be rewritten, so including this in the URI doesn't make sense. We need to trust proxies not to lie about their forwarding, but that is unavoidable.) Here, Proxy-Require is correct, since we want the request to fail if any one of the proxies is not able to honor the feature requested. We currently cannot request directly that IPsec is to be used, but the mechanism above may be suitable as well. To find out whether the other side uses IPsec, sending the IKE or similar message and getting an error response is probably the easiest approach. Action: needs discussion. * Integrity protection for messages end-to-end See below. * End-to-end authentication In addition to the RFC 2617 mechanism, this can also be addressed by encapsulating the necessary information in MIME multipart messages (e.g, draft-thomas-sip-sec-framework-00). Need: A decision needs to be made whether the S/MIME mechanism or something else is appropriate. Possibly, the header values in S/MIME can be used and extended, to avoid double encapsulation. * Setting up keys for media sessions -> Jonathan, need reference to SRTP keying drafts.