My point was simply that there's more challenge in the bureaucracy than 
technical implementation.

>From a technical standpoint, the corner cases to consider are:

1. Number validity. Sure things that fit into an e.164 and/or recognizable 
number patterns are simple.  What happens when someone sends a From: URI of 
`sip:anonym...@domain.com` - IIRC, the orig_tn field within the identity header 
is supposed to be numeric.  Do you reject the call?  Attest it as "C" and 
provide this in the `orig_tn` field or in a separate field?

2. Handling of forwarded calls - If you're sending a Diversion: header, do you 
also add an Identity header with a `div` passport?  Rewrite the From header?  
How do you determine the attestation in that case?

3. Known customers sending numbers for which you're not the provider?  Strictly 
speaking this should attest as "B", but supposing that you're a secondary 
vendor for the customer, and they're sending their primary number which is with 
a different provider?  Do you then allow them to submit an LOA (or whatever 
your jurisdictional equivalent is) and attest as A?

The questions above are strictly for STI Authentication.  Verification has some 
other idiosyncrasies.   Consider that there's three attestation levels for 
authentication, and normally as a carrier it is not desirable to pass the 
Identity header to the customer (consider if Privacy: is on).  The general 
practice is to assign this to a verstat parameter to the user portion of a PAI 
header's **USER** field, which is syntactically awkward in Kamailio.  Also 
strictly speaking AFAIK, the verstat only has two values - passed or failed - 
so there's three possible attestation levels but they only map to two 
verification levels.  Therea are suggestions on how to deal with this, but I'm 
not sure on their official status.

This brings up the final complexity:  It's a rapidly evolving system without a 
high degree of consistency vendor to vendor, so there's as much of a challenge 
of staying on top of things as anything else.

-----Original Message-----
From: Olle E. Johansson via sr-users <sr-users@lists.kamailio.org> 
Sent: Friday, October 20, 2023 2:08 AM
To: Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
Cc: Olle E. Johansson <o...@edvina.net>
Subject: [SR-Users] Re: STIR/SHAKEN with Kamailio

CAUTION: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.


> On 19 Oct 2023, at 18:46, Alex Balashov via sr-users 
> <sr-users@lists.kamailio.org> wrote:
>
> Would join Kaufman here to say that free-range STIR/SHAKEN 
> implementations in the US are limited by the small number of certified 
> authentication providers, but presumably the EU version will to some 
> extent avoid US-style Guilded Age corporate welfare...
Sadly that's my view of the US implementation. I can't say if it solved the 
problem, but I can see that a lot of new and old actors got an oppurtunity to 
earn more money.

There's no EU-wide implementation or regulation at this point. I am aware of 
France. There are certainly discussions.
/O
>
> -- Alex
>
>> On 19 Oct 2023, at 09:33, Ben Kaufman via sr-users 
>> <sr-users@lists.kamailio.org> wrote:
>>
>> Like some of the other posters here, we've implemented it as a 302-redirect 
>> server. This was the primary reason for using the secsipid rather than 
>> stirshaken module.  Both modules have a function to append an Identity 
>> header, but secsipid also has functions to simply build the identity header 
>> which can then easily be appended to the reply, rather than only appending 
>> to the request and plucking the Identity header from there.  Secsipid also 
>> has a function secsipid_sign() which allows for creating your own JWT.  This 
>> is useful if you want to create some variations on the Identity header - we 
>> use this to create div passports (as opposed to shaken passports) in some 
>> situations.
>>
>> Not sure how it will be implemented there, but the biggest challenge for me 
>> in the US was acquiring certificates because there is a very limited number 
>> of regulatory approved vendors.
>
> --
> Alex Balashov
> Principal Consultant
> Evariste Systems LLC
> Web: 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fevar
> istesys.com%2F&data=05%7C01%7Cbkaufman%40bcmone.com%7C31a9da72c1db4b26
> 7ff308dbd13cd073%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C63833383
> 1362925788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI
> iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=w9TCfesrCll46onz
> GqiIndpnonmKJpi06JrS1s3FJK4%3D&reserved=0
> Tel: +1-706-510-6800
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions To 
> unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send 
an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Reply via email to