Re: [stir] I-D Action: draft-ietf-stir-rfc4474bis-00.txt

[Paul Kyzivat <[e-mail]>]

On 6/25/14 11:02 AM, Peterson, Jon wrote:
>
> Yeah, this stuff is not straightforward.
>
> When we wrote RFC4474, we didn't think it was our business to specify the user interface when dubious events arose - we assumed our responsibilities ended with providing a set of tools in the signaling that could trigger UI as implementers and users thought appropriate. If you receive a SIP request that was To someone else and somehow forwarded to you, I do think that is potentially important information to render to the user, actually. I can imagine deciding whether or not to answer a call based on that information. I can even imagine that being useful without Identity. In a scoring system for identity, I can imagine that lowering confidence. But again, at least in how we originally saw our mandate, prescribing a UI was not in scope.

I understand that. And yet, STIR is intended to be a very pragmatic 
exercise. If many/most plausible deployments won't be able to give 
special treatment to unexpected To-URIs then it makes little sense to 
define a mechanism that requires doing so.

OTOH, if we really intend that UIs will be expected to do something, 
then we ought to come up some suggestions about how. Perhaps this is the 
wrong document for it, but then we should look for another document that 
is the right place.

> And we need to be careful to distinguish response identity (which to me means signing SIP response messages) and various forms of connected identity. Response identity is definitely out of scope -

I thought you had concluded that response identity was impossible.

> as I think is any mechanism intended to notify the caller of what number was reached, though Elwell-style workarounds could be implemented on top of these systems. But certainly the scope of RFC4474 did include protecting against a forged BYE request sent to tear down a dialog. That is why there are protections for requests sent in the backwards direction. Now this here is legacy RFC4474 text, and the number 4474 is less than 4916, so there may very well be fixes we need to get the language about From and To right.

Perhaps we also need a 4916bis, or expand this document to encompass both.

> Be happy to work with you on that.

Sure. My first suggestion is to split this section into two - separating 
out the response/connected identity.

> I will clarify that you do look at a leading + as an indicator to ascertain whether or not the numbers in a user-portion are a likely telephone number.

ok. And henning has had more to say on this.

	Thanks,
	Paul

> Thanks!
>
> Jon Peterson
> Neustar, Inc.
>
> Sent from my iPad
>
>> On Jun 24, 2014, at 6:14 PM, "Paul Kyzivat" <[e-mail]> wrote:
>>
>>> On 6/20/14 12:29 PM, Peterson, Jon wrote:
>>>
>>> Hi Paul,
>>>
>>>>
>>>> I find this section incomprehensible. What is it trying to tell me?
>>>>
>>>> It starts out saying:
>>>>
>>>>     The recipient of a request must compare
>>>>     that value to their own identity in order to determine whether or not
>>>>     the identity information in this call might have been replayed.
>>>>
>>>> Must it? This doesn't seem to be normative, and I didn't find anything
>>>> else saying this.
>>>
>>>
>>> This is actually making a very simple, almost trite statement: if you
>>> receive a request, you should inspect it to make sure it is to
>>> "[e-mail]" and not to "[e-mail]," because someone could
>>> just capture a request to Derek and replay it to you in order to
>>> impersonate the sender of that message. It's telling you to pay attention
>>> to the To, but, due to retargeting of various kinds, this gets
>>> complicated. This section exists to explain that complication.
>>
>> OK. That wasn't clear to me. But from a practical perspective, what are you suggesting be done? Does this imply that the UAS should display the To-URI together with the callerid? Or that the callerid should be displayed with an indication of lower confidence in this case? Or that the UAS should alert differently when the To-URI is "wrong" than it does when it is "right"?
>>
>> I see no good answers that don't increase the complexity of the user experience.
>>
>> I'd like to see more about this.
>>
>>>> The point seems to be that response identity is hard and is not covered
>>>> by this draft. If so, then the section title should be changed, and the
>>>> section should explicitly state that is what it is trying to say.
>>>
>>> This draft is not trying to address response identity in any way.
>>
>> I thought it was at least touching on that because of:
>>
>>    Moreover, the value in the To header field of a dialog-forming
>>    request is used as the From header field of requests sent in the
>>    backwards direction during the dialog, and is accordingly the header
>>    that would be signed by an authentication service for requests sent
>>    in the backwards direction.  But in retargeting cases, if the URI in
>>    the From header does not identify the sender of the request in the
>>    backwards direction, then clearly it would be inappropriate to
>>    provide an Identity signature over that From header.  As specified
>>    above, if the authentication service is not responsible for the
>>    domain in the From header field of the request, it MUST NOT add an
>>    Identity header to the request, and it should process/forward the
>>    request normally.
>>
>> And IIUC that statement is actually *wrong*. The retargeted user could never get a request in the reverse direction signed with that From URI. RFC 4916 tackled that, and results in switching to, and signing, the proper URI for the called UA.
>>
>> And the rest of the section also seems to be about connected/response identity and is unrelated to the subject of the section. I'm not sure it needs to be anywhere in this draft, but if so, then in a different section.
>>
>>> The major changes that were made in this draft are largely to Section 6.1:
>>> this has some new text that we're going to need to talk about I'm sure.
>>>
>>>>
>>>> Section 6.1:
>>>>
>>>>     To address this problem, the authentication service and verification
>>>>     service both must perform the following canonicalization procedure on
>>>>     any SIP URI they inspect which contains a wholly numeric user part.
>>>>     Note that the same procedures are followed for creating the canonical
>>>>     form of URIs found in both the From and To header field values.
>>>>
>>>> Based on the other text, I don't think the above really means "wholly
>>>> numeric". It at least seems to include a leading "+". Perhaps the
>>>> following better states what is intended:
>>>
>>> No, the intention is that you strip the '+' for canonicalization.
>>> "Implementations MUST drop any leading +'s" is two paragraphs down.
>>
>> Yes, I understand that. My point was about how you determine if the original URI is a candidate for canonicalization as a telephone number. You say to inspect any URI which contains a wholly numeric user part. But certainly incoming URIs starting with "+" (which are *not* wholly numeric) also must be considered. Probably anything that matches a tel global-number should be, as well as anything that is wholly numeric.
>>
>>     Thanks,
>>     Paul
>>
>>>>     To address this problem, the authentication service and verification
>>>>     service both must perform the following canonicalization procedure on
>>>>     any SIP URI to which it applies.
>>>>     Note that the same procedures are followed for creating the canonical
>>>>     form of URIs found in both the From and To header field values.
>>>>
>>>> Later in this section:
>>>>
>>>>     The ABNF of this number string is:
>>>>
>>>>           tn-spec = *DIGIT
>>>>
>>>> I suspect you probably really want
>>>>
>>>>           tn-spec = 1*DIGIT
>>>
>>>
>>> Oh, well, yes, that's true.
>>>
>>>> Section 7:
>>>>
>>>>     digest-string = addr-spec / tn-spec "|" addr-spec / tn-spec "|"
>>>>            Method "|" SIP-date "|" [ signed-identity-reliance-digest ]
>>>>
>>>> The above has some precedence issues, and needs some parentheses:
>>>>
>>>>     digest-string = (addr-spec / tn-spec) "|" (addr-spec / tn-spec) "|"
>>>>            Method "|" SIP-date "|" [ signed-identity-reliance-digest ]
>>>>
>>>> Or perhaps this would be clearer:
>>>>
>>>>     source-identity = addr-spec / tn-spec
>>>>     target-identity = addr-spec / tn-spec
>>>>     digest-string = source-identity "|" target-identity "|"
>>>>            Method "|" SIP-date "|" [ signed-identity-reliance-digest ]
>>>
>>>
>>> Sure, that is clearer. This was legacy text imported from RFC4474, but we
>>> should fix it here.
>>>
>>> Thanks!
>>>
>>> Jon Peterson
>>> Neustar, Inc.
>>>
>>>> That's it.
>>>>
>>>>     Thanks,
>>>>     Paul
>>>>
>>>> _______________________________________________
>>>> stir mailing list
>>>> [e-mail]
>>>> https://urldefense.proofpoint.com/v1/url?u=https://www.ietf.org/mailman/li
>>>> stinfo/stir&k=lQ50IrZ4n2wmPbDBDzKBYw%3D%3D%0A&r=8DMZR2OPVO0EflFSzDaVn8Q%2B
>>>> 31F1WQyjSQmLQXwHuHE%3D%0A&m=ChG48g2XuFFNBy%2F18bJyzEhIHdICB3IHnrFZJTtotCE%
>>>> 3D%0A&s=d0ac8746ea772795a2d7d1b8f83e221e6d3c45d69a6d7f096521e495983ad112
>>
>