<div dir="ltr">I have no idea how this email will render in the old asterisk-dev<div>list but here goes.<div>If you can't read it, and you're not already subscribed to the</div><div>new list, this is your reminder to do so... <a href="https://groups.io/g/asterisk-dev">https://groups.io/g/asterisk-dev</a><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">George Joseph via <a href="http://groups.io">groups.io</a></strong> <span dir="auto"><gjoseph=<a href="mailto:sangoma.com@groups.io">sangoma.com@groups.io</a>></span><br>Date: Tue, Jan 9, 2024 at 1:11 PM<br>Subject: [asterisk-dev] Stir/Shaken Refactor<br>To: <<a href="mailto:asterisk-dev@groups.io">asterisk-dev@groups.io</a>><br></div><br><br><h2>Please review the pull request at <a href="https://github.com/asterisk/asterisk/pull/524" target="_blank">Stir/Shaken Refactor</a></h2>
<p>You can review this PR locally by running <code>gh pr checkout 524</code> if you have the GitHub CLI client installed
or by running <code>git fetch upstream pull/524/head:master-stir-shaken-refactor</code> (assuming "upstream"
points to <a href="https://github.com/asterisk/asterisk.git)" target="_blank">https://github.com/asterisk/asterisk.git)</a>.</p>
<h2>It's important that you understand that there are breaking changes to the Stir/Shaken implementation and that you TEST!!</h2>
<p>I'll be updating the documentation at <a href="https://docs.asterisk.org/Deployment/STIR-SHAKEN" target="_blank">https://docs.asterisk.org/Deployment/STIR-SHAKEN</a> over the next few days.</p>
<h2>Why do we need a refactor?</h2>
<p>The original stir/shaken implementation was started over 3 years ago
when little was understood about practical implementation. The
result was an implementation that wouldn't actually interoperate
with any other stir-shaken implementations.</p>
<p>There were also a number of stir-shaken features and RFC
requirements that were never implemented such as TNAuthList
certificate validation, sending Reason headers in SIP responses
when verification failed but we wished to continue the call, and
the ability to send Media Key(mky) grants in the Identity header
when the call involved DTLS.</p>
<p>Finally, there were some performance concerns around outgoing
calls and selection of the correct certificate and private key.
The configuration was keyed by an arbitrary name which meant that
for every outgoing call, we had to scan the entire list of
configured TNs to find the correct cert to use. With only a few
TNs configured, this wasn't an issue but if you have a thousand,
it could be.</p>
<p>What's changed?</p>
<ul>
<li><p>Configuration objects have been refactored to be clearer about
their uses and to fix issues.</p>
<ul>
<li>The "general" object was renamed to "verification" since it
contains parameters specific to the incoming verification
process. It also never handled ca_path and crl_path
correctly.</li>
<li>A new "attestation" object was added that controls the
outgoing attestation process. It sets default certificates,
keys, etc.</li>
<li>The "certificate" object was renamed to "tn" and had it's key
change to telephone number since outgoing call attestation
needs to look up certificates by telephone number.</li>
<li>The "profile" object had more parameters added to it that can
override default parameters specified in the "attestation"
and "verification" objects.</li>
<li>The "store" object was removed altogether as it was never
implemented.</li>
</ul></li>
<li><p>We now use libjwt to create outgoing Identity headers and to
parse and validate signatures on incoming Identity headers. Our
previous custom implementation was much of the source of the
interoperability issues.</p></li>
<li><p>General code cleanup and refactor.</p>
<ul>
<li>Moved things to better places.</li>
<li>Separated some of the complex functions to smaller ones.</li>
<li>Using context objects rather than passing tons of parameters
in function calls.</li>
<li>Removed some complexity and unneeded encapsulation from the
config objects.</li>
</ul></li>
</ul>
<p>Resolves: #351<br>
Resolves: #46</p>
<p>UserNote: Asterisk's stir-shaken feature has been refactored to
correct interoperability, RFC compliance, and performance issues.
See <a href="https://docs.asterisk.org/Deployment/STIR-SHAKEN" target="_blank">https://docs.asterisk.org/Deployment/STIR-SHAKEN</a> for more
information.</p>
<p>UpgradeNote: The stir-shaken refactor is a breaking change but since
it's not working now we don't think it matters. The
stir_shaken.conf file has changed significantly which means that
existing ones WILL need to be changed. The stir_shaken.conf.sample
file in configs/samples/ has quite a bit more information. This is
also an ABI breaking change since some of the existing objects
needed to be changed or removed, and new ones added.</p>
<div width="1" style="color:white;clear:both">_._,_._,_</div>
<hr>
Groups.io Links:<p>
You receive all messages sent to this group.
</p><p>
<a href="https://groups.io/g/asterisk-dev/message/12" target="_blank">View/Reply Online (#12)</a> |
<a href="mailto:asterisk-dev@groups.io?subject=Re:%20%5Basterisk-dev%5D%20Stir%2FShaken%20Refactor" target="_blank">Reply To Group</a>
| <a href="mailto:gjoseph@sangoma.com?subject=Private:%20Re:%20%5Basterisk-dev%5D%20Stir%2FShaken%20Refactor" target="_blank">Reply To Sender</a>
|
<a href="https://groups.io/mt/103627606/8107472" target="_blank">Mute This Topic</a>
| <a href="https://groups.io/g/asterisk-dev/post" target="_blank">New Topic</a>
<br>
<a href="https://groups.io/g/asterisk-dev/editsub/8107472" target="_blank">Your Subscription</a> |
<a href="mailto:asterisk-dev+owner@groups.io" target="_blank">Contact Group Owner</a> |
<a href="https://groups.io/g/asterisk-dev/leave/12915652/8107472/342978022/xyzzy" target="_blank">Unsubscribe</a>
[<a href="mailto:gjoseph@sangoma.com" target="_blank">gjoseph@sangoma.com</a>]<br>
</p><div width="1" style="color:white;clear:both">_._,_._,_</div>
<p></p><p></p></div></div></div></div>