Re: [VoiceOps] question about stir/shaken - iat and DATE header
For Ribbon SBCs you have to enable header transparency for the Date header on both ingress and egress. From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew Yaklin Sent: Friday, July 02, 2021 11:55 AM To: j...@communichanic.com; voiceops@voiceops.org Subject: Re: [VoiceOps] question about stir/shaken - iat and DATE header Just to wrap this up and to thank those who responded... IQNT's sonus (ribbon) do not support the DATE header. Ribbon plans to fix it soon. It is being stripped out. Meta already loaded an efix for us. I think I typed out the issue wrong. On verification the IAT has the time. The INVITE did not have the DATE. Meta's perimeta json schema choked due to that. They will now use the SBC's date/time to do a comparison if the DATE is not there. Probably check to see if it is within a certain time frame. After all the DATE and iat may not match when the INVITE comes in when everything is there to process. This should solve the problem and allow us to keep moving along with this. Matt From: VoiceOps On Behalf Of John S. Robinson Sent: Thursday, July 1, 2021 3:31 PM To: voiceops@voiceops.org Subject: Re: [VoiceOps] question about stir/shaken - iat and DATE header Date header has been part of RFC-3261 SIP<https://datatracker.ietf.org/doc/html/rfc3261.html> for 19 years now, but was not used all that much.IAT and Date are both part of the specs and more recent RFC's that define stir-shaken. So the seldom-used but long time defined Date: header is now required.Furthermore, IAT is part of the formal JSON in the Identity header and must be present, or the claims are not valid. Normally, IAT would restate the Date with Unix Epoch date. IAT is signed, but the Date header is not signed. When a call is received and Verified, the the plain-text signed JSON is validated. If verified IAT is stale, the call is rejected. True, someone could mess with Date header along the route or SIP From header or PAI. And for that matter, someone could mess with the JSON attributes that are signed. But then the verification would fail, and the call should not be delivered. That's part of the beauty of the system. Best regards, John On 7/1/2021 12:29, Joseph Jackson wrote: I've heard that TNSi also counts on the date header being present. So far we don't see a lot of people passing tokens with the date header. From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew Yaklin Sent: Thursday, July 01, 2021 12:25 PM To: voiceops@voiceops.org<mailto:voiceops@voiceops.org> Subject: [VoiceOps] question about stir/shaken - iat and DATE header All, Pretty simple question here. When you do a verify request are you filling in the iat with your sbc's current date/time or using the DATE information from the invite? With Neustar the iat is currently optional. IQNT is basically removing the DATE header in a test we are doing by sending them a call and getting it back in a different region. It really does not make sense to me to use the DATE header because it could be messed with by anyone in the path. It is untrusted. The iat is trusted so when you verify it makes more sense to use the current date/time of your SBC because the limitation is 60 seconds from AS to VS. I imagine Neustar made it optional because their own system has some intelligence when it comes to this expiration of the AS. On top of that Metaswitch is not prepared for this situation. They are basically counting on that DATE header to be there in their recommended perimeta SBC config. They plan to fix it by using the current date/time. Just looking for how others are handling this. Just leaving it blank for now? Matt ___ VoiceOps mailing list VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] question about stir/shaken - iat and DATE header
Just to wrap this up and to thank those who responded... IQNT's sonus (ribbon) do not support the DATE header. Ribbon plans to fix it soon. It is being stripped out. Meta already loaded an efix for us. I think I typed out the issue wrong. On verification the IAT has the time. The INVITE did not have the DATE. Meta's perimeta json schema choked due to that. They will now use the SBC's date/time to do a comparison if the DATE is not there. Probably check to see if it is within a certain time frame. After all the DATE and iat may not match when the INVITE comes in when everything is there to process. This should solve the problem and allow us to keep moving along with this. Matt From: VoiceOps On Behalf Of John S. Robinson Sent: Thursday, July 1, 2021 3:31 PM To: voiceops@voiceops.org Subject: Re: [VoiceOps] question about stir/shaken - iat and DATE header Date header has been part of RFC-3261 SIP<https://datatracker.ietf.org/doc/html/rfc3261.html> for 19 years now, but was not used all that much.IAT and Date are both part of the specs and more recent RFC's that define stir-shaken. So the seldom-used but long time defined Date: header is now required.Furthermore, IAT is part of the formal JSON in the Identity header and must be present, or the claims are not valid. Normally, IAT would restate the Date with Unix Epoch date. IAT is signed, but the Date header is not signed. When a call is received and Verified, the the plain-text signed JSON is validated. If verified IAT is stale, the call is rejected. True, someone could mess with Date header along the route or SIP From header or PAI. And for that matter, someone could mess with the JSON attributes that are signed. But then the verification would fail, and the call should not be delivered. That's part of the beauty of the system. Best regards, John On 7/1/2021 12:29, Joseph Jackson wrote: I've heard that TNSi also counts on the date header being present. So far we don't see a lot of people passing tokens with the date header. From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew Yaklin Sent: Thursday, July 01, 2021 12:25 PM To: voiceops@voiceops.org<mailto:voiceops@voiceops.org> Subject: [VoiceOps] question about stir/shaken - iat and DATE header All, Pretty simple question here. When you do a verify request are you filling in the iat with your sbc's current date/time or using the DATE information from the invite? With Neustar the iat is currently optional. IQNT is basically removing the DATE header in a test we are doing by sending them a call and getting it back in a different region. It really does not make sense to me to use the DATE header because it could be messed with by anyone in the path. It is untrusted. The iat is trusted so when you verify it makes more sense to use the current date/time of your SBC because the limitation is 60 seconds from AS to VS. I imagine Neustar made it optional because their own system has some intelligence when it comes to this expiration of the AS. On top of that Metaswitch is not prepared for this situation. They are basically counting on that DATE header to be there in their recommended perimeta SBC config. They plan to fix it by using the current date/time. Just looking for how others are handling this. Just leaving it blank for now? Matt ___ VoiceOps mailing list VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] question about stir/shaken - iat and DATE header
Date header has been part of RFC-3261 SIP <https://datatracker.ietf.org/doc/html/rfc3261.html> for 19 years now, but was not used all that much. IAT and Date are both part of the specs and more recent RFC's that define stir-shaken. So the seldom-used but long time defined Date: header is now required. Furthermore, IAT is part of the formal JSON in the Identity header and must be present, or the claims are not valid. Normally, IAT would restate the Date with Unix Epoch date. IAT is signed, but the Date header is not signed. When a call is received and Verified, the the plain-text signed JSON is validated. If verified IAT is stale, the call is rejected. True, someone could mess with Date header along the route or SIP From header or PAI. And for that matter, someone could mess with the JSON attributes that are signed. But then the verification would fail, and the call should not be delivered. That's part of the beauty of the system. Best regards, John On 7/1/2021 12:29, Joseph Jackson wrote: I’ve heard that TNSi also counts on the date header being present. So far we don’t see a lot of people passing tokens with the date header. *From:*VoiceOps [mailto:voiceops-boun...@voiceops.org] *On Behalf Of *Matthew Yaklin *Sent:* Thursday, July 01, 2021 12:25 PM *To:* voiceops@voiceops.org *Subject:* [VoiceOps] question about stir/shaken - iat and DATE header All, Pretty simple question here. When you do a verify request are you filling in the iat with your sbc’s current date/time or using the DATE information from the invite? With Neustar the iat is currently optional. IQNT is basically removing the DATE header in a test we are doing by sending them a call and getting it back in a different region. It really does not make sense to me to use the DATE header because it could be messed with by anyone in the path. It is untrusted. The iat is trusted so when you verify it makes more sense to use the current date/time of your SBC because the limitation is 60 seconds from AS to VS. I imagine Neustar made it optional because their own system has some intelligence when it comes to this expiration of the AS. On top of that Metaswitch is not prepared for this situation. They are basically counting on that DATE header to be there in their recommended perimeta SBC config. They plan to fix it by using the current date/time. Just looking for how others are handling this. Just leaving it blank for now? Matt ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Re: [VoiceOps] question about stir/shaken - iat and DATE header
I've heard that TNSi also counts on the date header being present. So far we don't see a lot of people passing tokens with the date header. From: VoiceOps [mailto:voiceops-boun...@voiceops.org] On Behalf Of Matthew Yaklin Sent: Thursday, July 01, 2021 12:25 PM To: voiceops@voiceops.org Subject: [VoiceOps] question about stir/shaken - iat and DATE header All, Pretty simple question here. When you do a verify request are you filling in the iat with your sbc's current date/time or using the DATE information from the invite? With Neustar the iat is currently optional. IQNT is basically removing the DATE header in a test we are doing by sending them a call and getting it back in a different region. It really does not make sense to me to use the DATE header because it could be messed with by anyone in the path. It is untrusted. The iat is trusted so when you verify it makes more sense to use the current date/time of your SBC because the limitation is 60 seconds from AS to VS. I imagine Neustar made it optional because their own system has some intelligence when it comes to this expiration of the AS. On top of that Metaswitch is not prepared for this situation. They are basically counting on that DATE header to be there in their recommended perimeta SBC config. They plan to fix it by using the current date/time. Just looking for how others are handling this. Just leaving it blank for now? Matt ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
[VoiceOps] question about stir/shaken - iat and DATE header
All, Pretty simple question here. When you do a verify request are you filling in the iat with your sbc's current date/time or using the DATE information from the invite? With Neustar the iat is currently optional. IQNT is basically removing the DATE header in a test we are doing by sending them a call and getting it back in a different region. It really does not make sense to me to use the DATE header because it could be messed with by anyone in the path. It is untrusted. The iat is trusted so when you verify it makes more sense to use the current date/time of your SBC because the limitation is 60 seconds from AS to VS. I imagine Neustar made it optional because their own system has some intelligence when it comes to this expiration of the AS. On top of that Metaswitch is not prepared for this situation. They are basically counting on that DATE header to be there in their recommended perimeta SBC config. They plan to fix it by using the current date/time. Just looking for how others are handling this. Just leaving it blank for now? Matt ___ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
