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(a)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:anonymous@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(a)lists.kamailio.org>
Sent: Friday, October 20, 2023 2:08 AM
To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>
Cc: Olle E. Johansson <oej(a)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(a)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(a)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-leave(a)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-leave(a)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-leave(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to
the sender!
Edit mailing list options or unsubscribe: