OpenSIPit 2021 was held back in April with myself and Ben Ford representing Asterisk. There were two main interoperability focuses this year: the support of additional authentication digest algorithms specified by RFC-8760, and STIR/SHAKEN. This post addresses the former.
RFC 8760: The Session Initiation Protocol (SIP) Digest Access Authentication Scheme
A Bit Of History
As you may know, SIP uses the same authentication/authorization mechanism as HTTP. Originally defined in RFC-2617 in June 1999, it considered the MD5 digest algorithm to be secure and allowed only that algorithm. Only a few years later though, it was discovered to not be as secure as initially thought. Advances in processor technology made attacks much more feasible. In September 2015, RFC-7616 was published which specified two new digest algorithms for HTTP, SHA-256 and SHA-512/256, with MD5 kept for backward compatibility. Finally in March 2020, RFC-8760 was published which outlined how this all applies to SIP.
So, how does this apply to SIP?
For the better part of two decades, things were simple. A UAC sent a request to a UAS and the UAS responded with one WWW-Authenticate header using the MD5 hash algorithm. The UAC then responded with one Authorization header. There were cases involving proxies that were a little more complicated but not by much. With RFC-8760 however…
- A UAS can respond with multiple WWW-Authenticate headers for the same realm. If multiple headers are sent, each must have a different algorithm, with the most preferred one first.
- A UAS can respond with multiple realms. While technically this was always true, a UAS responding with two realms, each with three algorithms means six WWW-Authenticate headers.
- The UAC has to process each of the WWW-Authenticate headers for a realm first-to-last. For UACs like Asterisk, it means searching for an authentication entry in its configuration database that matches the specific endpoint, the realm, and the algorithm. Failing to find one for the specific realm, it then has to check any defined wildcard auth entries for an algorithm match.
- The UAC then sends one Authorization header for each realm (assuming it found one for the realm) in the followup request.
So, how does this apply to Asterisk?
Going into OpenSIPit#01, we knew Asterisk didn’t support the additional algorithms required for RFC-8760 Interoperability. What we discovered though was that Asterisk wasn’t tolerant of them either. If a UAS sent us two WWW-Authenticate headers, the first with SHA-256 and the second with MD5, we saw the SHA-256 algorithm in the first header and just gave up. If we’d kept looking however, we’d have seen the header with MD5 and could probably have processed it. The fix for this wasn’t quite as straightforward as you’d think because, as you may know, Asterisk relies on PJSIP for much of the underlying SIP protocol handling. This required us to coordinate changes to both projects to at least make them both tolerant of receiving the new algorithms even if we didn’t yet support them. That work was completed in May and is included in Asterisk releases 16.19.0 and 18.5.0.
What’s next?
Full RFC-8760 Interoperability means we still need to support the new algorithms but again, this means changes to both Asterisk and PJSIP. We have issues in our backlog to do this and we hope to have the work completed this year. We could use some help though. If you ‘re a member of the Asterisk development community and you’d like to help with the implementation, just let us know! BTW, Has anyone seen implementations of the new algorithms in the wild?
Stay tuned for OpenSIPit#01 Part 2 which addresses STIR/SHAKEN Interoperability and for further developments on RFC8760.
One Response
Is Asterisk supporting sha-256 in digest authentication now? I tried to register an ITSP trunk which challenges with digest/sha-256 but the Aserisk debug says its not supported (Asterisk 16.26.0 w/ PJSIP 2.12). pjsip says it is supporting digest/sha-256 from =>2.12. I used MIcroSIP version 3.21.3 which uses pjsip 2.12 and i’m able to register with my ITSP. I checked in the res_pjsip_outbound_authenticator_digest.c of the git master branch and it seems still its not supported.
Any plan to add this support.