SASL Authentication for SIP

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 9 April 2023.¶

Copyright Notice

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SASL authentication has long been used in protocol design to gain flexible authentication without change to the protocol that carries this. This powerful idea is still being introduced in new protocols. SIP has fallen behind by choosing the HTTP framework, which is not actively developed because much of HTTP authentication has shifted to the application layer. A recent proposal was made to add SASL authentication to HTTP, and a variant of that is herein proposed for SASL.¶

A few aspects about SASL are especially interesting. Its support of Kerberos is useful in many organisations who exercise central identity management under a single-signon system. Any protocol that cannot use Kerberos interferes with such operational policies. Recent SASL mechanisms of cryptographic interest are the SCRAM family and the OPAQUE mechanism. Finally, work has been done to proxy SASL to a client's own Diameter backend to allow Realm Crossover. All these would be of benefit to SIP usage profiles under the authentication profile specified herein.¶

SIP differs from HTTP and connection-bound protocols in a few important manners. First, SIP messages are often forwarded along a path, and this is not done transparantly. Second, any TLS protection is tied to a single hop along this path and cannot be used to protect the SASL mechanism from transmission in plaintext. Third, SIP messages must be considered separate from their carrier connection but are tied together with identities, both for transactions and for dialogs. This mix of properties necessitates a separate profile to use SASL under SIP.¶

2. Inheritance of HTTP-SASL as SIP-SASL

SASL authentication inherits most of its properties from HTTP authentication [Section 22 of [RFC3261]]. This includes the 401 and 407 responses and the corresponding headers in both these responses and subsequent new requests that attempt to answer the authentication request. It adopts the Digest authentication but abolishes Basic authentication.¶

The general SIP grammar [Section 25 of [RFC3261]] welcomes other-challenge and other-response forms that fit a token as an auth-scheme:¶

; Challenge
WWW-Authenticate    =  "WWW-Authenticate" HCOLON challenge
Proxy-Authenticate  =  "Proxy-Authenticate" HCOLON challenge
challenge           =  ("Digest" LWS digest-cln *(COMMA digest-cln))
                       / other-challenge

; Response
Authorization       =  "Authorization" HCOLON credentials
Proxy-Authorization =  "Proxy-Authorization" HCOLON credentials
credentials         =  ("Digest" LWS digest-response)
                       / other-response

; non-Digest forms
other-challenge     =  auth-scheme LWS auth-param
                       *(COMMA auth-param)
other-response      =  auth-scheme LWS auth-param
                       *(COMMA auth-param)

; Shared elements
auth-scheme         =  token
auth-param          =  auth-param-name EQUAL
                       ( token / quoted-string )
auth-param-name     =  token

The auth-scheme values are not formally linked to HTTP, but are presumably inhereted, along with their accompanying grammars. We hereby explicitly import the specifications for HTTP-SASL [TODO:xref target="draft-vanrein-httpauth-sasl"] for use with SIP. This specifically adds the auth-scheme token SASL and the auth-param-name tokens realm, mech, c2s, s2c, c2c and s2s. When each of these MAY or MUST be used follows HTTP-SASL [Section 2.1 of TODO:xref target="draft-vanrein-httpauth-sasl"].¶

3. Additional Concerns for SIP

Most SASL protocols have a direct connection between client and server, and protect it with TLS. This is not the case for SIP, may vividly route its messages. It is also not like HTTP, in the sense that requests and responses may be even more detached when they are transmitted over UDP.¶

Some things about SASL are actually simpler than HTTP, namely the standardised notions of identities. There are dialog identities (Call-ID: value, From: tag and, once available, To: tag) and transaction identities (Via: branch) that are helpful to see connections between individual SIP messages. They are not designed to be cryptographically secure, but as unique identifiers that may be used in nonces.¶

4. Authenticating From: and To: headers

The identities validated are the ones in From: and To: headers, respectively as client and server identities. The precies parts of the SIP grammar [Section 25 of [RFC3261]] are the user or telephone-subscriber in the addr-info non-terminal in these headers. The host (which often ends up being a domain) is used as the realm for SIP authentication.¶

It is worth noting that the host/domain for From: and To: may differ, especially when SIP proxies connect over the Internet. In such cases, the From: host/domain is used as the client realm and the To: host/domain is used as the server realm. The implications for authentication access realms are discussed in Section 10.¶

5. Plaintext Sensitivity and Context Binding

Not all SASL mechanisms are suitable for transfer over a plaintext channel. Such mechanisms SHOULD NOT be used with SIP, not even when protected by TLS, because the messages are often relayed; even when all legs on their path are encrypted channels, then the SASL mechanism is revealed to all intermediate proxies. This concern is also reflected in the original SIP authentication schemes, which inherit Digest from HTTP authentication, but not Basic.¶

It is a concern that rogue proxies could insert a SASL mechanism of lower quality in the mech header while it passes through, so clients MUST be able to filter the list of mechanisms, for example with conservative builtin lists or through configuration settings by the user.¶

The restriction to plaintext-ready SASL mechanisms does not mean that secure transports are no longer useful. There are other values, such as privacy of SIP messages and the binding of these messages to the authentication exchange. This is a useful hop-to-hop property. It is worth nothing that TLS is not the only mechanism to establish these properties however; a SIP connection may encapsulate messages in a secure body to achieve the same effect.¶

6. Mutual Authentication

All SASL mechanisms offer client authentication, some offer mutual authentication and thereby also authenticate the server. Examples of the latter include GSSAPI for Kerberos5, GS2-KRB5, GS2-KRB5-PLUS, EXTERN based on a mutually authenticating TLS connection, the SCRAM-* family, SXOVER-PLUS with suitable access control, and OPAQUE.¶

SIP clients are those parties that send a request; this is fixed per transaction, but roles may vary during a dialog. When a request receives a 401 or 407 response to call for client authentication, then authentication always validates the client identity, but mutual authentication would validate the server in the same authentication process.¶

Authentication never covers more than a SIP dialog, and may even be considered valid for a single transaction (which makes cryptographic sense of unencrypted tansports). When a dialog is covered, mutual authentication may be considered to already authenticate the other side.¶

7. Channel Binding

SASL mechanism names have a reserved -PLUS ending to indicate Channel Binding. This facility is used to avoid passing of an authentication exchange from one channel onto another. Protocols that employ a single TLS connection can derive a channel binding value from the master key. For SIP, this might work as a hop-to-hop approach, but in general SIP needs end-to-end negotiation, at least for generally useful 401 response handling.¶

Channel Binding has progressed from simple endpoint data such as addresses and ports to much stronger cryptographic derivates. These have the benefit of providing sufficient entropy that cannot be changed by a rogue intermediate. In SIP, both end points supply random tags and identifiers that involves entropy, and pass it in a textual form which is not size-constrained. This allows any amount of entropy desired.¶

Dialogs in SIP are identified with the Call-ID field value, the From: tag and, once set in a response, the To: tag. This allows a good level of entropy to describe the identity of a dialog with input from both endpoints. Transactions are identified by a Via: branch value, which may be added to the dialog identities because a transaction are always part of a dialog.¶

The values are identities, and they are unrelated to transport endpoint coordinates. As a result, they can be designed as non-repetitive strings and they serve as selectors for the active transactions. This qualifies the SIP identity information as useful channel binding values. It is vital that both sides can supply entropy, which is addressed by a first response. As long as SASL is initiated with a 401 response this is taken care of.¶

Channel binding can be used to incorporate more data into a authentication exchange, thereby validating the said data. For SIP, that is likely the SDP attachment. If the SDP information from both ends is to be integrated, then the first 401 must already add the SDP offer to bind.¶

Based on the aforementioned information, the following forms of channel binding are based on varying lists of values:¶

Channel Binding type | Values included in a hash
---------------------+-------------------------------------
sip-dialog           | Call-ID,From,To
sip-dialog-body      | Call-ID,From,To,   ,reqbody,respbody
sip-transaction      | Call-ID,From,To,Via
sip-transaction-body | Call-ID,From,To,Via,reqbody,respbody

The channel binding value starts with the Channel Binding type, a colon (ASCII 0x3a) [Section 2.1 of [RFC5056]] followed by the binary value of the SHA-256 hash over the following character sequence:¶

Call-ID

the contents of the callid terminal, followed by an ASCII space,¶

From

the contents of the token terminal in the tag-param in the from-param, followed by an ASCII space,¶

To

the contents of the token terminal in the tag-param in the to-param, followed by an ASCII space,¶

Via (if included)

the token terminal in the via-branch of the first Via: header, followed by an ASCII space,¶

reqbody (if included)

the media-type non-terminal in the Content-Type header, an ASCII space, the shortest possible 1*DIGIT value for the value of the Content-Length header, an ASCII space and the body from the original request in the transaction that is being authenticated,¶

respbody (if included)

the media-type non-terminal in the Content-Type header, an ASCII space, the shortest possible 1*DIGIT value for the value of the Content-Length header, an ASCII space and the body from the response to the original request in the transaction that is being authenticated.¶

The bodies are always specific to the authenticating transaction, even when Channel Binding covers a dialog. This avoids confusion when re-authenticating for a re-INVITE.¶

TODO: Are all these Channel Binding types practical? (1) The Via: branch differs at different parts of the exchange. (2) It is difficult to speak of a body when referencing a dialog, unless it is for the transaction that is authenticated; does this not mean that the body is tied to a transaction?¶

Note that only certain parts of the SIP message content are included in the Channel Binding information. This reflects the protocol support for changes along its path. The body however, is only subjected to rewrites in special circumstances (SDP rewrites for traffic over IPv4) but will otherwise be sent as an opaque end-to-end object. The use of a secure transport is the customary approach to protect the unbound information from being changed in transit.¶

8. Security Layers: Encryption

SASL can negotiate security layers, which usually means that it can facilitate integrity and/or confidentiality bassed on the cryptographic material exchanged during authentication. A common example is the GSSAPI implementation of Kerberos5, which passes a session key encrypted with a Ticket-specific secret. Subsequent GSS_Wrap and GSS_Unwrap calls, or GSS_GetMIC and GSS_VerifyMIC [RFC2743] map plaintext to wire messages and back.¶

The use of cryptographic content in a SIP message is generally confined to the body. When a suitable Media type is registered to convey the confidentialilty and/or integrity wrapper of the body, then an endpoint may choose to use this to transmit a more secure form of a body, or a full SIP message. A typical example of this mechanism is the S/MIME content in a body with Content-type application/pkcs7-mime [Section 23 of [RFC3261].¶

This specification introduces a media type message/gssapi, to capture bodies with one wire-format message as may be prepared with GSS-API calls like GSS_Wrap() or GSS_GetMIC() [RFC2743]]. SASL mechanisms that could use this media type include GSSAPI, GS2-KRB5, GS2-KRB5-PLUS and SXOVER-PLUS.¶

When a proxy or server offers a SASL mechanism that derives a security layer, then the authenticating proxy or client MAY transmit SIP messages with a matching body media type after the authentication succeeds. When a proxy or client chooses to authenticate with a SASL mechanism that derives a security layer, then the proxy or server MAY transmit SIP messages with a matching body media type after the authentication succeeds.¶

9. Security Layers: Key Derivation

Security layers negotiated with SASL can take various forms. Particularly interesting for SIP could be key derivation, because it initiates independently operated sessions which often benefit from keys to improve security. A general mechanism that works well for key derivation is to present a string label and an optional salt to extract distinct key material.¶

SIP applications in want for such a facility would define such a string label and salt computation, and choose whether to prefer or even require SASL mechanisms that allow key derivation. When an application and SASL mechanism meet, then key derivation can be used, further processing the outcome as per the definitions of the application. Such mechanisms are not enforced for SIP-SASL in a general sense, because that could lead to incompatibility issues, but applications or application profiles with suitable negotiation parameters may build upon key derivation facilities.¶

Applications and application profiles MAY choose to extract key material from SASL mechanisms that were not originally designed with such facilities, but that happen to have a more extensive implementation. SASL mechanism negotiation would then offer and accept such mechanisms for applications that rely on key derivation.¶

When elected, the general pattern starts with HKDF-Extract(salt,IKM) [Section 2.2 of [RFC5869]] with salt set to the hash input for the sip-dialog Channel Binding type and IKM set to a shared secret; in password-based mechanisms this is the password and in decryption challenges it is the encrypted material. Following this, the general pattern uses KHDF-Expand(PRK,info,L) [Section 2.3 of [RFC5869]] where the info consists of the string label, and, if the application defines a salt for this string label, an additional NUL byte (0x00) and the salt bytes. The HMAC algorithm underneath HDKF-Extract and HDKF-Expand will be based on a hash used in the SASL mechanism if it uses one; otherwise it will be SHA256.¶

10. Realm Crossover

The term Realm Crossover refers to techniques that allow existing protocols to benefit from identity providers under operational control of a user's domain. These techniques minimise the dependency on third parties while maximising the control of domains and their users over their online identity. Identities generally take a form user@domain.name which, in the the case of SIP, can simply be prefixed with sip: or sips: scheme.¶

Techniques that have been investigated as candidates for Realm Crossover are:¶

SASL

This uses the SXOVER-PLUS mechanism as a secure wrapper for another SASL mechanism, and relaying it to a Diameter backend, which in can relay the SASL content to the client's realm, where a Diameter server offers identity assurance. The Diameter cross-link assures a domain.name based on TLS and DNSSEC/DANE, the client's server assures a userid based on the client's SASL content, so that a userid@domain.name can be formed on the relying Diameter node, and fed back locally to the relying service.¶

Kerberos5

This already facilitates Realm Crossover, but it is customarily founded on static keys. The KXOVER protocol allows Key Distribution Centers to exchange a dynamic key that can be used for a few weeks to crossover between their realms. KXOVER founds its security on TLS and DNSSEC/DANE.¶

PKIX

Current work is in progress on Client DANE. This may be used to publish a Root CA for a domain's client identities. After obtaining this with DNSSEC assurance from the client domain, a client certificates can be validated by any other party.¶

It is common for SIP messages to be internally routed from one endpoint to the public proxy for its realm, then crossover to the proxy of another realm which internally routes it to another endpoint. The 407 mechanism might be used to validate the From: and To: identities for the crossover, while encrypting the SDP content involved in the crossover.¶

Such proxy-to-proxy encryption may be used to connect realms for prolonged periods, independently of the SIP messages that pass as SIP messages contained in secured bodies. This can be setup with proxy hostnames in From: and To: headers, to be used when SRV records indicate those hostnames. The setup would be with INVITE with SASL authentication, and the dialog is used until one party sends BYE or a transmission results in a 481 Call/Transaction Does Not Exist to thissuggest renegotiation.¶

The longer messages caused by security wrapping combined with MTU considerations arguably make it better to use a transport with more control than UDP. When domains connect via their externally visible proxies, SCTP should be a reasonable default.¶

Appendix A. Acknowledgements

Thanks to NLNet for funding this work.¶

Author's Address