[SR-Users] Re: STIR/SHAKEN with Kamailio
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-174 > 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 >> Sent: Friday, October 20, 2023 2:08 AM >> To: Kamailio (SER) - Users Mailing List >> Cc: Olle E. Johansson >> 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,
[SR-Users] Re: STIR/SHAKEN with Kamailio
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-174 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 > Sent: Friday, October 20, 2023 2:08 AM > To: Kamailio (SER) - Users Mailing List > Cc: Olle E. Johansson > 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
[SR-Users] Re: STIR/SHAKEN with Kamailio
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 Sent: Friday, October 20, 2023 2:08 AM To: Kamailio (SER) - Users Mailing List Cc: Olle E. Johansson 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 > 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 >> 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=05%7C01%7Cbkaufman%40bcmone.com%7C31a9da72c1db4b26 > 7ff308dbd13cd073%7Cafc1818e7b6848568913201b9396c4fc%7C1%7C0%7C63833383 > 1362925788%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzI > iLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=w9TCfesrCll46onz > GqiIndpnonmKJpi06JrS1s3FJK4%3D=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 l
[SR-Users] Re: STIR/SHAKEN with Kamailio
> On 19 Oct 2023, at 18:46, Alex Balashov via sr-users > 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 >> 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://evaristesys.com > 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:
[SR-Users] Re: STIR/SHAKEN with Kamailio
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... -- Alex > On 19 Oct 2023, at 09:33, Ben Kaufman via sr-users > 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://evaristesys.com 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:
[SR-Users] Re: STIR/SHAKEN with Kamailio
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. Regards, Kaufman -Original Message- From: Olle E. Johansson via sr-users Sent: Wednesday, October 18, 2023 2:24 AM To: Leonardo Arena via sr-users Cc: Olle E. Johansson Subject: [SR-Users] 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. Hello Kamailians! As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, I’m curious on how you’ve implemented it with Kamailio. I asked on our Matrix chat and got two responses that seems to not use the Kamailio STIR/SHAKEN support but rather a 3rd party service that they’ve integrated using restful APIs. Please help me and share how you’re implementing STIR/SHAKEN with Kamailio. I’m not shaken, nor stirred. yet. Regards, /O __ 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:
[SR-Users] Re: STIR/SHAKEN with Kamailio
Hello, I use Kamailio + secsipid module to implement France MAN programm which is a slightly different from US STIR/SHAKEN framework but aims the same goal. And yes, have it as a 3rd party service accessible via HTTP requests is another doable option. On Wed 18 Oct 2023 at 10:49, Yuriy G via sr-users < sr-users@lists.kamailio.org> wrote: > I will add some clarifications and the purpose of the approach: > I've been using a 3d-party service ( written in-house ) via restful API as > there were no STIR/SHAKEN modules for the Kamailio at that moment. > So in short: it was a matter of time to integrate functionality. > > > ср, 18 окт. 2023 г. в 10:03, Olle E. Johansson via sr-users < > sr-users@lists.kamailio.org>: > >> Hello Kamailians! >> >> As STIR/SHAKEN seems to cross the ocean and arrive on the European >> shores, I’m curious on how you’ve implemented it with Kamailio. I asked on >> our Matrix chat and got two responses that seems to not use the Kamailio >> STIR/SHAKEN support but rather a 3rd party service that they’ve integrated >> using restful APIs. >> >> Please help me and share how you’re implementing STIR/SHAKEN with >> Kamailio. >> >> I’m not shaken, nor stirred. yet. >> >> Regards, >> /O >> __ >> 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: > -- Sent from Gmail Mobile __ 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:
[SR-Users] Re: STIR/SHAKEN with Kamailio
I will add some clarifications and the purpose of the approach: I've been using a 3d-party service ( written in-house ) via restful API as there were no STIR/SHAKEN modules for the Kamailio at that moment. So in short: it was a matter of time to integrate functionality. ср, 18 окт. 2023 г. в 10:03, Olle E. Johansson via sr-users < sr-users@lists.kamailio.org>: > Hello Kamailians! > > As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, > I’m curious on how you’ve implemented it with Kamailio. I asked on our > Matrix chat and got two responses that seems to not use the Kamailio > STIR/SHAKEN support but rather a 3rd party service that they’ve integrated > using restful APIs. > > Please help me and share how you’re implementing STIR/SHAKEN with Kamailio. > > I’m not shaken, nor stirred. yet. > > Regards, > /O > __ > 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:
[SR-Users] Re: STIR/SHAKEN with Kamailio
I implemented it with Kamailio. I forward all invites to a Kamailio instance that does the stir/shaken stuff and returns it in a 302 which is then added to the INVITE to continue normally. OpenSIPS has a nice how-to and examples on how to do it. Hope that helps David On Wed, 18 Oct 2023 at 10:03, Olle E. Johansson via sr-users < sr-users@lists.kamailio.org> wrote: > Hello Kamailians! > > As STIR/SHAKEN seems to cross the ocean and arrive on the European shores, > I’m curious on how you’ve implemented it with Kamailio. I asked on our > Matrix chat and got two responses that seems to not use the Kamailio > STIR/SHAKEN support but rather a 3rd party service that they’ve integrated > using restful APIs. > > Please help me and share how you’re implementing STIR/SHAKEN with Kamailio. > > I’m not shaken, nor stirred. yet. > > Regards, > /O > __ > 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:
