Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt

[Chris Wendt <[e-mail]>]

The purpose of this document is two fold, to bring the mechanism we use in 1000074 of reason header with STIR Error code (recall we didn’t want to end/block calls because of STIR errors by sending 4xx errors, we only wanted to notify the authentication service that and error occurred in verification) We also wanted to extend that mechanism for the use-case of multiple identity header errors, which isn’t mentioned in SHAKEN documents, but we needed a fix to the core reason header mechanism to support multiple reason headers with same protocol value in same SIP message.
Whether we explicitly take this back to IPNNI, i’m not sure, we certainly can and probably should for multiple identity header use-cases, but this was meant to be something that addressed something needed from pure STIR perspective, and certainly wouldn’t be a bad thing to reference from SHAKEN specs especially in cases of multiple identity header errors.  It is a bit of a corner case that more than one error occur for same call, but also something that is not impossible, and so the thought was that it is best to have a document to address it.

-Chris

> On Sep 1, 2022, at 10:34 AM, DOLLY, MARTIN C <[e-mail]> wrote:
> 
> Chris,
>  
> Why don’t you just use the language from ATIS-1000074?
>  
> If not, I see this as very difficult to bring into IPNNI.
>  
> I appreciate your consideration.
>  
> Martin
>  
> From: stir <[e-mail]> On Behalf Of Chris Wendt
> Sent: Friday, August 26, 2022 7:35 AM
> To: [e-mail]
> Cc: Christer Holmberg <christer.holmberg=[e-mail]>; Robert Sparks <[e-mail]>; Ben Campbell <[e-mail]>; IETF STIR Mail List <[e-mail]>; STIR Chairs <[e-mail]>
> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>  
> Hi Pierce,
>  
> I think in the context of this specification, we really need to view authentication service as the RFC8224 defined authentication service.  Beyond that is industry and implementation specific.  Recall that ATIS-1000074 has same Reason header requirements, so I would claim that current implementations ignored this if they can’t support this functionality as a split SIP/HTTP based “authentication service” implementation as you are defining it.
>  
> -Chris
> 
> 
> On Aug 25, 2022, at 11:25 AM, [e-mail] <mailto:[e-mail]> wrote:
>  
> The text "in the next provisional or final responses sent to the authentication service" assumes the STI-AS will receive those responses and can do something with them. E.g., include them in a log.
>  
> This is not a good assumption.  Many (most?) AS/VS designs use an outboard server which is called using SIP INVITE or HTTPS and which responds using SIP 302 or HTTPS.  In both of those cases an AS may never see responses from verification services.
>  
> I recommend removing the language “sent to the authentication service” as being unnecessary and potentially misleading.
>  
> Pierce
>  
>  
> From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Christer Holmberg
> Sent: Thursday, August 25, 2022 9:41 AM
> To: Robert Sparks <[e-mail] <mailto:[e-mail]>>; Ben Campbell <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> Cc: Chris Wendt <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>  
> Hi,
>  
> Yes, I meant Reasonse+STIR. It also seems I forgot the background information for my question in my previous e-mail. Sorry for that.
>  
> RFC 3326 says:
>  
>    "Initially, the Reason header field defined here appears to be most
>    useful for BYE and CANCEL requests, but it can appear in any request
>    within a dialog, in any CANCEL request and in any response whose
>    status code explicitly allows the presence of this header field."
>  
> So, my reading it needs to be explicitly indicated for which SIP response status codes Reason can be included.
>  
> For example, RFC 6432, which defines the Reason Q.850 protocol says:
>  
> "This document allows SIP responses to carry Reason header fields as
>    follows:
>  
>       Any SIP Response message, with the exception of a 100 (Trying),
>       MAY contain a Reason header field with a Q.850 [Q.850] cause code."
>  
> Regards,
>  
> Christer
>  
>  
>  
>  
> -----Original Message-----
> From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Robert Sparks
> Sent: torstai 25. elokuuta 2022 17.21
> To: Christer Holmberg <[e-mail] <mailto:[e-mail]>>; Ben Campbell <[e-mail] <mailto:[e-mail]>>; IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> Cc: Chris Wendt <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
> Subject: Re: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
>  
> (Assuming you meant Reason+STIR below, and wearing no hats):
>  
> It isn't clear to me that there's a need to say anything more here than what RFC3326 says. Perhaps the text can be clear that this uses the rules for where the header can occur as RFC3326. I don't think we want something _different_, and I don't want to try to restate those rules in this document.
>  
> RjS
>  
>  
> On 8/25/22 9:05 AM, Christer Holmberg wrote:
> > Hi,
> > 
> > When the STIR protocol is used, in which SIP response codes can the Reason header(s) be included?
> > 
> > I can only find the following statement: "in the next provisional or final responses sent to the authentication service.".
> > 
> > That is not every explicit. If we want to allow Reason+SIP with *any* SIP response code it would be good to say so.
> > 
> > Regards,
> > 
> > Christer
> > 
> > -----Original Message-----
> > From: stir <[e-mail] <mailto:[e-mail]>> On Behalf Of Ben Campbell
> > Sent: maanantai 22. elokuuta 2022 2.50
> > To: IETF STIR Mail List <[e-mail] <mailto:[e-mail]>>
> > Cc: Chris Wendt <[e-mail] <mailto:[e-mail]>>; STIR Chairs <[e-mail] <mailto:[e-mail]>>
> > Subject: [stir] WGLC: draft-ietf-stir-identity-header-errors-handling-03.txt
> > 
> > Hi,
> > 
> > This starts a STIR working group last call for draft-ietf-stir-identity-header-errors-handling-03. Please send feedback tot he authors and the STIR list by September 7. Note that we added a couple of days to the WGLC period due to the US Labor Day holiday.      
> > 
> > As always,any constructive feedback, including feedback to the effect of “I’ve read this and it is ready to go” is helpful.
> > 
> > Thanks!
> > 
> > Ben (For the STIR chairs)
> > 
> > 
> >> On Aug 19, 2022, at 11:10 AM, [e-mail] <mailto:[e-mail]> wrote:
> >> 
> >> 
> >> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> >> This draft is a work item of the Secure Telephone Identity Revisited WG of the IETF.
> >> 
> >>         Title           : Identity Header Errors Handling
> >>         Author          : Chris Wendt
> >>   Filename        : draft-ietf-stir-identity-header-errors-handling-03.txt
> >>   Pages           : 7
> >>   Date            : 2022-08-19
> >> 
> >> Abstract:
> >>    This document extends STIR and the Authenticated Identity Management
> >>    in the Session Initiation Protocol (SIP) error handling procedures to
> >>    include the mapping of verification failure reasons to STIR defined
> >>    4xx codes so the failure reason of an Identity header field can be
> >>    conveyed to the upstream authentication service when local policy
> >>    dictates that the call should continue in the presence of a
> >>    verification failure.  This document also defines procedures that
> >>    enable enable a failure reason to be mapped to a specific Identity
> >>    header for scenarios that use multiple Identity header fields where
> >>    some may have errors and others may not and the handling of those
> >>    situations is defined.
> >> 
> >> 
> >> The IETF datatracker status page for this draft is:
> >> https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4hCieo9Q$>
> >> 
> >> There is also an htmlized version available at:
> >> https://datatracker.ietf.org/doc/html/draft-ietf-stir-identity-header-errors-handling-03 <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-stir-identity-header-errors-handling-03__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4xuA3QC4$>
> >> 
> >> A diff from the previous version is available at:
> >> https://www.ietf.org/rfcdiff?url2=draft-ietf-stir-identity-header-errors-handling-03 <https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-stir-identity-header-errors-handling-03__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4ABsgGbs$>
> >> 
> >> 
> >> Internet-Drafts are also available by rsync at rsync.ietf.org <https://urldefense.com/v3/__http:/rsync.ietf.org__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4X7NdPdU$>::internet-drafts
> >> 
> >> 
> >> _______________________________________________
> >> stir mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/stir <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4VuX0JZI$>
> > _______________________________________________
> > stir mailing list
> > [e-mail] <mailto:[e-mail]>
> > https://www.ietf.org/mailman/listinfo/stir <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4VuX0JZI$>
>  
> _______________________________________________
> stir mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/stir__;!!BhdT!j6ANu4WmhoYTjBJDWq-Ps2FI2j18o1npm8uLG-xb0-IjI8TdDuVvLCDoI25j3pfSz-jelNiAJKGvyQy4VuX0JZI$>