RFC 3329

Q: What does the Introduction section cover in RFC 3329 — SIP Security Agreement?

The Introduction section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 3329 — SIP Security Agreement. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Security Agreement Flow section cover in RFC 3329 — SIP Security Agreement?

The Security Agreement Flow section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 3329 — SIP Security Agreement. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Security Mechanism Parameters section cover in RFC 3329 — SIP Security Agreement?

The Security Mechanism Parameters section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 3329 — SIP Security Agreement. This content is part of the BLACKLABS RFC Reference Library.

Q: What does the Security Considerations section cover in RFC 3329 — SIP Security Agreement?

The Security Considerations section provides detailed technical specifications, security considerations, and implementation guidance as documented in RFC 3329 — SIP Security Agreement. This content is part of the BLACKLABS RFC Reference Library.

BLACKLABS

Security Mechanism Agreement for the Session Initiation Protocol (SIP)

Standards Track

January 2003

Abstract: Defines a mechanism for SIP user agents and first-hop proxies to negotiate security mechanisms. In 3GPP IMS, this is mandatory for the UE to negotiate IPsec security associations with the P-CSCF on the Gm interface.

Canonical source: https://www.rfc-editor.org/rfc/rfc3329 | IETF Datatracker

1. Introduction

▶

SIP does not natively negotiate which security mechanisms to use. This RFC defines Security-Client, Security-Server, and Security-Verify headers that allow a SIP UA and its first-hop SIP proxy to agree on a security mechanism.

In 3GPP IMS, this mechanism is used during registration to establish IPsec ESP security associations between the UE and P-CSCF, protecting all subsequent SIP signaling on the Gm (access) interface.

2. Security Agreement Flow

▶

The UE sends its supported mechanisms in Security-Client. The P-CSCF responds with its supported mechanisms in Security-Server. The UE's second REGISTER echoes the server's list in Security-Verify to protect against MitM downgrade attacks.

  UE                              P-CSCF
|                                |
|  REGISTER                      |
|  Security-Client: ipsec-3gpp;  |
|    alg=hmac-sha-1-96;          |
|    spi-c=11111; spi-s=22222;   |
|    port-c=5060; port-s=5061    |
|------------------------------->|
|                                |
|  401 Unauthorized              |
|  Security-Server: ipsec-3gpp;  |
|    alg=hmac-sha-1-96;          |
|    spi-c=33333; spi-s=44444;   |
|    port-c=5062; port-s=5063;   |
|    q=0.1                       |
|<-------------------------------|
|                                |
|  [IPsec SAs established using  |
|   IMS-AKA derived keys (IK)]   |
|                                |
|  REGISTER (via IPsec)          |
|  Security-Verify: ipsec-3gpp;  |
|    (echo of Security-Server)   |
|------------------------------->|
|                                |
|  200 OK (via IPsec)            |
|<-------------------------------|

3. Security Mechanism Parameters

▶

Parameter	Description
alg	Integrity algorithm (hmac-sha-1-96, hmac-md5-96)
ealg	Encryption algorithm (des-ede3-cbc, aes-cbc, null)
spi-c	SPI for client-to-server direction
spi-s	SPI for server-to-client direction
port-c	Protected client port
port-s	Protected server port
q	Preference value (0-1, higher = more preferred)

4. Security Considerations

▶

Security-Verify header prevents bidding-down attacks (MitM selecting weakest mechanism)
IK (Integrity Key) from AKA is used as IPsec pre-shared key — ties security to authentication
Without Security Agreement, an attacker could strip IPsec and intercept plain SIP
The first REGISTER (before IPsec) MUST NOT carry sensitive data beyond initial auth challenge