RFC 3329 (rfc3329) - Page 2 of 24
Security Mechanism Agreement for the Session Initiation Protocol (SIP)
Alternative Format: Original Text Document
RFC 3329 SIP Security Agreement January 2003 3. Backwards Compatibility . . . . . . . . . . . . . . . . . .11 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . .12 4.1 Client Initiated . . . . . . . . . . . . . . . . . . . .12 4.2 Server Initiated . . . . . . . . . . . . . . . . . . . .14 5. Security Considerations . . . . . . . . . . . . . . . . . .15 6. IANA Considerations. . . . . . . . . . . . . . . . . . . . .17 6.1 Registration Information . . . . . . . . . . . . . . . .17 6.2 Registration Template. . . . . . . . . . . . . . . . . .18 6.3 Header Field Names . . . . . . . . . . . . . . . . . . .18 6.4 Response Codes . . . . . . . . . . . . . . . . . . . . .18 6.5 Option Tags. . . . . . . . . . . . . . . . . . . . . . .19 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . .19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .19 9. Normative References . . . . . . . . . . . . . . . . . . . .19 10. Informative References . . . . . . . . . . . . . . . . . . 20 A. Syntax of ipsec-3gpp . . . . . . . . . . . . . . . . . . . .21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .23 Full Copyright Statement . . . . . . . . . . . . . . . . . . . .24 1. Introduction Traditionally, security protocols have included facilities to agree on the used mechanisms, algorithms, and other security parameters. This is to add flexibility, since different mechanisms are usually suitable to different scenarios. Also, the evolution of security mechanisms often introduces new algorithms, or uncovers problems in existing ones, making negotiation of mechanisms a necessity. The purpose of this specification is to define negotiation functionality for the Session Initiation Protocol (SIP) [1]. This negotiation is intended to work only between a UA and its first-hop SIP entity. 1.1 Motivations Without a secured method to choose between security mechanisms and/or their parameters, SIP is vulnerable to certain attacks. Authentication and integrity protection using multiple alternative methods and algorithms is vulnerable to Man-in-the-Middle (MitM) attacks (e.g., see [4]). It is also hard or sometimes even impossible to know whether a specific security mechanism is truly unavailable to a SIP peer entity, or if in fact a MitM attack is in action. In certain small networks these issues are not very relevant, as the administrators of such networks can deploy appropriate software versions and set up policies for using exactly the right type of Arkko, et. al. Standards Track
