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

[Christer Holmberg <[e-mail]>]

Hi,

>I certainly hope that the semantics are basically the same, yes, that the only real difference is in how nested "div" is carried in the signaling.
>The main reason for embedding right now is forward compatibility with OOB, correct. If we ever decided we wanted to be able to encrypt 
>PASSporTs carried in-band, this would also be very handy. In general it seems like kind of a nuisance to hand a verification service a pile of 
>Identity headers and say "you figure out what goes with what" - when I started pondering cases with spirals in signaling, for example, I got 
>a little worried.

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 next revision to the document is going to talk a bit about an issue that has arisen in implementation (already) with the Diversion header and 3xx responses. There >probably should be a means for a 3xx to carry a nested PASSporT in the response that could be tucked into an Identity header by any entity sending new INVITEs based on >the Contacts in the 3xx
>- but there are a few potential pitfalls there we need to avoid, or at least carefully mark.

Assume the following: 

1 . The "original" (pre-3xx) INVITE traverses proxies P1 and P2. Each of those proxies insert a claim. 
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.
3.  The 3xx reaches the UA, which sends a "new" INVITE, which contains the nested PASSporT provided in the 3xx.
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?

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


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

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=