2013-04-25 18:25:31 +00:00
|
|
|
/*
|
|
|
|
* Asterisk -- An open source telephony toolkit.
|
|
|
|
*
|
|
|
|
* Copyright (C) 2013, Digium, Inc.
|
|
|
|
*
|
|
|
|
* Mark Michelson <mmichelson@digium.com>
|
|
|
|
*
|
|
|
|
* See http://www.asterisk.org for more information about
|
|
|
|
* the Asterisk project. Please do not directly contact
|
|
|
|
* any of the maintainers of this project for assistance;
|
|
|
|
* the project provides a web site, mailing lists and IRC
|
|
|
|
* channels for your use.
|
|
|
|
*
|
|
|
|
* This program is free software, distributed under the terms of
|
|
|
|
* the GNU General Public License Version 2. See the LICENSE file
|
|
|
|
* at the top of the source tree.
|
|
|
|
*/
|
|
|
|
|
2024-10-17 08:02:08 -06:00
|
|
|
/*!
|
|
|
|
* \file
|
|
|
|
* \brief PJSIP UAC Authentication
|
|
|
|
*
|
|
|
|
* This module handles authentication when Asterisk is the UAC.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2013-04-26 21:52:06 +00:00
|
|
|
/*** MODULEINFO
|
|
|
|
<depend>pjproject</depend>
|
2013-07-30 18:14:50 +00:00
|
|
|
<depend>res_pjsip</depend>
|
2013-04-26 21:52:06 +00:00
|
|
|
<support_level>core</support_level>
|
|
|
|
***/
|
|
|
|
|
2013-04-25 18:25:31 +00:00
|
|
|
#include "asterisk.h"
|
|
|
|
|
|
|
|
#include <pjsip.h>
|
|
|
|
|
2013-07-30 18:14:50 +00:00
|
|
|
#include "asterisk/res_pjsip.h"
|
2013-04-25 18:25:31 +00:00
|
|
|
#include "asterisk/logger.h"
|
|
|
|
#include "asterisk/module.h"
|
|
|
|
#include "asterisk/strings.h"
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
#include "asterisk/vector.h"
|
2013-04-25 18:25:31 +00:00
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Determine proper authenticate header
|
|
|
|
*
|
|
|
|
* We need to search for different headers depending on whether
|
|
|
|
* the response code from the UAS/Proxy was 401 or 407.
|
|
|
|
*/
|
|
|
|
static pjsip_hdr_e get_auth_search_type(pjsip_rx_data *challenge)
|
|
|
|
{
|
2013-09-13 14:44:43 +00:00
|
|
|
if (challenge->msg_info.msg->line.status.code == PJSIP_SC_UNAUTHORIZED) {
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
return PJSIP_H_WWW_AUTHENTICATE;
|
2013-09-13 14:44:43 +00:00
|
|
|
} else if (challenge->msg_info.msg->line.status.code == PJSIP_SC_PROXY_AUTHENTICATION_REQUIRED) {
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
return PJSIP_H_PROXY_AUTHENTICATE;
|
2013-09-13 14:44:43 +00:00
|
|
|
} else {
|
|
|
|
ast_log(LOG_ERROR,
|
|
|
|
"Status code %d was received when it should have been 401 or 407.\n",
|
|
|
|
challenge->msg_info.msg->line.status.code);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
return PJSIP_H_OTHER;
|
2013-09-13 14:44:43 +00:00
|
|
|
}
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
}
|
2013-09-13 14:44:43 +00:00
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*!
|
|
|
|
* \internal
|
2024-10-17 08:02:08 -06:00
|
|
|
* \brief Determine if digest algorithm in the header is one supported by
|
|
|
|
* pjproject and OpenSSL.
|
|
|
|
*/
|
|
|
|
static const pjsip_auth_algorithm *get_supported_algorithm(pjsip_www_authenticate_hdr *auth_hdr)
|
|
|
|
{
|
|
|
|
const pjsip_auth_algorithm *algo = NULL;
|
|
|
|
|
|
|
|
algo = ast_sip_auth_get_algorithm_by_iana_name(&auth_hdr->challenge.digest.algorithm);
|
|
|
|
if (!algo) {
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ast_sip_auth_is_algorithm_supported(algo->algorithm_type)) {
|
|
|
|
return algo;
|
|
|
|
}
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
AST_VECTOR(cred_info_vector, pjsip_cred_info);
|
|
|
|
|
|
|
|
/*!
|
|
|
|
* \brief Get credentials (if any) from auth objects for a WWW/Proxy-Authenticate header
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
*
|
2024-10-17 08:02:08 -06:00
|
|
|
* \param id For logging
|
|
|
|
* \param src_name For logging
|
|
|
|
* \param auth_hdr The *-Authenticate header to check
|
|
|
|
* \param auth_object_count The number of auth objects available
|
|
|
|
* \param auth_objects_vector The vector of available auth objects
|
|
|
|
* \param auth_creds The vector to store the credentials in
|
|
|
|
* \param realms For logging
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
*
|
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
static void get_creds_for_header(const char *id, const char *src_name,
|
|
|
|
pjsip_www_authenticate_hdr *auth_hdr, size_t auth_object_count,
|
|
|
|
const struct ast_sip_auth_objects_vector *auth_objects_vector,
|
|
|
|
struct cred_info_vector *auth_creds, struct ast_str **realms)
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
{
|
2024-10-17 08:02:08 -06:00
|
|
|
int exact_match_index = -1;
|
|
|
|
int wildcard_match_index = -1;
|
|
|
|
struct ast_sip_auth *found_auth = NULL;
|
|
|
|
const pjsip_auth_algorithm *challenge_algorithm =
|
|
|
|
get_supported_algorithm(auth_hdr);
|
|
|
|
int i = 0;
|
|
|
|
pjsip_cred_info auth_cred;
|
|
|
|
const char *cred_data;
|
|
|
|
int res = 0;
|
|
|
|
SCOPE_ENTER(4, "%s:%s: Testing header realm: '" PJSTR_PRINTF_SPEC "' algorithm: '"
|
|
|
|
PJSTR_PRINTF_SPEC "'\n", id, src_name,
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.algorithm));
|
|
|
|
|
|
|
|
if (!challenge_algorithm) {
|
|
|
|
SCOPE_EXIT_RTN("%s:%s: Skipping header with realm '" PJSTR_PRINTF_SPEC "' "
|
|
|
|
"and unsupported " PJSTR_PRINTF_SPEC "' algorithm \n", id, src_name,
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.algorithm));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we already have credentials for this realm, we don't need to
|
|
|
|
* process this header. We can just skip it.
|
|
|
|
*/
|
|
|
|
for (i = 0; i < AST_VECTOR_SIZE(auth_creds); i++) {
|
|
|
|
pjsip_cred_info auth_cred = AST_VECTOR_GET(auth_creds, i);
|
|
|
|
if (pj_stricmp(&auth_cred.realm, &auth_hdr->challenge.common.realm) == 0) {
|
|
|
|
SCOPE_EXIT_RTN("%s:%s: Skipping header with realm '" PJSTR_PRINTF_SPEC "' "
|
|
|
|
"because we already have credentials for it\n", id, src_name,
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm));
|
|
|
|
}
|
|
|
|
}
|
2013-09-13 14:44:43 +00:00
|
|
|
|
2024-10-17 08:02:08 -06:00
|
|
|
/*
|
|
|
|
* Appending "realm/agorithm" to realms is strictly so
|
|
|
|
* digest_create_request_with_auth() can display good error messages.
|
|
|
|
*/
|
|
|
|
if (*realms) {
|
|
|
|
ast_str_append(realms, 0, PJSTR_PRINTF_SPEC "/" PJSTR_PRINTF_SPEC ", ",
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.algorithm));
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
}
|
|
|
|
|
2024-10-17 08:02:08 -06:00
|
|
|
/*
|
|
|
|
* Now that we have a valid header, we can loop over the auths available to
|
|
|
|
* find either an exact realm match or, failing that, a wildcard auth (an
|
|
|
|
* auth with an empty or "*" realm).
|
|
|
|
*
|
|
|
|
* NOTE: We never use the global default realm when we're the UAC responding
|
|
|
|
* to a 401 or 407. We only use that when we're the UAS (handled elsewhere)
|
|
|
|
* and the auth object didn't have a realm.
|
|
|
|
*/
|
|
|
|
ast_trace(-1, "%s:%s: Searching %zu auths to find matching ones for header with realm "
|
|
|
|
"'" PJSTR_PRINTF_SPEC "' and algorithm '" PJSTR_PRINTF_SPEC "'\n",
|
|
|
|
id, src_name, auth_object_count,
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.algorithm));
|
|
|
|
|
|
|
|
for (i = 0; i < auth_object_count; ++i) {
|
|
|
|
struct ast_sip_auth *auth = AST_VECTOR_GET(auth_objects_vector, i);
|
|
|
|
const char *auth_id = ast_sorcery_object_get_id(auth);
|
|
|
|
SCOPE_ENTER(5, "%s:%s: Checking auth '%s' with realm '%s'\n",
|
|
|
|
id, src_name, auth_id, auth->realm);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Is the challenge algorithm in the auth's supported_algorithms_uac
|
|
|
|
* and is there either a plain text password or a password_digest
|
|
|
|
* for the algorithm?
|
|
|
|
*/
|
|
|
|
if (!ast_sip_auth_is_algorithm_available(auth, &auth->supported_algorithms_uac,
|
|
|
|
challenge_algorithm->algorithm_type)) {
|
|
|
|
SCOPE_EXIT_EXPR(continue, "%s:%s: Skipping auth '%s' with realm '%s' because it doesn't support "
|
|
|
|
" algorithm '" PJSTR_PRINTF_SPEC "'\n", id, src_name,
|
|
|
|
auth_id, auth->realm,
|
|
|
|
PJSTR_PRINTF_VAR(challenge_algorithm->iana_name));
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
}
|
2024-10-17 08:02:08 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If this auth object's realm exactly matches the one
|
|
|
|
* from the header, we can just break out and use it.
|
|
|
|
*
|
|
|
|
* NOTE: If there's more than one auth object for an endpoint with
|
|
|
|
* a matching realm it's a misconfiguration. We'll only use the first.
|
|
|
|
*/
|
|
|
|
if (pj_stricmp2(&auth_hdr->challenge.digest.realm, auth->realm) == 0) {
|
|
|
|
exact_match_index = i;
|
|
|
|
/*
|
|
|
|
* If we found an exact realm match, there's no need to keep
|
|
|
|
* looking for a wildcard.
|
|
|
|
*/
|
|
|
|
SCOPE_EXIT_EXPR(break, "%s:%s: Found matching auth '%s' with realm '%s'\n",
|
|
|
|
id, src_name, auth_id, auth->realm);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If this auth object's realm is empty or a "*", it's a wildcard
|
|
|
|
* auth object. We going to save its index but keep iterating over
|
|
|
|
* the vector in case we find an exact match later.
|
|
|
|
*
|
|
|
|
* NOTE: If there's more than one wildcard auth object for an endpoint
|
|
|
|
* it's a misconfiguration. We'll only use the first.
|
|
|
|
*/
|
|
|
|
if (wildcard_match_index < 0
|
|
|
|
&& (ast_strlen_zero(auth->realm) || ast_strings_equal(auth->realm, "*"))) {
|
|
|
|
ast_trace(-1, "%s:%s: Found wildcard auth '%s' for realm '" PJSTR_PRINTF_SPEC "'\n",
|
|
|
|
id, src_name, auth_id,
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm));
|
|
|
|
wildcard_match_index = i;
|
|
|
|
}
|
|
|
|
SCOPE_EXIT("%s:%s: Done checking auth '%s' with realm '%s'. "
|
|
|
|
"Found exact? %s Found wildcard? %s\n", id, src_name,
|
|
|
|
auth_id, auth->realm, exact_match_index >= 0 ? "yes" : "no",
|
|
|
|
wildcard_match_index >= 0 ? "yes" : "no");
|
|
|
|
} /* End auth object loop */
|
|
|
|
|
|
|
|
if (exact_match_index < 0 && wildcard_match_index < 0) {
|
|
|
|
/*
|
|
|
|
* Didn't find either a wildcard or an exact realm match.
|
|
|
|
* Move on to the next header.
|
|
|
|
*/
|
|
|
|
SCOPE_EXIT_RTN("%s:%s: No auth matching realm or no wildcard found for realm '" PJSTR_PRINTF_SPEC "'\n",
|
|
|
|
id, src_name, PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm));
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
}
|
2024-10-17 08:02:08 -06:00
|
|
|
|
|
|
|
if (exact_match_index >= 0) {
|
|
|
|
/*
|
|
|
|
* If we found an exact match, we'll always prefer that.
|
|
|
|
*/
|
|
|
|
found_auth = AST_VECTOR_GET(auth_objects_vector, exact_match_index);
|
|
|
|
ast_trace(-1, "%s:%s: Using matched auth '%s' with realm '" PJSTR_PRINTF_SPEC "'\n",
|
|
|
|
id, src_name, ast_sorcery_object_get_id(found_auth),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm));
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* We'll only use the wildcard if we didn't find an exact match.
|
|
|
|
*/
|
|
|
|
found_auth = AST_VECTOR_GET(auth_objects_vector, wildcard_match_index);
|
|
|
|
ast_trace(-1, "%s:%s: Using wildcard auth '%s' for realm '" PJSTR_PRINTF_SPEC "'\n",
|
|
|
|
id, src_name, ast_sorcery_object_get_id(found_auth),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm));
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Now that we have an auth object to use, we need to create a
|
|
|
|
* pjsip_cred_info structure for each algorithm we support.
|
|
|
|
*/
|
|
|
|
|
|
|
|
memset(&auth_cred, 0, sizeof(auth_cred));
|
|
|
|
/*
|
|
|
|
* Copy the fields from the auth_object to the
|
|
|
|
* pjsip_cred_info structure.
|
|
|
|
*/
|
|
|
|
auth_cred.realm = auth_hdr->challenge.common.realm;
|
|
|
|
pj_cstr(&auth_cred.username, found_auth->auth_user);
|
|
|
|
pj_cstr(&auth_cred.scheme, "digest");
|
|
|
|
|
|
|
|
/*
|
|
|
|
* auth_cred.data_type tells us whether the credential is a plain text
|
|
|
|
* password or a pre-digested one.
|
|
|
|
*/
|
|
|
|
cred_data = SCOPE_CALL_WITH_RESULT(-1, const char *, ast_sip_auth_get_creds,
|
|
|
|
found_auth, challenge_algorithm->algorithm_type, &auth_cred.data_type);
|
|
|
|
/*
|
|
|
|
* This can't really fail because we already called
|
|
|
|
* ast_sip_auth_is_algorithm_available() for the auth
|
|
|
|
* but we check anyway.
|
|
|
|
*/
|
|
|
|
if (!cred_data) {
|
|
|
|
SCOPE_EXIT_RTN("%s:%s: Shouldn't have happened\n", id, src_name);
|
|
|
|
}
|
|
|
|
|
|
|
|
pj_cstr(&auth_cred.data, cred_data);
|
|
|
|
#ifdef HAVE_PJSIP_AUTH_NEW_DIGESTS
|
|
|
|
if (auth_cred.data_type == PJSIP_CRED_DATA_DIGEST) {
|
|
|
|
auth_cred.algorithm_type = challenge_algorithm->algorithm_type;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
/*
|
|
|
|
* Because the vector contains actual structures and not pointers
|
|
|
|
* to structures, the call to AST_VECTOR_APPEND results in a simple
|
|
|
|
* assign of one structure to another, effectively copying the auth_cred
|
|
|
|
* structure contents to the array element.
|
|
|
|
*
|
|
|
|
* Also note that the calls to pj_cstr above set their respective
|
|
|
|
* auth_cred fields to the _pointers_ of their corresponding auth
|
|
|
|
* object fields. This is safe because the call to
|
|
|
|
* pjsip_auth_clt_set_credentials() below strdups them before we
|
|
|
|
* return to the calling function which decrements the reference
|
|
|
|
* counts.
|
|
|
|
*/
|
|
|
|
res = AST_VECTOR_APPEND(auth_creds, auth_cred);
|
|
|
|
SCOPE_EXIT_RTN("%s:%s: %s credential for realm: '" PJSTR_PRINTF_SPEC "' algorithm: '"
|
|
|
|
PJSTR_PRINTF_SPEC "'\n", id, src_name,
|
|
|
|
res == 0 ? "Added" : "Failed to add",
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.realm),
|
|
|
|
PJSTR_PRINTF_VAR(auth_hdr->challenge.digest.algorithm));
|
2013-09-13 14:44:43 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Initialize pjproject with a valid set of credentials
|
|
|
|
*
|
|
|
|
* 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). However,
|
2024-10-17 08:02:08 -06:00
|
|
|
* a UAS can NOT send back multiple Authenticate headers for
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
* 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
|
2024-10-17 08:02:08 -06:00
|
|
|
* of the Authenticate headers into one response back to the UAC.
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
2024-10-17 08:02:08 -06:00
|
|
|
* So now... For each WWW/Proxy-Authenticate header we encounter, we have to
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
* 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.
|
|
|
|
*
|
2024-10-17 08:02:08 -06:00
|
|
|
* In the end, we'll have accumulated a list of credentials, one per realm,
|
|
|
|
* we can pass to pjproject that it can use to add Authentication headers
|
|
|
|
* to a request.
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
static pj_status_t set_auth_creds(const char *id, pjsip_auth_clt_sess *auth_sess,
|
|
|
|
const struct ast_sip_auth_objects_vector *auth_objects_vector,
|
|
|
|
pjsip_rx_data *challenge, struct ast_str **realms)
|
2013-04-25 18:25:31 +00:00
|
|
|
{
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
size_t auth_object_count;
|
|
|
|
pjsip_www_authenticate_hdr *auth_hdr = NULL;
|
|
|
|
pj_status_t res = PJ_SUCCESS;
|
|
|
|
pjsip_hdr_e search_type;
|
2024-10-17 08:02:08 -06:00
|
|
|
size_t cred_count = 0;
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
pjsip_cred_info *creds_array;
|
2024-10-17 08:02:08 -06:00
|
|
|
char *pj_err = NULL;
|
|
|
|
const char *src_name = challenge->pkt_info.src_name;
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*
|
|
|
|
* Normally vector elements are pointers to something else, usually
|
|
|
|
* structures. In this case however, the elements are the
|
|
|
|
* structures themselves instead of pointers to them. This is due
|
|
|
|
* to the fact that pjsip_auth_clt_set_credentials() expects an
|
2021-10-30 21:04:36 -04:00
|
|
|
* array of structures, not an array of pointers to structures.
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
* Thankfully, vectors allow you to "steal" their underlying
|
|
|
|
* arrays, in this case an array of pjsip_cred_info structures,
|
|
|
|
* which we'll pass to pjsip_auth_clt_set_credentials() at the
|
|
|
|
* end.
|
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
struct cred_info_vector auth_creds;
|
|
|
|
SCOPE_ENTER(3, "%s:%s\n", id, src_name);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
|
|
|
|
search_type = get_auth_search_type(challenge);
|
|
|
|
if (search_type == PJSIP_H_OTHER) {
|
|
|
|
/*
|
|
|
|
* The status code on the response wasn't 401 or 407
|
|
|
|
* so there are no WWW-Authenticate or Proxy-Authenticate
|
|
|
|
* headers to process.
|
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
SCOPE_EXIT_RTN_VALUE(PJ_ENOTSUP, "%s:%s: Status code %d was received when it should have been 401 or 407.\n",
|
|
|
|
id, src_name, challenge->msg_info.msg->line.status.code);
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
auth_object_count = AST_VECTOR_SIZE(auth_objects_vector);
|
|
|
|
if (auth_object_count == 0) {
|
|
|
|
/* This shouldn't happen but we'll check anyway. */
|
2024-10-17 08:02:08 -06:00
|
|
|
SCOPE_EXIT_RTN_VALUE(PJ_EINVAL, "%s:%s No auth objects available\n", id, src_name);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The number of pjsip_cred_infos we send to pjproject can
|
|
|
|
* vary based on the number of acceptable headers received
|
|
|
|
* and the number of acceptable auth objects on the endpoint
|
|
|
|
* so we just use a vector to accumulate them.
|
|
|
|
*
|
|
|
|
* NOTE: You have to call AST_VECTOR_FREE() on the vector
|
|
|
|
* but you don't have to free the elements because they're
|
|
|
|
* actual structures, not pointers to structures.
|
|
|
|
*/
|
|
|
|
if (AST_VECTOR_INIT(&auth_creds, 5) != 0) {
|
2024-10-17 08:02:08 -06:00
|
|
|
SCOPE_EXIT_RTN_VALUE(PJ_ENOMEM);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2024-10-17 08:02:08 -06:00
|
|
|
* There may be multiple WWW/Proxy-Authenticate headers each one having
|
|
|
|
* a different realm/algorithm pair. Test each to see if we have credentials
|
|
|
|
* for it and accumulate them in the auth_creds vector.
|
|
|
|
* The code doesn't really care but just for reference, RFC-7616 says
|
|
|
|
* a UAS can't send multiple headers for the same realm with the same
|
|
|
|
* algorithm. It also says the UAS should send the headers in order
|
|
|
|
* of preference with the first one being the most preferred.
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
*/
|
|
|
|
while ((auth_hdr = pjsip_msg_find_hdr(challenge->msg_info.msg,
|
|
|
|
search_type, auth_hdr ? auth_hdr->next : NULL))) {
|
|
|
|
|
2024-10-17 08:02:08 -06:00
|
|
|
get_creds_for_header(id, src_name, auth_hdr, auth_object_count,
|
|
|
|
auth_objects_vector, &auth_creds, realms);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
|
|
|
|
} /* End header loop */
|
|
|
|
|
|
|
|
if (*realms && ast_str_strlen(*realms)) {
|
|
|
|
/*
|
2024-10-17 08:02:08 -06:00
|
|
|
* Chop off the trailing ", " on the last realm-algorithm.
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
*/
|
|
|
|
ast_str_truncate(*realms, ast_str_strlen(*realms) - 2);
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
if (AST_VECTOR_SIZE(&auth_creds) == 0) {
|
|
|
|
/* No matching auth objects were found. */
|
|
|
|
res = PJSIP_ENOCREDENTIAL;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Here's where we steal the cred info structures from the vector.
|
|
|
|
*
|
|
|
|
* The steal effectively returns a pointer to the underlying
|
|
|
|
* array of pjsip_cred_info structures which is exactly what we need
|
|
|
|
* to pass to pjsip_auth_clt_set_credentials().
|
|
|
|
*
|
|
|
|
* <struct cred info><struct cred info>...<struct cred info>
|
|
|
|
* ^pointer
|
|
|
|
*
|
|
|
|
* Since we stole the array from the vector, we have to free it ourselves.
|
|
|
|
*
|
|
|
|
* We also have to copy the size before we steal because stealing
|
|
|
|
* resets the vector size to 0.
|
|
|
|
*/
|
|
|
|
cred_count = AST_VECTOR_SIZE(&auth_creds);
|
|
|
|
creds_array = AST_VECTOR_STEAL_ELEMENTS(&auth_creds);
|
|
|
|
|
|
|
|
res = pjsip_auth_clt_set_credentials(auth_sess, cred_count, creds_array);
|
|
|
|
ast_free(creds_array);
|
2013-04-25 18:25:31 +00:00
|
|
|
|
|
|
|
cleanup:
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
AST_VECTOR_FREE(&auth_creds);
|
2024-10-17 08:02:08 -06:00
|
|
|
if (res != PJ_SUCCESS) {
|
|
|
|
pj_err = ast_alloca(PJ_ERR_MSG_SIZE);
|
|
|
|
pj_strerror(res, pj_err, PJ_ERR_MSG_SIZE);
|
|
|
|
}
|
|
|
|
SCOPE_EXIT_RTN_VALUE(res, "%s:%s: Set %zu credentials in auth session: %s\n",
|
|
|
|
id, src_name, cred_count, S_OR(pj_err, "success"));
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*!
|
|
|
|
* \internal
|
|
|
|
* \brief Create new tdata with auth based on original tdata
|
|
|
|
* \param auth_ids_vector Vector of auth IDs retrieved from endpoint
|
|
|
|
* \param challenge rdata of the response from the UAS with challenge
|
|
|
|
* \param old_request tdata from the original request
|
|
|
|
* \param new_request tdata of the new request with the auth
|
|
|
|
*
|
|
|
|
* This function is what's registered with ast_sip_register_outbound_authenticator()
|
|
|
|
*
|
|
|
|
* \retval 0 success
|
|
|
|
* \retval -1 failure
|
|
|
|
*/
|
|
|
|
static int digest_create_request_with_auth(const struct ast_sip_auth_vector *auth_ids_vector,
|
2017-04-28 09:56:20 -06:00
|
|
|
pjsip_rx_data *challenge, pjsip_tx_data *old_request, pjsip_tx_data **new_request)
|
2013-04-25 18:25:31 +00:00
|
|
|
{
|
|
|
|
pjsip_auth_clt_sess auth_sess;
|
2015-04-24 09:17:25 -05:00
|
|
|
pjsip_cseq_hdr *cseq;
|
2016-11-14 14:36:52 -06:00
|
|
|
pj_status_t status;
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
struct ast_sip_auth_objects_vector auth_objects_vector;
|
|
|
|
size_t auth_object_count = 0;
|
2024-10-17 08:02:08 -06:00
|
|
|
pjsip_dialog *dlg = pjsip_rdata_get_dlg(challenge);
|
|
|
|
struct ast_sip_endpoint *endpoint = (dlg ? ast_sip_dialog_get_endpoint(dlg) : NULL);
|
|
|
|
/*
|
|
|
|
* We're ast_strdupa'ing the endpoint id because we're going to
|
|
|
|
* clean up the endpoint immediately after this. We only needed
|
|
|
|
* it to get the id for logging.
|
|
|
|
*/
|
|
|
|
char *endpoint_id = endpoint ? ast_strdupa(ast_sorcery_object_get_id(endpoint)) : NULL;
|
|
|
|
char *id = endpoint_id ?: "noendpoint";
|
|
|
|
char *src_name = challenge->pkt_info.src_name;
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
struct ast_str *realms = NULL;
|
|
|
|
int res = -1;
|
2024-10-17 08:02:08 -06:00
|
|
|
char *pj_err = NULL;
|
|
|
|
SCOPE_ENTER(3, "%s:%s\n", id, src_name);
|
|
|
|
|
|
|
|
/* We only needed endpoint to get the id */
|
|
|
|
ao2_cleanup(endpoint);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Some older compilers have an issue with initializing structures with
|
|
|
|
* pjsip_auth_clt_sess auth_sess = { 0, };
|
|
|
|
* so we'll just do it the old fashioned way.
|
|
|
|
*/
|
|
|
|
memset(&auth_sess, 0, sizeof(auth_sess));
|
2017-04-28 09:56:20 -06:00
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
if (!auth_ids_vector || AST_VECTOR_SIZE(auth_ids_vector) == 0) {
|
2024-10-17 08:02:08 -06:00
|
|
|
SCOPE_EXIT_LOG_RTN_VALUE(-1, LOG_ERROR, "%s:%s: There were no auth ids available\n",
|
|
|
|
id, src_name);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
|
2024-10-17 08:02:08 -06:00
|
|
|
/*
|
|
|
|
* auth_ids_vector contains only ids but we need the complete objects.
|
|
|
|
*/
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
if (AST_VECTOR_INIT(&auth_objects_vector, AST_VECTOR_SIZE(auth_ids_vector)) != 0) {
|
2024-10-17 08:02:08 -06:00
|
|
|
SCOPE_EXIT_LOG_RTN_VALUE(-1, LOG_ERROR, "%s:%s: Couldn't initialize auth object vector\n",
|
|
|
|
id, src_name);
|
2017-04-28 09:56:20 -06:00
|
|
|
}
|
2013-04-25 18:25:31 +00:00
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*
|
|
|
|
* We don't really care about ast_sip_retrieve_auths_vector()'s return code
|
|
|
|
* because we're checking the count of objects in the vector.
|
|
|
|
*
|
|
|
|
* Don't forget to call
|
|
|
|
* ast_sip_cleanup_auth_objects_vector(&auth_objects_vector);
|
|
|
|
* AST_VECTOR_FREE(&auth_objects_vector);
|
|
|
|
* when you're done with the vector
|
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
ast_trace(-1, "%s:%s: Retrieving %d auth objects\n", id, src_name,
|
|
|
|
(int)AST_VECTOR_SIZE(auth_ids_vector));
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
ast_sip_retrieve_auths_vector(auth_ids_vector, &auth_objects_vector);
|
|
|
|
auth_object_count = AST_VECTOR_SIZE(&auth_objects_vector);
|
|
|
|
if (auth_object_count == 0) {
|
|
|
|
/*
|
|
|
|
* If none of the auth ids were found, we can't continue.
|
|
|
|
* We're OK if there's at least one left.
|
|
|
|
* ast_sip_retrieve_auths_vector() will print a warning for every
|
|
|
|
* id that wasn't found.
|
|
|
|
*/
|
|
|
|
res = -1;
|
2024-10-17 08:02:08 -06:00
|
|
|
ast_trace(-1, "%s:%s: No auth objects found\n", id, src_name);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
goto cleanup;
|
|
|
|
}
|
2024-10-17 08:02:08 -06:00
|
|
|
ast_trace(-1, "%s:%s: Retrieved %d auth objects\n", id, src_name,
|
|
|
|
(int)auth_object_count);
|
|
|
|
|
|
|
|
status = pjsip_auth_clt_init(&auth_sess, ast_sip_get_pjsip_endpoint(),
|
|
|
|
old_request->pool, 0);
|
|
|
|
if (status != PJ_SUCCESS) {
|
|
|
|
pj_err = ast_alloca(PJ_ERR_MSG_SIZE);
|
|
|
|
pj_strerror(status, pj_err, PJ_ERR_MSG_SIZE);
|
|
|
|
ast_log(LOG_ERROR, "%s:%s: Failed to initialize client authentication session: %s\n",
|
|
|
|
id, src_name, pj_err);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
res = -1;
|
|
|
|
goto cleanup;
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*
|
|
|
|
* realms is used only for displaying good error messages.
|
|
|
|
*/
|
|
|
|
realms = ast_str_create(32);
|
|
|
|
if (!realms) {
|
|
|
|
res = -1;
|
|
|
|
goto cleanup;
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*
|
|
|
|
* Load pjproject with the valid credentials for the Authentication headers
|
|
|
|
* received on the 401 or 407 response.
|
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
status = SCOPE_CALL_WITH_RESULT(-1, pj_status_t, set_auth_creds, id, &auth_sess, &auth_objects_vector, challenge, &realms);
|
|
|
|
if (status != PJ_SUCCESS && status != PJSIP_ENOCREDENTIAL) {
|
|
|
|
pj_err = ast_alloca(PJ_ERR_MSG_SIZE);
|
|
|
|
}
|
|
|
|
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
switch (status) {
|
|
|
|
case PJ_SUCCESS:
|
|
|
|
break;
|
|
|
|
case PJSIP_ENOCREDENTIAL:
|
|
|
|
ast_log(LOG_WARNING,
|
2024-10-17 08:02:08 -06:00
|
|
|
"%s:%s: No auth objects matching realm/algorithm(s) '%s' from challenge found.\n",
|
|
|
|
id, src_name, realms ? ast_str_buffer(realms) : "<none>");
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
res = -1;
|
|
|
|
goto cleanup;
|
|
|
|
default:
|
2024-10-17 08:02:08 -06:00
|
|
|
pj_strerror(status, pj_err, PJ_ERR_MSG_SIZE);
|
|
|
|
ast_log(LOG_WARNING, "%s:%s: Failed to set authentication credentials: %s\n",
|
|
|
|
id, src_name, pj_err);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
res = -1;
|
|
|
|
goto cleanup;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* reinit_req actually creates the Authorization headers to send on
|
|
|
|
* the next request. If reinit_req already has a cached credential
|
|
|
|
* from an earlier successful authorization, it'll use it. Otherwise
|
|
|
|
* it'll create a new authorization and cache it.
|
|
|
|
*/
|
2024-10-17 08:02:08 -06:00
|
|
|
status = SCOPE_CALL_WITH_RESULT(-1, pj_status_t, pjsip_auth_clt_reinit_req,
|
|
|
|
&auth_sess, challenge, old_request, new_request);
|
|
|
|
if (status != PJ_SUCCESS) {
|
|
|
|
pj_err = ast_alloca(PJ_ERR_MSG_SIZE);
|
|
|
|
}
|
2017-04-28 09:56:20 -06:00
|
|
|
|
2016-11-14 14:36:52 -06:00
|
|
|
switch (status) {
|
2013-09-04 22:49:25 +00:00
|
|
|
case PJ_SUCCESS:
|
2015-04-24 09:17:25 -05:00
|
|
|
/* PJSIP creates a new transaction for new_request (meaning it creates a new
|
|
|
|
* branch). However, it recycles the Call-ID, from-tag, and CSeq from the
|
|
|
|
* original request. Some SIP implementations will not process the new request
|
|
|
|
* since the CSeq is the same as the original request. Incrementing it here
|
|
|
|
* fixes the interop issue
|
|
|
|
*/
|
|
|
|
cseq = pjsip_msg_find_hdr((*new_request)->msg, PJSIP_H_CSEQ, NULL);
|
|
|
|
ast_assert(cseq != NULL);
|
|
|
|
++cseq->cseq;
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
res = 0;
|
2024-10-17 08:02:08 -06:00
|
|
|
ast_trace(-1, "%s:%s: Created new request with auth\n", id, src_name);
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
goto cleanup;
|
2013-09-04 22:49:25 +00:00
|
|
|
case PJSIP_ENOCREDENTIAL:
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
/*
|
|
|
|
* This should be rare since set_outbound_authentication_credentials()
|
|
|
|
* did the matching but you never know.
|
|
|
|
*/
|
2017-01-01 03:47:50 -06:00
|
|
|
ast_log(LOG_WARNING,
|
2024-10-17 08:02:08 -06:00
|
|
|
"%s:%s: No auth objects matching realm(s) '%s' from challenge found.\n",
|
|
|
|
id, src_name, realms ? ast_str_buffer(realms) : "<none>");
|
2013-09-04 22:49:25 +00:00
|
|
|
break;
|
|
|
|
case PJSIP_EAUTHSTALECOUNT:
|
2024-10-17 08:02:08 -06:00
|
|
|
pj_strerror(status, pj_err, PJ_ERR_MSG_SIZE);
|
2017-01-01 03:47:50 -06:00
|
|
|
ast_log(LOG_WARNING,
|
2024-10-17 08:02:08 -06:00
|
|
|
"%s:%s: Unable to create request with auth: %s\n",
|
|
|
|
id, src_name, pj_err);
|
2013-09-04 22:49:25 +00:00
|
|
|
break;
|
|
|
|
case PJSIP_EFAILEDCREDENTIAL:
|
2024-10-17 08:02:08 -06:00
|
|
|
pj_strerror(status, pj_err, PJ_ERR_MSG_SIZE);
|
|
|
|
ast_log(LOG_WARNING, "%s:%s: Authentication credentials not accepted by server. %s\n",
|
|
|
|
id, src_name, pj_err);
|
2013-09-04 22:49:25 +00:00
|
|
|
break;
|
|
|
|
default:
|
2024-10-17 08:02:08 -06:00
|
|
|
pj_strerror(status, pj_err, PJ_ERR_MSG_SIZE);
|
|
|
|
ast_log(LOG_WARNING, "%s:%s: Unable to create request with auth: %s\n",
|
|
|
|
id, src_name, pj_err);
|
2013-09-04 22:49:25 +00:00
|
|
|
break;
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
res = -1;
|
|
|
|
|
|
|
|
cleanup:
|
|
|
|
#if defined(HAVE_PJSIP_AUTH_CLT_DEINIT)
|
2022-01-31 06:09:09 -07:00
|
|
|
/* If we initialized the auth_sess, clean it up */
|
|
|
|
if (auth_sess.endpt) {
|
|
|
|
pjsip_auth_clt_deinit(&auth_sess);
|
|
|
|
}
|
res_pjsip_outbound_authenticator_digest: Be tolerant of RFC8760 UASs
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
2021-04-15 09:43:48 -06:00
|
|
|
#endif
|
|
|
|
|
|
|
|
ast_sip_cleanup_auth_objects_vector(&auth_objects_vector);
|
|
|
|
AST_VECTOR_FREE(&auth_objects_vector);
|
|
|
|
ast_free(realms);
|
2013-04-25 18:25:31 +00:00
|
|
|
|
2024-10-17 08:02:08 -06:00
|
|
|
SCOPE_EXIT_RTN_VALUE(res, "%s:%s: result: %s\n", id, src_name,
|
|
|
|
res == 0 ? "success" : "failure");
|
2013-04-25 18:25:31 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct ast_sip_outbound_authenticator digest_authenticator = {
|
|
|
|
.create_request_with_auth = digest_create_request_with_auth,
|
|
|
|
};
|
|
|
|
|
|
|
|
static int load_module(void)
|
|
|
|
{
|
|
|
|
if (ast_sip_register_outbound_authenticator(&digest_authenticator)) {
|
|
|
|
return AST_MODULE_LOAD_DECLINE;
|
|
|
|
}
|
|
|
|
return AST_MODULE_LOAD_SUCCESS;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int unload_module(void)
|
|
|
|
{
|
|
|
|
ast_sip_unregister_outbound_authenticator(&digest_authenticator);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-07-30 18:14:50 +00:00
|
|
|
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_LOAD_ORDER, "PJSIP authentication resource",
|
2015-05-05 20:49:04 -04:00
|
|
|
.support_level = AST_MODULE_SUPPORT_CORE,
|
|
|
|
.load = load_module,
|
|
|
|
.unload = unload_module,
|
|
|
|
.load_pri = AST_MODPRI_CHANNEL_DEPEND,
|
2017-11-19 17:30:49 -05:00
|
|
|
.requires = "res_pjsip",
|
2013-04-25 18:25:31 +00:00
|
|
|
);
|