RFC 3329
Security Mechanism Agreement for the Session Initiation Protocol (SIP)
RFC 3329: Security Mechanism Agreement for the Session Initiation Protocol (SIP) 🎀
bestie, this one is the Category: Standards Track doc 📜 It was written by J. Arkko, V. Torvinen, and G. Camarillo from Ericsson, plus A. Niemi and T. Haukka from Nokia, and it's dated January 2003 🌸 The title block doesn't list any Obsoletes or Updates entries, so it's its own thing and doesn't replace or patch anything 💅
Status of this Memo 🦋
This document specifies an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) ✨ Distribution of this memo is unlimited 🌈
Copyright Notice 🫶
Copyright (C) The Internet Society (2003). All Rights Reserved. 💜
Abstract ✨
okay so this doc adds a brand new trick 🪄 It lets a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity negotiate which security mechanisms they'll use with each other 🔐 It's giving "extra layer" energy, because it sits on top of the methods SIP entities already had for picking security mechanisms between themselves 🎀
1. Introduction 🌸
ngl security protocols have always come with a way to agree on the mechanisms, algorithms, and other security parameters being used 🤝 That's because different mechanisms fit different scenarios, so flexibility is the whole point 💖 And security keeps evolving, with new algorithms showing up or problems being found in old ones, so being able to negotiate mechanisms is basically a necessity 😭
The purpose of this specification is to define negotiation functionality for the Session Initiation Protocol (SIP) [1] 🦋 This negotiation is only meant to work between a UA and its first-hop SIP entity, so it's a very focused little handshake 🧚
1.1 Motivations 💅
Without a secured way to choose between security mechanisms and/or their parameters, SIP is open to certain attacks 🙈 If authentication and integrity protection can use multiple alternative methods and algorithms, it becomes vulnerable to Man-in-the-Middle (MitM) attacks (e.g., see [4]) 💀 Not okay!
It's also hard, or sometimes even impossible, to tell whether a specific security mechanism is actually unavailable to a SIP peer entity, or whether a MitM attack is secretly happening 😱
In certain small networks these issues aren't really a big deal, because the administrators can deploy the right software versions and set up policies for using exactly the right type of security 👑 But SIP is also expected to be deployed to hundreds of millions of small devices with little or no possibility of coordinated security policies, let alone software upgrades 🥺 That's why the negotiation functionality needs to be available from the very beginning of deployment (e.g., see [11]) 🌈
1.2 Design Goals 🎯
Here's what the security agreement process is supposed to do, bestie:
- The entities involved in the security agreement process need to find out exactly which security mechanisms to apply, preferably without excessive additional roundtrips ✨
- The selection of security mechanisms itself needs to be secure 🔥 Traditionally, all security protocols use a secure form of negotiation. For instance, after establishing mutual keys through Diffie-Hellman, IKE sends hashes of the previously sent data, including the offered crypto mechanisms [8] 🔑 This lets the peers detect whether the initial, unprotected offers were tampered with 🕵️♀️
- The entities involved in the security agreement process need to be able to indicate success or failure of the security agreement process 🎀
- The security agreement process should not introduce any additional state to be maintained by the involved entities 🍓
1.3 Conventions 📖
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 BCP 14, RFC 2119 [9] 💜 These are the official capital-letter requirement words, so read them carefully, periodt 💅
2. Solution 🧚
2.1 Overview of Operation 🗺️
Here's the message flow that shows how the mechanism in this document works 👀
1. Client ----------client list---------> Server
2. Client <---------server list---------- Server
3. Client ------(turn on security)------- Server
4. Client ----------server list---------> Server
5. Client <---------ok or error---------- Server
Figure 1: Security agreement message flow.Step 1: Clients who want to use this specification can send a list of their supported security mechanisms along with the first request to the server 📨
Step 2: Servers who want to use this specification can challenge the client to perform the security agreement procedure 🛡️ The security mechanisms and parameters the server supports get sent along in this challenge 🎀
Step 3: The client then picks the highest-preference security mechanism they have in common with the server, and turns on the selected security 🔐
Step 4: The client contacts the server again, now using the selected security mechanism 🦋 The server's list of supported security mechanisms gets returned as a response to the challenge ✨
Step 5: The server checks its own list of security mechanisms to make sure the original list hadn't been modified 🕵️♀️ Integrity check, iconic! 🌈
This procedure is stateless for servers, unless the security mechanisms in use require the server to keep some state 🧠
The client and the server lists are both static. That means they don't, and can't, change based on what the other side sends 🙅♀️ Nodes may, however, maintain several static lists, one for each interface, for example 🍓
Between Steps 1 and 2, the server may set up a non-self-describing security mechanism if it's necessary. Note that with this type of security mechanism, the server is necessarily stateful 🧚 The client would set up the non-self-describing security mechanism between Steps 2 and 4 💖
2.2 Syntax 🎀
okay bestie, so we're adding three brand new SIP header fields 💅: Security-Client, Security-Server, and Security-Verify. The grammar uses the Augmented BNF from SIP [1], and anything not defined in this section is defined in SIP and the documents it points to 🫶
security-client = "Security-Client" HCOLON
sec-mechanism *(COMMA sec-mechanism)
security-server = "Security-Server" HCOLON
sec-mechanism *(COMMA sec-mechanism)
security-verify = "Security-Verify" HCOLON
sec-mechanism *(COMMA sec-mechanism)
sec-mechanism = mechanism-name *(SEMI mech-parameters)
mechanism-name = ( "digest" / "tls" / "ipsec-ike" /
"ipsec-man" / token )
mech-parameters = ( preference / digest-algorithm /
digest-qop / digest-verify / extension )
preference = "q" EQUAL qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] )
/ ( "1" [ "." 0*3("0") ] )
digest-algorithm = "d-alg" EQUAL token
digest-qop = "d-qop" EQUAL token
digest-verify = "d-ver" EQUAL LDQUOT 32LHEX RDQUOT
extension = generic-paramNote that qvalue is already defined in the SIP BNF [1]. We copied its definitions here so everything's in one spot ✨
The parameters in that BNF have these semantics 🌸
Mechanism-name 🔐 This token names the security mechanism. When it shows up in a Security-Client header field, it's the client's supported mechanism. When it's in a Security-Server or Security-Verify header field, it's the server's. The mechanism-name tokens are registered with the IANA, and this spec defines four values:
- "tls" for TLS [3].
- "digest" for HTTP Digest [4].
- "ipsec-ike" for IPsec with IKE [2].
- "ipsec-man" for manually keyed IPsec without IKE.
Preference 💜 The "q" value shows how much a mechanism is preferred compared to the others. Higher means more preferred. All the security mechanisms MUST have different "q" values. Giving two mechanisms the same "q" value is an error, no cap 🙅♀️
Digest-algorithm 🍓 This one's optional, and it's only defined for HTTP Digest [4]. Its job is to stop the bidding-down attack on the HTTP Digest algorithm parameter. The content can have the same values that [4] defines for the "algorithm" field.
Digest-qop 🌈 Also optional and only for HTTP Digest [4], again to stop bidding-down, this time on the HTTP Digest qop parameter. The content can have the same values that [4] defines for the "qop" field.
Digest-verify 🛡️ This optional parameter is only defined for HTTP Digest [4], and it's there to stop the bidding-down attack on the SIP security mechanism agreement (this document, bestie) 😭 The value is calculated exactly like "request-digest" in [4], with one twist: the Security-Server header field gets included in the A2 parameter. If the "qop" directive's value is "auth" or isn't specified at all, then A2 is:
A2 = Method ":" digest-uri-value ":" security-serverIf the "qop" value is "auth-int", then A2 is:
A2 = Method ":" digest-uri-value ":" H(entity-body) ":"
security-serverBefore calculating or interpreting the digest-verify parameter, every linear white space in the Security-Server header field MUST be replaced by a single SP. Method, digest-uri-value, entity-body, and any other HTTP Digest parameter work as specified in [4] 🫧
Lowkey the most important bit: this spec does not add any extension or change to HTTP Digest [4]. It just re-uses the existing HTTP Digest mechanisms to protect the negotiation of security mechanisms between SIP entities. Not reinventing the wheel, periodt 🛞
2.3 Protocol Operation 🦋
This section is all about the protocol details of the negotiation between a SIP UA and its next-hop SIP entity. Throughout the text, that next-hop SIP entity is called the first-hop proxy or outbound proxy. Just keep in mind that a user agent server can also be the next-hop for a user agent client 👑
2.3.1 Client Initiated 📤
If a client ends up using TLS to contact the server because it followed the rules in [5], the client MUST NOT use the security agreement procedure of this specification. If a client ends up using non-TLS connections because of the rules in [5], the client MAY use the security agreement of this specification to detect DNS spoofing, or to negotiate some other security than TLS 🕵️♀️
A client that wants to use the security agreement of this specification MUST add a Security-Client header field to a request addressed to its first-hop proxy (meaning the request's destination is the first-hop proxy). That header field lists all the security mechanisms the client supports. The client SHOULD NOT add preference parameters to this list. The client MUST also add both a Require and Proxy-Require header field with the value "sec-agree" to its request ✨
The server can use the contents of the Security-Client header field to add any info it needs to its response 💖
A server that gets an unprotected request containing a Require or Proxy-Require header field with the value "sec-agree" MUST respond to the client with a 494 (Security Agreement Required) response. The server MUST add a Security-Server header field to this response, listing the security mechanisms it supports. It MUST add that list even if the client's and server's lists have no mechanisms in common. The server's list MUST NOT depend on the contents of the client's list 🙈
The server MUST compare the list received in the Security-Client header field with the list it's going to send in the Security-Server header field. When the client gets this response, it picks the common security mechanism with the highest "q" value. So the server MUST add the info the client needs to start that mechanism (for example, a Proxy-Authenticate header field for HTTP Digest) 🔑
When the client gets a response with a Security-Server header field, it MUST choose the mechanism in the server's list with the highest "q" value among all the mechanisms the client knows. Then it MUST start that mechanism as described in Section 3.5. Starting it might not involve any SIP message exchange at all (for example, setting up a TLS connection) 🚀
If an attacker messes with the Security-Client header field in the request, the server might leave out the info needed to set up the common mechanism with the highest preference value (say, the Proxy-Authenticate header field is missing). If the client notices that info is missing from the response, it MUST consider the current security agreement process aborted. It MAY try to start it again by sending a new request with a Security-Client header field, as described above 🚨
All the later SIP requests the client sends to that server SHOULD use the security mechanism that was started in the previous step. These requests MUST contain a Security-Verify header field that mirrors the server's list received earlier in the Security-Server header field. These requests MUST also have both a Require and Proxy-Require header field with the value "sec-agree" 🫶
The server MUST check that the security mechanisms listed in the Security-Verify header field of incoming requests match its static list of supported security mechanisms 🔍
Note that, following the standard SIP header field comparison rules defined in [1], both lists have to contain the same security mechanisms in the same order to count as equivalent. On top of that, for each security mechanism, its parameters in both lists need to have the same values 💅
The server can go ahead and process a particular request if, and only if, the list was not modified. If the server detects that the list was modified, it MUST respond to the client with a 494 (Security Agreement Required) response. That response MUST include the server's unmodified list of supported security mechanisms. If the list wasn't modified and the server is a proxy, it MUST remove the "sec-agree" value from both the Require and Proxy-Require header fields, and then remove the header fields if no values are left 🧹
Once the security has been negotiated between two SIP entities, those same SIP entities MAY use the same security when they talk to each other in different SIP roles. For example, if a UAC and its outbound proxy negotiate some security, they may use that same security for incoming requests (so the UA is acting as a UAS) 🔄
The user of a UA SHOULD be told about the results of the security mechanism agreement. The user MAY decline to accept a particular security mechanism and abort any further SIP communications with the peer 🙅♀️
2.3.2 Server Initiated 📥
A server decides to use the security agreement in this document based on local policy. If a server gets a request from a network interface that's configured to use this mechanism, it must check that the request has only one Via entry. If there are several Via entries, the server isn't the first-hop SIP entity, and it MUST NOT use this mechanism. For a request like that, the server must return a 502 (Bad Gateway) response 🚧
A server that decides to use this agreement mechanism MUST challenge unprotected requests with one Via entry, no matter whether incoming requests have any Require, Proxy-Require, or Supported header fields or not 🎯
A server that requires this specification by policy and gets a request without the sec-agree option tag in a Require, Proxy-Require, or Supported header field MUST return a 421 (Extension Required) response. If the request has the sec-agree option tag in a Supported header field, the server MUST return a 494 (Security Agreement Required) response instead. In both situations the server MUST also include a Security-Server header field in the response listing its capabilities, plus a Require header field with the option-tag "sec-agree" in it. The server MUST also add the info the client needs to start the preferred security mechanism (for example, a Proxy-Authenticate header field for HTTP Digest) 🌸
Clients that support the extension in this document SHOULD add a Supported header field with the value "sec-agree" 🍓
2.4 Security Mechanism Initiation 💖
okay so once the client picks a security mechanism from the list the server sent in its Security-Server header field, it's time to actually start that mechanism 🎀 Different mechanisms need different startup routines, so there's no one-size-fits-all move here 💅
If "tls" is chosen, the client follows Section 8.1.2 of [1] to work out the URI that gets fed into the DNS procedures of [5] 🧚 Plot twist: if the URI is a SIP URI, it MUST treat the scheme as if it were sips, not sip 🙈 And if the URI scheme is not sip, the request MUST be sent using TLS 🔒
If "digest" is chosen, the 494 (Security Agreement Required) response will include an HTTP Digest authentication challenge 🔑 The client MUST use the algorithm and qop parameters from the Security-Server header field to replace the same parameters in the HTTP Digest challenge. The client MUST also use the digest-verify parameter in the Security-Verify header field to protect the Security-Server header field, as specified in 2.2 ✨
To use "ipsec-ike", the client tries to set up an IKE connection to the host part of the Request-URI in the first request it sends to the server 🌸 If that IKE connection attempt fails, the agreement procedure MUST be considered to have failed, and MUST be terminated. no retries, bestie 💀
Note that "ipsec-man" only works if the communicating SIP entities already know which keys and other parameters to use 🗝️ Figuring out how that info gets to the peers is outside the scope of this specification. All rules for minimum implementations, such as mandatory-to-implement algorithms, apply as defined in [2], [6], and [7] 📜
For both IPsec-based mechanisms, it's expected that appropriate policy entries for protecting SIP have been configured (or will be created) before you try the security agreement procedure. SIP communications also need to use port numbers and addresses that match those policy entries 🦋 How that info reaches the peers is also out of scope, but it would typically get configured at the same time as the IKE credentials or manual SAs 🫶
2.5 Duration of Security Associations 🕰️
once a security mechanism has been negotiated, both the server and the client need to know how long it's good for ⏳ Every mechanism in this document signals the end of a security association in its own way.
With TLS, the termination of the connection tells everyone that a new negotiation is needed 🔌 IKE negotiates the duration of its own security association 🙌 If the credentials a client used with digest stop being valid, the server will re-challenge the client 🔁 When IPsec-man is used, it's assumed that the same out-of-band mechanism used to distribute keys also defines how long the security association lasts 🗓️
2.6 Summary of Header Field Use 📋
The header fields defined in this document can be used to negotiate security mechanisms between a UAC and other SIP entities, including a UAS, a proxy, and a registrar 🤝 Table 1 sums up how these headers relate to SIP methods and proxy processing.
Header field where proxy ACK BYE CAN INV OPT REG
_________________________________________________________________
Security-Client R ard - o - o o o
Security-Server 421,494 - o - o o o
Security-Verify R ard - o - o o o
Header field where proxy SUB NOT PRK IFO UPD MSG
_________________________________________________________________
Security-Client R ard o o - o o o
Security-Server 421,494 o o - o o o
Security-Verify R ard o o - o o o
Table 1: Summary of Header Usage.The "where" column tells you which request and response types a header field can show up in. A header may not appear in other types of SIP messages. Values in the where column mean:
- R: the header field may appear in requests.
- 421, 494: a numerical value shows which response codes the header field can be used with.
The "proxy" column describes what a proxy is allowed to do with a header field:
- a: a proxy can add or concatenate the header field if it's not present.
- r: a proxy must be able to read the header field, so this header field cannot be encrypted.
- d: a proxy can delete a header field value.
The next six columns are about whether a header field is present for a given method:
- o: the header field is optional.
3. Backwards Compatibility 🔄
Using this extension on a network interface is a matter of local policy 🏠 Different network interfaces may follow different policies, so using this extension may end up being situational by nature 🌈 UA and server implementations MUST be configurable to operate with or without this extension ⚙️
A server that's configured to use this mechanism may also accept requests from clients that use TLS, based on the rules defined in [5] 🔐 Requests from clients that support neither this extension nor TLS cannot be accepted 🚫 Obviously, this breaks interoperability with some SIP clients 😭 So this extension should be used in environments where it's somehow ensured that every client implements this extension or is able to use TLS. It may also be used in environments where insecure communication is not acceptable, as long as being unable to communicate is also an acceptable outcome 🧯
4. Examples 🎀
The following examples show the mechanism defined above in action 👀
4.1 Client Initiated 🚀
A UA negotiates the security mechanism to use with its outbound proxy without knowing ahead of time which mechanisms the proxy supports 🕵️ The OPTIONS method can be used to ask for the proxy's security capabilities. That way, security can get started even before the first INVITE is sent through the proxy ✨
UAC Proxy UAS
| | |
|----(1) OPTIONS---->| |
| | |
|<-----(2) 494-------| |
| | |
|<=======TLS========>| |
| | |
|----(3) INVITE----->| |
| |----(4) INVITE--->|
| | |
| |<---(5) 200 OK----|
|<---(6) 200 OK------| |
| | |
|------(7) ACK------>| |
| |-----(8) ACK----->|
| | |
| | |
| | |
| | |
Figure 2: Negotiation Initiated by the Client.The UAC sends an OPTIONS request to its outbound proxy 📨 At the same time, it says it can negotiate security mechanisms and that it supports TLS and HTTP Digest (1).
The outbound proxy answers the UAC with its own list of security mechanisms, which are IPsec and TLS (2). The only mechanism they have in common is TLS, so they set up a TLS connection between them 🔒 Once that connection is successfully established, the UAC sends an INVITE request over the new TLS connection (3). This INVITE contains the server's security list. The server checks it, and since it matches its static list, it processes the INVITE and forwards it to the next hop 💌
If this example were run without the Security-Server header in Step 2, the UAC wouldn't know what kind of security the other side supports, and it would be forced into error-prone trials 😵
More seriously, if the Security-Verify header were omitted in Step 3, the whole process would be prone to MitM attacks 🚨 An attacker could spoof "ICMP Port Unreachable" messages during the trials, or remove the stronger security option from the header in Step 1. That would substantially reduce the security 💔
(1) OPTIONS sip:proxy.example.com SIP/2.0
Security-Client: tls
Security-Client: digest
Require: sec-agree
Proxy-Require: sec-agree
(2) SIP/2.0 494 Security Agreement Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(3) INVITE sip:proxy.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.2
Route: sip:callee@domain.com
Require: sec-agree
Proxy-Require: sec-agreeThe 200 OK response (6) to the INVITE and the ACK (7) are also sent over the TLS connection 🌷 The ACK contains the same Security-Verify header field as the INVITE (3).
4.2 Server Initiated 🌙
In this example, shown in Figure 3, the client sends an INVITE towards the callee through an outbound proxy 📮 This INVITE doesn't contain any Require header field.
UAC Proxy UAS
| | |
|-----(1) INVITE---->| |
| | |
|<-----(2) 421-------| |
| | |
|------(3) ACK------>| |
| | |
|<=======IKE========>| |
| | |
|-----(4) INVITE---->| |
| |----(5) INVITE--->|
| | |
| |<---(6) 200 OK----|
|<----(7) 200 OK-----| |
| | |
|------(8) ACK------>| |
| |-----(9) ACK----->|
| | |
| | |
Figure 3: Server Initiated Security Negotiation.The proxy, following its local policy, doesn't accept the INVITE 🙅 It returns a 421 (Extension Required) with a Security-Server header field that lists IPsec-IKE and TLS. Since the UAC supports IPsec-IKE, it performs the key exchange and sets up a security association with the proxy 🗝️
The second INVITE (4) and the ACK (8) contain a Security-Verify header field that mirrors the Security-Server header field received in the 421 🪞 The INVITE (4), the 200 OK (7) and the ACK (8) are all sent using the security association that's been established 🫶
(1) INVITE sip:uas.example.com SIP/2.0
(2) SIP/2.0 421 Extension Required
Security-Server: ipsec-ike;q=0.1
Security-Server: tls;q=0.2
(4) INVITE sip:uas.example.com SIP/2.0
Security-Verify: ipsec-ike;q=0.1
Security-Verify: tls;q=0.25. Security Considerations 🔐
okay so this spec is all about picking between SIP security mechanisms in a secure way 💅 The big payoff is that networks already running something like HTTP Digest can get upgraded to IPsec without every single piece of equipment changing at the same time 🦋 The catch: the method only holds up if the weakest mechanism on the list gives at least integrity and replay protection for the Security-Verify header field ✨
The security stuff is subtle but seriously important when networks change over time 🌸 The hashes are built using algorithms that were agreed on in those first unprotected messages, so you might ask what's even different. Assuming integrity protection is mandatory and only secure algorithms get used, we still have to stop MitM attackers from messing with other parameters, like whether encryption is turned on 👀 Say both peers can do strong AND weak security. If the initial offers aren't protected at all, any attacker can easily "downgrade" them by deleting the strong options 😤 That forces the two peers into weak security between them. But if the offers are protected somehow, like by hashing them or repeating them later once the selected security is really on, the situation changes completely 🙌 The attacker can't just modify one message. They'd have to change the offer message AND the message with the hash or repetition. Even worse for them, they'd have to forge the weak security in that second message, and do it in real time between the sent offers and the later messages. Otherwise the peers would notice the hash is wrong 🫶 And if the attacker can break the weak security, then that security method and/or algorithm just shouldn't be used anymore 💀
So the real difference is this: it's either a trivial attack, or the attacker has to actually break algorithms 😭 An example of why this matters: a network gets deployed with integrity protection first (like HTTP Digest [4]), and later new devices get added that also support encryption (like TLS [3]). With an insecure negotiation procedure, attackers could trivially force even those new devices to only use integrity protection 🥺
Here are the possible attacks against the security agreement, bestie 👇
- Attackers could try to modify the server's list of security mechanisms in the first response. This would be revealed to the server when the client sends the received list back using the security.
- Attackers could also try to modify the repeated list in the second request from the client. However, if the selected security mechanism uses encryption this may not be possible, and if it uses integrity protection any modifications will be detected by the server.
- Attackers could try to modify the client's list of security mechanisms in the first message. The client picks the security mechanism based on its own knowledge of its own capabilities and the server's list, so the client's choice wouldn't be affected by any such modification 🧚 The server's choice could still be affected, though:
- If the modification affected the server's choice, the server and client would end up choosing different security mechanisms in Step 3 or 4 of Figure 1. Since they couldn't communicate with each other, this would be detected as a potential attack. The client would either retry or give up in this situation.
- If the modification did not affect the server's choice, there's no effect.
- Finally, attackers may also try to replay old security agreement messages 🙈 Each security mechanism must provide replay protection. In particular, HTTP Digest implementations should carefully utilize existing replay protection options, such as including a time-stamp to the nonce parameter, and using nonce counters [4].
All clients that implement this specification MUST select HTTP Digest, TLS, IPsec, or any stronger method for the protection of the second request 💜
6. IANA Considerations 🌈
This specification defines a new mechanism-name namespace in Section 2.2, and that namespace needs a central coordinating body. That body is the Internet Assigned Numbers Authority (IANA) 🍓
This document defines four mechanism-names to be initially registered: "digest", "tls", "ipsec-ike", and "ipsec-man". On top of those, the "ipsec-3gpp" mechanism-name is also registered (see Appendix A). Following the policies outlined in [10], further mechanism-names get allocated based on IETF Consensus ✨
Registrations with the IANA MUST include the mechanism-name token being registered, plus a pointer to a published RFC that describes the details of the corresponding security mechanism 📚
6.1 Registration Information
IANA registers new mechanism-names at http://www.iana.org/assignments/sip-parameters under "Security Mechanism Names". Since this document specifies five mechanism-names, the initial IANA registration will contain the information in Table 2. It also shows the kind of information IANA keeps track of 🎀
Mechanism Name Reference
-------------- ---------
digest [RFC3329]
tls [RFC3329]
ipsec-ike [RFC3329]
ipsec-man [RFC3329]
ipsec-3gpp [RFC3329]
Table 2: Initial IANA registration.6.2 Registration Template
To: ietf-sip-sec-agree-mechanism-name@iana.org
Subject: Registration of a new SIP Security Agreement mechanism
Mechanism Name:
(Token value conforming to the syntax described in
Section 2.2.)
Published Specification(s):
(Descriptions of new SIP Security Agreement mechanisms
require a published RFC.)6.3 Header Field Names
This specification registers three new header fields: Security-Client, Security-Server and Security-Verify. These get defined by the information below, which goes in the sub-registry for SIP headers under http://www.iana.org/assignments/sip-parameters 🦋
Header Name: Security-Client
Compact Form: (none)
Header Name: Security-Server
Compact Form: (none)
Header Name: Security-Verify
Compact Form: (none)6.4 Response Codes
This specification registers one new response code: 494 (Security Agreement Required). It gets defined by the info below, which goes into the sub-registry for SIP methods and response-codes under http://www.iana.org/assignments/sip-parameters 💖
Response Code Number: 494
Default Reason Phrase: Security Agreement Required6.5 Option Tags
This specification defines a new option tag, sec-agree. It's defined by the information below, which goes in the sub-registry for option tags under http://www.iana.org/assignments/sip-parameters 👑
Name: sec-agree
Description: This option tag indicates support for the Security
Agreement mechanism. When used in the Require, or
Proxy-Require headers, it indicates that proxy servers
are required to use the Security Agreement mechanism.
When used in the Supported header, it indicates that
the User Agent Client supports the Security Agreement
mechanism. When used in the Require header in the 494
(Security Agreement Required) or 421 (Extension
Required) responses, it indicates that the User Agent
Client must use the Security Agreement Mechanism.7. Contributors ✨
Sanjoy Sen and Lee Valerius from Nortel Networks have contributed to the document 🧚
8. Acknowledgements 🫶
Beyond the contributors, the authors wanted to thank Allison Mankin, Rolf Blom, James Undery, Jonathan Rosenberg, Hugh Shieh, Gunther Horn, Krister Boman, David Castellanos-Zamora, Miguel Garcia, Valtteri Niemi, Martin Euchner, Eric Rescorla and members of the 3GPP SA3 group for the interesting discussions in this problem space 💜
9. Normative References 📚
[1] 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.
[2] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[3] Dierks, T. and C. Allen, P. Kocher, "The TLS Protocol Version
1.0", RFC 2246, January 1999.
[4] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402,
November 1998.
[7] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[8] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[10] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.10. Informative References 🌸
[11] Garcia-Martin, M., "3rd-Generation Partnership Project (3GPP)
Release 5 requirements on the Session Initiation Protocol
(SIP)", Work in Progress.
[12] 3rd Generation Partnership Project, "Access security for IP-
based services, Release 5", TS 33.203 v5.3.0, September 2002.
[13] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and
AH", RFC 2403, November 1998.
[14] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within ESP
and AH", RFC 2404, November 1998.
[15] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher Algorithms",
RFC 2451, November 1998.Appendix A. Syntax of ipsec-3gpp ✨
okay bestie, appendix time 🧚 this one adds a brand new security mechanism to the agreement framework from the main doc, and it's called "ipsec-3gpp" 💅 it gets used in the 3GPP IP Multimedia Subsystem [12]. the grammar is written in Augmented BNF and follows the syntax of SIP [1], so here it is, verbatim 🎀
mechanism-name = ( "ipsec-3gpp" )
mech-parameters = ( algorithm / protocol /mode /
encrypt-algorithm / spi /
port1 / port2 )
algorithm = "alg" EQUAL ( "hmac-md5-96" /
"hmac-sha-1-96" )
protocol = "prot" EQUAL ( "ah" / "esp" )
mode = "mod" EQUAL ( "trans" / "tun" )
encrypt-algorithm = "ealg" EQUAL ( "des-ede3-cbc" / "null" )
spi = "spi" EQUAL spivalue
spivalue = 10DIGIT; 0 to 4294967295
port1 = "port1" EQUAL port
port2 = "port2" EQUAL port
port = 1*DIGITnow the semantics, parameter by parameter 🦋
Algorithm 🔥 this one defines the authentication algorithm being used. it may be "hmac-md5-96" for HMAC-MD5-96 [13], or "hmac-sha-1-96" for HMAC-SHA-1-96 [14]. the algorithm parameter is mandatory, so it's a must-have 💀
Protocol 🌸 this one defines which IPsec protocol you're using. it may be "ah" for AH [6], or "esp" for ESP [7]. if there's no Protocol parameter present, the protocol will be ESP by default ✨
Mode 🍓 this defines the mode the IPsec protocol runs in. it may be "trans" for transport mode, or "tun" for tunneling mode. if there's no Mode parameter present, the IPsec protocol is used in transport mode 🫶
Encrypt-algorithm 🔐 this defines the encryption algorithm. it may be "des-ede3-cbc" for 3DES [15], or "null" for no encryption. if there's no Encrypt-algorithm parameter present, encryption is not used 💜
Spi 🧚 defines the SPI number used for inbound messages ✨
Port1 🎀 defines the destination port number for inbound messages that are protected 👑
Port2 🌈 defines the source port number for outbound messages that are protected. Port 2 is optional, so you don't have to include it 🙈
the SIP entities need to know beforehand which keys to use, no cap 🔑 it's also assumed that the underlying IPsec implementation supports selectors that let all the transport protocols SIP supports get protected with a single SA. and the lifetime of the security association is the same as the expiration interval of the matching registration binding. main character energy for the SA 👑
Authors' Addresses 🎀
the crew behind this one, all in one place 🫶
Jari Arkko
Ericsson
Jorvas, FIN 02420
Finland
Phone: +358 40 507 9256
EMail: jari.arkko@ericsson.com
Vesa Torvinen
Ericsson
Joukahaisenkatu 1
Turku, FIN 20520
Finland
Phone: +358 40 723 0822
EMail: vesa.torvinen@ericsson.fi
Gonzalo Camarillo
Advanced Signalling Research Lab.
Ericsson
FIN-02420 Jorvas
Finland
Phone: +358 40 702 3535
EMail: Gonzalo.Camarillo@ericsson.com
Aki Niemi
NOKIA Corporation
P.O.Box 321, FIN 00380
Finland
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Tao Haukka
Nokia Corporation
P.O. Box 50
FIN - 90570 Oulu
Finland
Phone: +358 40 517 0079
EMail: tao.haukka@nokia.comFull Copyright Statement ⭐
the legal bit, kept complete and word for word 💅
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement 🌸
funding for the RFC Editor function is currently provided by the Internet Society 💖 and that's the end of the doc, bestie 🦋✨
📦 where this page comes from
- ietf: rfc3329 2003-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms