Internet DRAFT - draft-vanrein-sipauth-sasl
draft-vanrein-sipauth-sasl
Network Working Group R. Van Rein
Internet-Draft OpenFortress BV
Intended status: Informational 14 October 2022
Expires: 17 April 2023
SASL Authentication for SIP
draft-vanrein-sipauth-sasl-01
Abstract
Many protocols benefit from "pluggable" authentication choice as a
result of SASL authentication. In the Session Initiation Protocol,
the independent branch of HTTP Authentication has been elected.
Recent progress has been made in bringing SASL to HTTP, but SIP has
its own special considerations and needs its own embedding to gain
the flexibility of SASL.
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 17 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.
Van Rein Expires 17 April 2023 [Page 1]
Internet-Draft SIP-SASL October 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Inheritance of HTTP-SASL as SIP-SASL . . . . . . . . . . . . 3
3. Additional Concerns for SIP . . . . . . . . . . . . . . . . . 4
3.1. Authenticating From: and To: headers . . . . . . . . . . 4
3.2. Plaintext Sensitivity and Context Binding . . . . . . . . 5
3.3. Mutual Authentication . . . . . . . . . . . . . . . . . . 5
3.4. Channel Binding . . . . . . . . . . . . . . . . . . . . . 6
3.5. Security Layers: Encryption . . . . . . . . . . . . . . . 8
3.6. Security Layers: Key Derivation . . . . . . . . . . . . . 8
4. Realm Crossover . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Internal Security . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Normative References . . . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
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.
Van Rein Expires 17 April 2023 [Page 2]
Internet-Draft SIP-SASL October 2022
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
Van Rein Expires 17 April 2023 [Page 3]
Internet-Draft SIP-SASL October 2022
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.
Each party may approve of more flexibility than a literal match with
the authenticated identity and the remote header value. Group
members may authenticate as a group, for example. And users may be
replaced by an alias. More generally said, an access control
mechanism may be used to decide on identity substitutions, possibly
based on the relation between remote and local identity.
3.1. 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 4.
Van Rein Expires 17 April 2023 [Page 4]
Internet-Draft SIP-SASL October 2022
3.2. Plaintext Sensitivity and Context Binding
Some SASL mechanisms are unsuitable 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 tokens
are 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.
3.3. Mutual Authentication
All SASL mechanisms offer client authentication, some offer mutual
authentication and thereby also authenticate the server. Examples of
the latter include GSS-API 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.
Van Rein Expires 17 April 2023 [Page 5]
Internet-Draft SIP-SASL October 2022
3.4. 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
Van Rein Expires 17 April 2023 [Page 6]
Internet-Draft SIP-SASL October 2022
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 path. (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 transaction authentication?
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.
Van Rein Expires 17 April 2023 [Page 7]
Internet-Draft SIP-SASL October 2022
3.5. 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 GSS-API 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 GSS-API, 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.
3.6. 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.
Van Rein Expires 17 April 2023 [Page 8]
Internet-Draft SIP-SASL October 2022
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 restrict the
mechanisms offered and accepted if applications depend on such
extended forms of 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 sip-
dialog Channel Binding 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.
4. Realm Crossover
The term Realm Crossover refers to techniques [TODO:xref
target="draft-vanrein-internetwide-realm-crossover"] 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 for which Realm Crossover can be achieved 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
Van Rein Expires 17 April 2023 [Page 9]
Internet-Draft SIP-SASL October 2022
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 realm-crossing link is a sensitive place in terms of
privacy, and may benefit from encrypting the SIP message. 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 SIP proxies 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, and 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; the
latter may be seen as a suggestion to send another INVITE to the
responding proxy.
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.
4.1. Internal Security
The mechanism of passing SIP messages in secure bodies need not be
limited to Realm Crossover; it may also be used for internal
security, such as for a device registration with its domain proxy.
To combat MTU considerations it may be useful to forego UDP, but
clients may be restricted to TCP and, given the low traffic rate and
the higher administrative overhead of SCTP, this would be a good
choice for individual registrations. For SIP trunks, the use of SCTP
Van Rein Expires 17 April 2023 [Page 10]
Internet-Draft SIP-SASL October 2022
may still be a feasible option.
TODO: Is this a good idea though? How would it relate to the
REGISTER usage pattern? It does add proper security in a part of the
infrastructure that usually is only mildly secure.
5. Security Considerations
TODO: Some points made in the foregoing: plaintext sensitivity,
binding of authentication to context, mutual-or-not, encrypting
wrappers for SIP messages.
6. IANA Considerations
IANA is requested to register the following values in the Media Types
registry:
Name: GSS-API
Template: message/gssapi
Reference: <this spec>
IANA is requested to register the following types of channel binding
in the Channel-Binding Types registry:
Van Rein Expires 17 April 2023 [Page 11]
Internet-Draft SIP-SASL October 2022
Subject: Registration of channel binding sip-dialog
Channel-binding unique prefix: sip-dialog
Channel-binding type: unique
Channel type: SIP
Published specification: <this spec>
Channel binding is secret: no
Description: Call-ID, From: tag, To: tag
Intended usage: COMMON
Person and email: <author of this spec>
Owner/Change controller: IESG
Subject: Registration of channel binding sip-dialog-sdp
Channel-binding unique prefix: sip-transaction
Channel-binding type: unique
Channel type: SIP
Published specification: <this spec>
Channel binding is secret: no
Description: Call-ID, From: tag, To: tag, Via: branch
Intended usage: COMMON
Person and email: <author of this spec>
Owner/Change controller: IESG
Subject: Registration of channel binding sip-transaction
Channel-binding unique prefix: sip-dialog-sdp
Channel-binding type: unique
Channel type: SIP
Published specification: <this spec>
Channel binding is secret: no
Description: Call-ID, From: tag, To: tag, request SDP, [response SDP]
Intended usage: COMMON
Person and email: <author of this spec>
Owner/Change controller: IESG
Subject: Registration of channel binding sip-transaction-sdp
Channel-binding unique prefix: sip-transaction-sdp
Channel-binding type: unique
Channel type: SIP
Published specification: <this spec>
Channel binding is secret: no
Description: Call-ID, From: tag, To: tag, Via: branch, request SDP, [response SDP]
Intended usage: COMMON
Person and email: <author of this spec>
Owner/Change controller: IESG
Since there is no separate registry for SIP authentication schemes,
no work on this is requested from IANA.
7. Normative References
Van Rein Expires 17 April 2023 [Page 12]
Internet-Draft SIP-SASL October 2022
[I-D.vanrein-internetwide-realm-crossover]
van Rein, R., "InternetWide Identities with Realm
Crossover", Work in Progress, Internet-Draft, draft-
vanrein-internetwide-realm-crossover-01, 6 October 2022,
<https://www.ietf.org/archive/id/draft-vanrein-
internetwide-realm-crossover-01.txt>.
[I-D.vanrein-httpauth-sasl]
Rein, R. V., "HTTP Authentication with SASL", Work in
Progress, Internet-Draft, draft-vanrein-httpauth-sasl-07,
14 October 2022,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
vanrein-httpauth-sasl/>.
[RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743,
DOI 10.17487/RFC2743, January 2000,
<https://www.rfc-editor.org/info/rfc2743>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, DOI 10.17487/RFC5056, November 2007,
<https://www.rfc-editor.org/info/rfc5056>.
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand
Key Derivation Function (HKDF)", RFC 5869,
DOI 10.17487/RFC5869, May 2010,
<https://www.rfc-editor.org/info/rfc5869>.
Appendix A. Acknowledgements
Thanks to NLNet for funding this work.
Author's Address
Rick van Rein
OpenFortress BV
Haarlebrink 5
Enschede
Email: rick@openfortress.nl
Van Rein Expires 17 April 2023 [Page 13]
