Re: [stir] [EXTERNAL] Re: PASSPorT: "orig" and "dest" mandatory in all PASSPorTs?

["Peterson, Jon" <[e-mail]>]

On 2/4/18, 7:27 AM, "Christer Holmberg" <[e-mail]>
wrote:

>Even if you hand the verification service a single Identity header
>fields, which contains embedded claims from N Identity header fields, the
>verification service still have to figure out what goes with what,
>doesn't it?

The point of nesting is to order the stack, and correlate retargets with
previous targets. So I hope that it is explicit about what goes with what.

>
>>- but there are a few potential pitfalls there we need to avoid, or at
>>least carefully mark.
>
>Assume the following:

Yeah this the sort of thing I meant by pitfalls.

> 
>1 . The "original" (pre-3xx) INVITE traverses proxies P1 and P2. Each of
>those proxies insert a claim.

.. in separate Identity headers, I assume.

>2.  The INVITE then reaches P3, which decides to send a 3xx response. It
>includes a nested PASSporT, with the claims from P1 and P2 (and possibly
>P3) in the responses.

... in this case the redirecting service would need to have a way to send
two nested PASSporTs in the backwards direction (one for the P1 PASSporT
and one for the P2 PASSporT); we do need a way to do that.

>3.  The 3xx reaches the UA, which sends a "new" INVITE, which contains
>the nested PASSporT provided in the 3xx.

... in general, cases where the 3xx actually reaches the UA don't worry me
as much as ones where a helpful intermediary intervenes. If the 3xx
reaches the UA, the UA can just send a new INVITE which will go back
through P1 and P2 (or maybe as you have it below some other AS) and they
can merrily add fresh Identity headers to it reflecting the new target.
The reason why I'm not super concerned about this case is because the STIR
scope is limited to trying to convey the identity of the originator to
prevent spoofing, not to record service logic like History-Info does. If
the UAC gets the chance to send a new INVITE, it will get a new Identity
signature quite routinely.

>4.  The new INVITE reaches P3 and P4, and eventually a verifier. The
>Identity header will contain the claims of P1 and P2. Is that the
>intention? Is the verifier supposed to verify those? What if the
>verification fails? Should the verifier reject the request, even if P1
>and P2 are no longer associated with the call?

Ordinarily there would be no reason for a new INVITE - one resulting from
a 3xx that had reached the UAC - to carry the claims of P1 and P2.

>If this will be clarified in the next version, I can wait for the answer
>:)

The above is basically what I have in mind, anyway, for the revision. To
try to keep this simple, focused on the impersonation attack, rather than
trying to sign service logic decisions. The new redirection text is
basically to handle the case where the INVITE does not reach the UA, where
some intermediary explores a new target, that those nested PASSporTs are
relevant here.

If that scope seems insufficient or misguided, let's talk about it more.

>In addition, P3 and P4 may add their own claims, in separate Identity
>header fields, so there would be one Identity header field with the
>nested claim (received in the 3xx response), followed by the Identity
>header fields added by P3 and P4. Perhaps that is not a problem, but I
>just hope we don't make assumptions regarding the number and combinations
>of Identity header fields...

In general, I don't know why changing the target should result in
different authentication services wanting to add PASSporTs to a call, and
I'm kind of afraid to hear the rationale for it. I mean, I can construe a
reason for some corner cases, but in ordinary operations, we hope the
administrative domain of the originator of the call will be able to sign
PASSporTs for it, and that it won't be so destination-dependent.

Jon Peterson
Neustar, Inc.

>
>Regards,
>
>Christer
>
>
>
>On 1/26/18, 9:27 AM, "stir on behalf of Julio Martinez-Minguito"
><[e-mail] on behalf of [e-mail]>
>wrote:
>
>>Hi,
>>
>>I see in the nested divert that the new PASSporT has a claim "opt"
>>which includes the PASSporT of the originating network, including the
>>signature.
>>The PASSporT added by the diverting network includes a claim "orig",
>>which is copied from the 'original' PASSporT.
>>In this case , for a PASSporT ppt:div, the diverting network mays not
>>have authority over the claim "orig", but only over the claim 'div'. A
>>verifier will have to check the embedded PASSporT, verify the signature
>>and check that the orig in the different PASSporT matches.
>>
>>Though in another cases, if the originating number and the diverting
>>are served by the same operator, the operator has authority over both
>>orig and div claims. A nested PASSporT would not be needed in this case.
>>
>>The end result is quite similar as if we have multiple Identity headers.
>>In the end there are multiple PASSporT objects, the difference is how
>>they are conveyed in the signaling.
>>
>>I assume the main reason for the embedding is because of the oob
>>solution, or?
>>
>>Regards, Julio
>>
>>> -----Original Message-----
>>> From: Christer Holmberg [mailto:[e-mail]]
>>> Sent: den 24 januari 2018 15:06
>>> To: Chris Wendt <[e-mail]>
>>> Cc: [e-mail]
>>> Subject: Re: [stir] PASSPorT: "orig" and "dest" mandatory in all
>>>PASSPorTs?
>>> 
>>> Hi,
>>> 
>>> >I guess i¹m not following what¹s not clear, if you MUST only have
>>> >one orig claim and one identity in that claim, that seems to be
>>> >pretty clear to me that you cannot either not have an orig claim or
>>> >have more than one.  I guess maybe i¹m missing something subtle in
>>>your point.
>>> 
>>> It is clear that you cannot have more than one claim, but I think it
>>>could be  made more clear that you always must have a claim to begin
>>>with :)
>>> 
>>> >For extensions, and in general with any PASSporT, once the PASSporT
>>> >is signed, that¹s it, you cannot modify claims or "re-sign".  If you
>>> >want new PASSporT claim information that you want to sign, you must
>>> >have a new PASSporT or new identity header.
>>> 
>>> Correct, I should have made that clear.
>>> 
>>> So, if you have two (or more) Identity header fields, do they all
>>>have to  contain the same ³orig² value? Or, is one allowed to change
>>>it?
>>> 
>>> Does the same apply for ³dest²? And, if you want to change the ³dest²
>>>you  need to use the divert extension? You can¹t just add a new
>>>passport with a  new ³dest² value. Or?
>>> 
>>> >Currently for divert, the approach is to embed a PASSporT inside a
>>> >new PASSporT, which is a valid technique also and result in a new
>>> >identity header also (but you should remove the old identity header
>>> >in this
>>>case).
>>> 
>>> My colleague Julio sent some questions and issues regarding the
>>> ³embedding²/³nesting² approach. I would be happy if you look at those
>>> :)
>>> 
>>> Regards,
>>> 
>>> Christer
>>> 
>>> 
>>> >
>>> >-Chris
>>> >
>>> >> On Jan 23, 2018, at 2:19 PM, Christer Holmberg
>>> >><[e-mail]> wrote:
>>> >>
>>> >> Hi Chris,
>>> >>
>>> >>>> Question for clarification:
>>> >>>>
>>> >>>> Section 5.2.1 of draft-passport says:
>>> >>>>
>>> >>>>      "There MUST be exactly one "orig" claim with exactly one
>>> >>>>identity claim object in a PASSporT object."
>>> >>>>
>>> >>>> Q1: Does the text above mean that
>>> >>>>
>>> >>>>      a) a passport must always contain one, one only one, "orig"
>>> >>>>claim; or
>>> >>>>      b) that if a passport contains an "orig" claim, if can only
>>> >>>>contains one?
>>> >>>
>>> >>> It can only contain one key value pair with the key ³orig² and
>>> >>>the claim value can only be one identity.
>>> >>>
>>> >>> In other words you cannot claim to originate multiple identities
>>> >>>with a single passport object.
>>> >>
>>> >> Correct. The question is whether "orig" is mandatory (alternative
>>> >>a) or not (alternative b). But, based on your reply to Q2 below, I
>>> >>assume the answer is alternative a).
>>> >>
>>> >> I think it would be good to make that more clear.
>>> >>
>>> >>>> Q2: If a), does it apply to passport extensions too?
>>> >>>
>>> >>> All extensions must include the base passport claims and follow
>>> >>>all rules of the claims, so yes.
>>> >>
>>> >> I think it should be more clear whether a node can modify claims
>>> >>or not when adding an extension, or whether an extension needs to
>>> >>explicitly allow it. Currently the text only says (AFAIK) that
>>> >>claims cannot be removed.
>>> >>
>>> >> For example, if I have a base passport, and add an RPH passport, I
>>> >>assume I cannot change the value of the "dest" claim. I would need
>>> >>to use a divert claim for that.
>>> >>
>>> >> Also, as the passports may be added and signed by different
>>> >>authorities, and as each passport will contain the base claims, it
>>> >>means that the base claims will be signed multiple times, and they
>>> >>may be signed by different authorities. I assume that is ok.
>>> >>
>>> >> Regards,
>>> >>
>>> >> Christer
>>> >>
>>> >
>>> 
>>
>>_______________________________________________
>>stir mailing list
>>[e-mail]
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailm
>>an_ 
>>listinfo_stir&d=DwIFAw&c=MOptNlVtIETeDALC_lULrw&r=dQ51tLfoGuuFjanmfeKC0
>>weX 
>>HNMl9xZnnsIiwRd6IgY&m=CYEKQetxoYJFWkCYlTjULI4cuXYtswc-ksgANHWODz0&s=n8n
>>5Xn LoHH1N9qVTNdWCn5VNUcQIQMajN21qTivbnD8&e=
>