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

["DOLLY, MARTIN C" <[e-mail]>]

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$>