This commit introduces an extension to the endpoint and relevant
resource sizes for PJSIP, transitioning from its current 40-character
constraint to a more versatile 255-character capacity. This enhancement
significantly overcomes limitations related to domain qualification and
practical usage, ultimately delivering improved functionality. In
addition, it includes adjustments to accommodate the expanded realm size
within the ARI, specifically enhancing the maximum realm length.
Resolves: #345
UserNote: With this update, the PJSIP realm lengths have been extended
to support up to 255 characters.
UpgradeNote: As part of this update, the maximum allowable length
for PJSIP endpoints and relevant resources has been increased from
40 to 255 characters. To take advantage of this enhancement, it is
recommended to run the necessary procedures (e.g., Alembic) to
update your schemas.
RFC7616 and RFC8760 allow more than one WWW-Authenticate or
Proxy-Authenticate header per realm, each with different digest
algorithms (including new ones like SHA-256 and SHA-512-256).
Thankfully however a UAS can NOT send back multiple Authenticate
headers for the same realm with the same digest algorithm. The
UAS is also supposed to send the headers in order of preference
with the first one being the most preferred. We're supposed to
send an Authorization header for the first one we encounter for a
realm that we can support.
The UAS can also send multiple realms, especially when it's a
proxy that has forked the request in which case the proxy will
aggregate all of the Authenticate headers and then send them all
back to the UAC.
It doesn't stop there though... Each realm can require a
different username from the others. There's also nothing
preventing each digest algorithm from having a unique password
although I'm not sure if that adds any benefit.
So now... For each Authenticate header we encounter, we have to
determine if we support the digest algorithm and, if not, just
skip the header. We then have to find an auth object that
matches the realm AND the digest algorithm or find a wildcard
object that matches the digest algorithm. If we find one, we add
it to the results vector and read the next Authenticate header.
If the next header is for the same realm AND we already added an
auth object for that realm, we skip the header. Otherwise we
repeat the process for the next header.
In the end, we'll have accumulated a list of credentials we can
pass to pjproject that it can use to add Authentication headers
to a request.
NOTE: Neither we nor pjproject can currently handle digest
algorithms other than MD5. We don't even have a place for it in
the ast_sip_auth object. For this reason, we just skip processing
any Authenticate header that's not MD5. When we support the
others, we'll move the check into the loop that searches the
objects.
Changes:
* Added a new API ast_sip_retrieve_auths_vector() that takes in
a vector of auth ids (usually supplied on a call to
ast_sip_create_request_with_auth()) and populates another
vector with the actual objects.
* Refactored res_pjsip_outbound_authenticator_digest to handle
multiple Authenticate headers and set the stage for handling
additional digest algorithms.
* Added a pjproject patch that allows them to ignore digest
algorithms they don't support. This patch has already been
merged upstream.
* Updated documentation for auth objects in the XML and
in pjsip.conf.sample.
* Although res_pjsip_authenticator_digest isn't affected
by this change, some debugging and a testsuite AMI event
was added to facilitate testing.
Discovered during OpenSIPit 2021.
ASTERISK-29397
Change-Id: I3aef5ce4fe1d27e48d61268520f284d15d650281
This removes references that are no longer needed due to automatic
references created by module dependencies.
In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.
Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e
* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.
Still need to investigate dependencies among modules I cannot compile.
Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf
The inbound authentication object is supposed to be immutable when it is
stored in sorcery. However, the immutable property is violated if the
authentication object does not have a realm set.
The immutable contract violation has a different effect depending upon
what sorcery back end is used. If it is the config file back end you
would get the same object back until res_pjsip is reloaded. If it is the
real-time or AstDB back end you would get a new object on each query. If
it is cached you would get the same object back until it is refreshed from
the database.
Once an inbound authentication object has its realm set it may or may not
get updated again if the default_realm changes.
If the same authentication object is used for inbound and outbound
authentication then the immutable violation can make it very hard to
determine why the outbound authentication now fails. The only diagnostic
message is a complaint about no realms matching when it had worked
earlier. It fails because of the difference in behaviour for an empty
realm setting between inbound and outbound authentication objects.
* Fixed the sorcery object immutable violation by creating a new object
and setting the default_realm on it instead. The new object is a shallow
copy for speed.
* The auth_store thread storage no longer holds an auth ref. It
interferes with the shallow copy and never needed a ref anyway.
ASTERISK-26799 #close
Change-Id: I2328a52f61b78ed5fbba38180b7f183ee7e08956
From the issue reporter:
"res_pjsip_outbound_authenticator_digest builds a nonce that is a hash of
the timestamp, the source address, the source port, a server UUID that is
calculated at startup, and the authentication realm.
Rather than caching nonces that we create, we instead attempt to re-calculate
the nonce when receiving an incoming request with authentication. We then
compare the re-calculated nonce to the incoming nonce, and if they don't match,
then authentication has failed early.
The problem is that it is possible, especially when using TCP, to receive two
requests from the same endpoint but have differing source ports for those
requests. Asterisk itself commonly will use different source ports for
outbound TCP requests."
This patch removes the source port dependency when building the nonce.
ASTERISK-25978 #close
Change-Id: I871b5f4adce102df1c4988066283095ec509dffe
The res_pjsip_authenticator_digest, res_pjsip_endpoint_identifier_*
and res_pjsip_registrar modules should load ASAP
to avoid "No matching endpoint found" for legitimate endpoint.
ASTERISK-25994
Change-Id: Iac95d95ad031e0be104189d29e923a2ad7c24a1b
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
An md5 hash is 32 bytes long. The char buffer must be at least 33 bytes to
avoid clobbering of the stack. This patch also fixes a potential clobbering
in test_utils.c.
Thanks to Andrew Nagy for reporting and testing this out in #asterisk-dev
Reported by: Andrew Nagy
Tested by: Andrew Nagy
........
Merged revisions 404843 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When switching to using a vector for authentication, I initialized
the vector for the artificial endpoint to be of size 1. However, this
does not result in AST_VECTOR_SIZE() returning 1 since there isn't
actually anything in the vector.
Rather than trifle with the vector by putting unnecessary elements in,
I simply changed the callback in res_pjsip_authenticator_digest.c to
explicitly report that the artificial endpoint requires authentication.
Thanks to Joshua Colp for pointing this out.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403605 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, regardless of whether failure to authenticate was due to
lacking any authentication or actually failing authentication, the
Digest Authenticator would simply return that a challenge was still
needed. It will continue to do that when no authentication information
is in the received SIP digest, but when authentication information
is present and does not pass authentication, that will be treated as
an authentication error. This is to ensure that PJSIP will issue
security events indicated failed auths.
........
Merged revisions 402537 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this change, if no realm is specified in an outbound auth
section, then we will simply match the realm that was present
in the 401/407 challenge.
(closes issue ASTERISK-22471)
Reported by George Joseph
(closes issue ASTERISK-22386)
Reported by Rusty Newton
Patches:
outbound_auth_realm_v4.patch uploaded by George Joseph (License #6322)
........
Merged revisions 399059 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The general gist is to have a clear boundary between old SIP stuff
and new SIP stuff by having the word "SIP" for old stuff and "PJSIP"
for new stuff. Here's a brief rundown of the changes:
* The word "Gulp" in dialstrings, functions, and CLI commands is now
"PJSIP"
* chan_gulp.c is now chan_pjsip.c
* Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*"
* All files that were "res_sip*" are now "res_pjsip*"
* The "res_sip" directory is now "res_pjsip"
* Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*"
* The configuration file is now "pjsip.conf" instead of "res_sip.conf"
* The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP"
* CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as
the starting word instead of "sip"
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sungtae kim
Alexander Traud
George Joseph
Corey Farrell
Richard Mudgett
Kevin Harwell
Alexei Gradinari
George Joseph
Rodrigo Ramírez Norambuena
Kinsey Moore
Mark Michelson
Matthew Jordan
Jonathan Rose