Agreed On Sun, 22 Oct 2023 at 23:22, Oleg Belousov via sr-users < sr-users@lists.kamailio.org> wrote:
> Hi, Ben. > Inline is how we implemented mentioned points in our project, If that will > be helpful. > Not sure if SS helps much to prevent spoofed calls, but there could be > other bonuses like rcd/branded calling which sounds like a promising cnam > extension. > -- > obelousov.tel > > > On Fri, 20 Oct 2023 at 16:25, Ben Kaufman via sr-users < > sr-users@lists.kamailio.org> wrote: > >> 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? >> > [Oleg] We are using P-Asserted-Identity instead of From, it keeps the > number even if CLIR is enabled. As per ATIS-1000074 > The ‘orig’ claim ‘tn’ value shall be derived using the following rules: > - The P-Asserted-Identity header field value shall be used as the > telephone identity, if present, otherwise the From header field value shall > be used. > - If there are two P-Asserted-Identity header field values, the > authentication service shall have logic to choose the most appropriate one > based on local service provider policy. > - The action taken when neither the P-Asserted-Identity header field value > nor the From header contain tel URI identities is outside the scope of the > SHAKEN framework. > >> >> 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? >> > [Oleg] For the forwarded calls (with enabled diversion) we are checking > if Identity is present. If yes - send call as it is, otherwise assign > attestation C, > >> >> 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? >> > [Oleg] If A-number does nor belong to operator - we assign attestation B > >> >> 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: >> > __________________________________________________________ > 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:
