[asterisk-dev] STIR/SHAKEN implementation Update

[George Joseph]

Since we've had some known issues with the current STIR/SHAKEN
implementation and since we discovered a few more during the latest
OpenSIPIt get-together, we've decided to do a re-evaluation and refactor.
Some of that refactor you've already seen in the recent addition of libjwt
to the third-party infrastructure in the source tree.  That addition has
already allowed us to eliminate over 1000 lines of custom code in Asterisk
itself.  We have more to do though and need your help with some of it.

Attestation:

Thanks to libjwt, we now have attestation working to the point where we're
using the correct caller-id TN and other open-source stirt/shaken
implementations can  successfully validate our passport signature and
decode the proper passport fields.  Huzzah!  We still have some plumbing
work to do though since the current method of associating TNs and certs is
neither flexible nor efficient.  There are a number of good
possibilities to make this better and we should have some design ideas to
share later this week.

Verification:

The verification process ultimately depends on two pieces of data...the
orig_tn in the passport received in the incoming Identity header, and the
certificate we retrieve from the URL also in the passport.  Right now, we
have verification working right up to the point where we have to verify
them against each other.  It sounds weird but there's a lot of other
verification that has to happen before we get to the point of actually
verifying the TN against the cert (passport signature validation, passport
dates, cert validity dates, cert trust, etc).  Anyway, there are a number
of ways a certificate can indicate it has authority over the TN...

   1. The cert can contain a TNAuthList X.509 extension containing a single
   TN.  No -brainer.  If the TN in the orig_tn passport field doesn't match
   the TN in the cert, it's a fail.
   2. The cert can contain a TNAuthList X.509 extension containing a TN
   range.  Also a no-brainer.  The orig_tn is either in the range or not.
   3. The cert can contain a URL in an "authorityInfoAccess" X.509
   extension.  From RFC8226...  " A verifier would then follow the URI to
   ascertain whether the TNs in the list are authorized for use by the
   caller".   Since the list is supposed to be in the same form as the
   TNAuthList, that should work fine.
   4. The cert can contain a TNAuthList X.509 extension containing a
   Service Provider Code.  Uhm, OK.  What are we supposed to do with that?  I
   can't find any RFC or ATIS document that describes how you match a TN to an
   SPC.  There are some hints that a trusted-well-known service _might_ be
   made available where you could get a list of TNs by SPC, or better yet, a
   service where you can submit a specific TN and get back the SPC, but I can
   find no actual documentation to that effect.  What's worse,
   ATIS-10000080.v005 specifically states that for an end-entity
   certificate... "The TNAuthList shall contain a single SPC value. The SPC
   value shall contain only numbers and uppercase letters. The
   TNAuthList shall *not contain any TNs or TN ranges*. ".  Nice.

OK, here's where we need your help....   Does anyone have any real-world
examples of certificates, TNAuthLists, documents, etc.  that would allow us
to actually implement and test items 3, and especially 4, above?   I can
find absolutely none.

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20231008/d54b2ce7/attachment.html>