Certificate Management Service for the Session Initiation Protocol (SIP)
Extracted elements (31)
Architectures that avoid storing private keys on credential servers were considered but rejected: alternatives either moved the security problem to another server, or required senders to encrypt per-device (revealing device topology and generating excessive signaling for multi-device users).
Self-signed certificates are used rather than CA-issued ones because commercial certification authorities have rarely supported SIP URIs in SubjectAltName. SIP Identity (RFC 4474) provides the equivalent trust binding by having the proxy domain vouch for the AOR-to-certificate relationship.
The credential exchange mechanism follows the SACRED Framework (RFC 3760) cTLS architecture: the UA authenticates the server via TLS certificate, and the server authenticates the UA using SIP Digest inside the TLS session, forming a strong session key protecting credentials in transit.
A UA MUST use TLS to directly connect to the credential service and MUST NOT connect through an intermediate proxy. The TLS certificate presented must match the expected server name to prevent man-in-the-middle attacks.
A UA wishing to revoke the existing certificate without publishing a new one MUST send a PUBLISH with an empty body and Expires=0 to the credential server, causing subscribers to receive a no-body NOTIFY and stop using previously stored credentials.
Before using a certificate from a NOTIFY, the UA MUST verify: (1) From header matches subscribed AOR, (2) Identity header is valid per RFC 4474, (3) certificate validity times are current, and (4) the certificate is indexed only by the AOR asserted by the authentication service.
Clients and servers MUST NOT request, offer, or use SSL 2.0 due to known security vulnerabilities.
Credential server implementations MUST be implemented as a state agent. Implementers MUST NOT use the event list extension (RFC 4662) with either the certificate or credential event types, as doing so would require the authentication service to assert multiple identities simultaneously.
Credential services MUST support TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_128_CBC_SHA256. Implementations MUST NOT negotiate cipher suites employing NULL encryption, integrity, or authentication algorithms.
If a credential is revoked, the credential service MUST terminate active subscriptions and send a NOTIFY with Subscription-State 'terminated' and reason 'deactivated'. Any time credentials change, the credential service MUST send a new NOTIFY to all active subscriptions.
If a UA receives a 437 (Unsupported Certificate) response, it SHOULD remove the used certificate from cache and fetch a new one. If a UA cannot decrypt a received PKCS #8 object, it MUST send a 437 response.
Implementations MUST support multipart/mixed for credential NOTIFY bodies, containing at minimum an application/pkix-cert and an application/pkcs8 body. PKCS #8 objects MUST be of type PrivateKeyInfo.
PKCS #8 encryption MUST implement PBES2 with PBKDF2 using HMAC (supporting both SHA-1 and SHA-256) and MUST implement id-aes128-wrap-pad as defined in RFC 5649. A different password SHOULD be used for PKCS #8 encryption than for client authentication.
The amount of time a Subscriber caches a certificate SHOULD be configurable; a default of one day is RECOMMENDED. The UA MUST NOT cache a certificate for longer than the subscription duration.
The body of a NOTIFY for the 'certificate' package MUST either be empty or contain an application/pkix-cert body. The Content-Disposition MUST be set to 'signal'.
The 'certificate' and 'credential' event packages do not permit forked requests; at most one subscription per resource is permitted.
The credential NOTIFY MUST be sent over a direct TLS connection between the UA and credential service with no intermediaries, ensuring integrity and confidentiality of the private key material.
The Subscriber MUST check that a certificate NOTIFY is correctly signed by an authentication service per RFC 4474. If the asserted identity does not match the subscribed AOR, the certificate MUST NOT be used.
User certificates MUST implement sha1WithRSAEncryption and sha256WithRSAEncryption for the signatureAlgorithm. The SubjectAltName must contain a URI type set to the user's SIP AOR URL. A validity period of one year or less is RECOMMENDED.
When a credential service receives a SUBSCRIBE for a credential, it MUST challenge the UA using SIP Digest authentication and authorize that the UA is entitled to register as that AOR before delivering credentials.
When processing a credential PUBLISH, the credential service MUST authenticate the request and validate: notBefore is not in the future, notAfter is in the future, and if cA BasicConstraints is present it is set to FALSE.
The 'certificate' SIP event package allows User Agents to subscribe to another user's AOR to retrieve that user's X.509 certificate. The credential service returns the certificate in a NOTIFY request authenticated via the SIP Identity mechanism (RFC 4474).
The 'credential' SIP event package allows User Agents to store and retrieve their own certificate and private key from a credential service. UAs authenticate via SIP Digest over a direct TLS connection and receive credentials in NOTIFY requests.
The rsa-sha256 identity signature algorithm is defined, computed identically to rsa-sha1 from RFC 4474 except using sha256WithRSAEncryption per RFC 5754. Implementations of this specification MUST implement both rsa-sha1 and rsa-sha256.
IANA added 'rsa-sha256' to the 'Identity-Info Algorithm Parameter Values' registry referencing RFC 6072. This algorithm uses sha256WithRSAEncryption in place of the sha1WithRSAEncryption used by rsa-sha1.
IANA registered the 'certificate' SIP event package in the 'Session Initiation Protocol (SIP) Event Types Namespace' registry. This is not a template package and defines no new Event header parameters.
IANA registered the 'credential' SIP event package in the 'Session Initiation Protocol (SIP) Event Types Namespace' registry. This is not a template package.
A compromised authentication service is the worst-case attack: the attacker can forge certificates and perform man-in-the-middle attacks on any user. UAs MAY try to detect this by subscribing to their own certificate under a different identity or by monitoring certificate fingerprints for unexpected changes before expiry.
An attacker can block certificate revocation NOTIFYs, causing a UA to continue using a revoked certificate. UAs mitigate this by enforcing a configurable maximum cache expiry independent of receiving a NOTIFY; the cache time is analogous to a CRL polling interval.
Private keys SHOULD NOT be stored in the clear on devices or servers. It is RECOMMENDED to encrypt them using tamper-resistant hardware, decrypting only during signing operations and re-encrypting immediately to limit RAM exposure.
TLS clients MUST check that the SubjectAltName of the server certificate exactly matches the intended server name. Any intermediary in the TLS path can substitute an attacker-controlled certificate, exposing private key material or Digest credentials.