Re: [stir] Benjamin Kaduk's Discuss on draft-ietf-stir-passport-divert-08: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Jon,

On Mon, Jul 13, 2020 at 02:45:45PM +0000, Peterson, Jon wrote:
> 
> Hi Benjamin,
> 
> Thanks for the thorough review of divert-08 (and apologies for the long RTT):

I think I managed to swap back in enough context to remember what's going
on...

> On 4/7/20, 1:54 PM, "Benjamin Kaduk via Datatracker" <[e-mail]> wrote:    
>     
>     ----------------------------------------------------------------------
>     DISCUSS:
>     ----------------------------------------------------------------------
>     
>     I support Roman's Discuss.  Isn't there a straightforward translation of
>     the "div" procedures to the nested "div-o" chain?  Why would that not be
>     applicable?
> 
> See my response to Roman, but yes, I agree it's designed to be a relatively straightforward translation, and I've fleshed that out a bit.

More than a bit :)
It seems okay to me.

>     I had two other points for discussion:
>     
>     (1) IANA seems unhappy (the expert review identified issues).  What's the
>     plan to address them?
>     
> We've followed up with them, the changes they proposed are fine, and are in the new version of the document.

Interestingly, I don't see a resolution of the thread in the jwt-reg-review
archives, though the datatracker status shows a clear "IANA OK" that showed
up a couple days after your message here, so I'm going to assume they know
what they're doing.

>     (2) The following text from the Security Considerations seems inconsistent
>     to me:
>     
>                                                               However,
>        including this information about forwarding is at the discretion of
>        the retargeting entity, so if there is a requirement to keep the
>        original called number confidential, no PASSporT should be created
>        for that retargeting - the only consequence will be that downstream
>        entities will be unable to correlate an incoming call with the
>        original PASSporT without access to some prior knowledge of the
>        policies that could have caused the retargeting.
>     
>     I don't understand this -- if the idea is to keep the original called
>     number confidential, wouldn't this necessitate *not giving the original
>     PASSporT to the called entity*, since the original PASSporT includes the
>     original call destination?  Without the original PASSporT at all, of
>     course it can't be correlated to an incoming call...  (Even in the OOB
>     case, would the post-retargeting called entity even be able to
>     retrieve/decrypt the original PASSporT?)  Is this intended to only apply
>     to some non-SIP case?
> 
> This paragraph is trying to refer at a high level to cases where complicated things are going on with the called number, like say, substituting it for an MSRN in roaming mobile telephone cases, where some intermediate identifier is, from the perspective of the diverting authentication service, the "original" called number. Some ways that number portability works would be comparable for landline call routing. I think the problem there is the word "original" - what I mean is the called number that the diverting authentication service sees, not the contents of the "orig" in the original PASSporT. I'll replace "original" with "an intermediate".

Oh, that makes much more sense!  Thanks, that minor change really helps me
understand what's going on.

I did read through the responses to my comments (much appreciated!), but
your explanations all make sense and I don't have anything further to say.
I see what you did with "the imagination of the author of RFC 3323", though :)

Anyway, I'll go clear my Discuss now.

Thanks again,

Ben

>     ----------------------------------------------------------------------
>     COMMENT:
>     ----------------------------------------------------------------------
>     
>     While it looks like the main change in the -08 is intended to address
>     the secdir reviewer's comment, it would be nice to respond to the review
>     and mention the new text.
> 
> Will do.
>     
>     Do we need to say something about whitespace being added to examples for
>     readability?
>     
> We're dealing here with JSON objects and header field values that are generally rendered to humans with some whitespace in them, I don't think our treatment is unusual.
> 
>     Section 1
>     
>     Is there an intended mnemonic for the "opt" element?  ("Original
>     passport"?)
> 
> Yes, added exactly that.
>     
>     Do "div-o" PASSporTs necessarily carry both "div" and "opt", or is "opt"
>     intended to be able to stand alone in a "div-o" PASSporT?
> 
> I believe we clarify that when we discuss "div-o", but "div-o" PASSporTs contain both a "div" and an "opt".
>     
>     Section 3
>     
>        canonical form of the "dest" identifiier is not changed during
>     
>     nit: s/identifiier/identifier/
> 
> Fixed.
>     
>        A "div" PASSporT claims set is populated with elements drawn from the
>        PASSporT(s) received for a call by the retargeting entity: at a high
>     
>     When would there be multiple received PASSporTs that all are input to
>     the same "div" PASSporT?
> 
> There can be multiple PASSporTs contained in the same SIP request, for example in cases where there is one signed by the originating carrier and another signed with a special government "rph" field (which has an independent trust anchor), even though the two PASSporTs share the same "dest" and "orig", as is discussed in Section 4.1.
> 
>     Also, the later discussion that indicates only a small number of
>     claims/extensions are copied from the original PASSporT (and that "iat"
>     might change!) suggests that perhaps the "is populated with" language
>     could be tweaked.
> 
> I think "at a high level" indicates that we are here just trying to convey the basic gist.
>     
>        level, the original identifier for the called party in the "dest"
>        object will become the "div" claim in the new PASSporT.  If the
>     
>     This "will become" language seems a bit problematic when combined with
>     the definition in Section 8 of an "hi" element within the "div" claim,
>     which is not part of the "original identifier for the called party".
> 
> Same comment- "at a high level", the "dest" populates the "div". I do not think it would help the reader's understanding to encumber this introductory sentence with corner cases and exceptions.
>     
>        The combined full form PASSporT (with a signature covered by the
>        ES256 keys given in Appendix A) would look as follows:
>     
>         eyJhbGciOiJFUzI1NiIsInBwdCI6ImRpdiIsInR5cCI6InBhc3Nwb3J0IiwieDV1Ij \
>         oiaHR0cHM6Ly93d3cuZXhhbXBsZS5jb20vY2VydC5jZXIifQ.eyJkZXN0Ijp7InRuI \
>         jpbIjEyMTU1NTUxMjE0Il19LCJkaXYiOnsidG4iOiIxMjE1NTU1NTEyMTMifSwiaWF \
>         0IjoxNDQzMjA4MzQ1LCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0.xBHWipDEE \
>         J8a6TsdX6xUXAnblsFiGUiAxwLiv0HLC9IICj6eG9jQd6WzeSSjHRBwxmChHhVIiMT \
>         SqIlk3yCNkg
>     
>     (The decoded claims set is sorted, though the previous display-form
>     example was in a different order.)
> 
> I'll fix that.
>     
>     Section 4
>     
>        This section specifies SIP-specific usage for the "div" PASSporT type
>        and its handling in the SIP Identity header field "ppt" parameter
>        value.  Other protocols using PASSporT may define behavior specific
>        to their use of the "div" claim.
>     
>     Is the last line supposed to be "claim" or "PASSporT type"?
> 
> I don't think the distinction particularly matters for the purposes of this statement. "div" claims are not used outside of "div" (or "div-o") PASSporTs. I guess the existence of "div-o" is a decent reason to go with claim rather than PASSporT type here.
>     
>     Section 4.1
>     
>        The retargeting entity SHOULD act as a verification service and
>        validate the existing Identity header field value(s) in the request
>        before proceeding; in some high-volume environments, it may instead
>        put that burden of validating the chain entirely on the terminating
>        verification service.  As the authentication service will be adding a
>     
>     Is this intended to be the only allowed exception to the SHOULD?  (Can
>     we phrase it as a MUST instead, e.g., "except when it is know that the
>     terminating verification service will do so, the retargeting entity MUST
>     act as a verification service"?)
> 
> This is not meant to be an exception solely for that case, no, that's just an example. I think the key point is that the security of the system is not weakened by the retargeting entity failing to act as a verification service - the terminating entity has to, so it is really just redundant work being done by the redirecting entity. Nice to do, so the network isn't clogged by "div" chains that won't pass validation, but not something I want to MUST. 
>     
>        PASSporT.  Note that this effectively creates multiple chains of
>        "div" PASSporTs in a single request, which complicates the procedures
>        that need to be performed at verification services.
>     
>     [ponders whether there should be more security considerations about
>     these added complications]
> 
> I'm not sure there are security implications that are not enumerated in 4.2, when we talk about how to resolve each chain.
>     
>        not for "div" PASSporTs with earlier targets.  Ordinarily, the
>        current target will be readily identifiable, as it will be in the
>        last "div" PASSporT in each chain, and in SIP cases it will
>        correspond to the Request-URI received by the retargeting entity.
>        Moreover, the current target will be an identifier that the
>        retargeting entity possess a credential to sign for, which may not be
>        true for earlier targets.  Ultimately, on each retargeting, the
>        number of PASSporTs added to a request will be equal to the number of
>        non-"div" PASSporTs that do not share the same "orig" and "dest"
>        object values.
>     
>     We seem to be providing two or three descriptions of the number of new
>     "div" PASSporTs to be created, and it's hard to have full confidence
>     that all are guaranteed to produce identical results.  Is it possible to
>     clarify a single definitive procedure?
> 
> This paragraph (which if I recall was suggested by an earlier reviewer) exemplifies the behavior of a second redirecting entity in a chain, as the snipped part of the first sentence of the paragraph states. It is giving different guidance than the paragraph above it, which focuses on how the first redirecting entity to handle a request deals with multiple PASSporTs. 
>     
>     Section 4.2
>     
>        In order to validate a SIP request using the "div" PASSporT type, a
>        verification service needs to inspect all of the valid Identity
>        header field values associated with a request, as an Identity header
>        field value containing "div" necessarily refers to an earlier
>        PASSporT already in the message.  [...]
>     
>     (refers to one or more earlier PASSporT, no?)
> 
> I see the ambiguity you mean - each "div" PASSporT refers to an earlier "orig"/"dest" couplet that appears in at least one, but possibly more, PASSporTs in the request. Nonetheless, I think the wording of the next sentence clarifies what you do sufficiently that I'm not concerned with implementers misunderstanding the intention, and I think adding my very wordy caveat would not really add any clarity.
>     
>                                                         Deployments that
>        change the original To header field value to conceal the original
>        destination of the call from the ultimate recipient should note that
>        the original destination of a call may be preserved in the innermost
>        PASSporT.  [...]
>     
>     Should this also be noted in the security considerations?
> 
> I think that is sufficiently captured in the Security Considerations text you highlighted in your discuss (and in the security considerations of RFC8224). Actually I'll add a pointer to RFC8224, that might help.
>     
>     Section 5
>     
>        This specification defines a "div-o" PASSporT type that uses the
>        "div" claim element in conjunction with the opt (Section 6) PASSporT
>        claim element.  As is the case with "div" PASSporT type, a "div-o"
>     
>     nit: any reason why we refer to "div" as a "claim element" but "opt"
>     (with no quotes!) as a "PASSporT claim element"?
> 
> Definitely "opt" should have quotes there. But no, no distinction is intended between a "claim element" and a "PASSporT claim element", I can fix that.
>     
>     Section 6
>     
>        The presence of an original PASSporT claims set element, designated
>        as "opt", signifies that a PASSporT encapsulates another entire
>        PASSporT within it, typically a PASSporT that was transformed in some
>        way to create the current PASSporT.  Relying parties may need to
>        consult the encapsulated PASSporT in order to validate the identity
>        of a caller. "opt" as defined in this specification may be used by
>        future PASSporT extensions as well as in conjunction with "div-o".
>     
>     All the more reason for this document to specify the "div-o" usage's
>     validation procedures!
> 
> I'm not sure I follow you, but we're adding some text about "div-o" validation. Future PASSporT extensions that leverage "opt" would have to specify their own semantics for validating it in whatever context that might be (I could imagine it being very different from how div-o works).
>     
>     Section 7
>     
>        an impractical number of combinations.  But in very complex call
>        routing scenarios, attestation of source identity would only add
>        limited value anyway.
>     
>     I'm not sure what point this last sentence is trying to make.  "Yes this
>     is complicated, but no one would do it anyway"?  That doesn't really
>     support the case for retargeting over redirecting...
> 
> I'm just trying not to sweep the complexity of redirecting under the rug. For a number of reasons, I think in general redirection has better security properties than retargeting. It is only with regret that I heavily caveat it here. 
>     
>        STIR-aware SIP intermediaries that redirect requests MAY therefore
>        convey one or more PASSporTs in the backwards direction within
>        Identity header fields.  These redirecting entities will act as
>        authentication services for "div" as described in Section 4.1.  This
>        document consequently updates [RFC8224] to permit carrying Identity
>        header fields in SIP 300-class responses.  It is left to the
>        originating user agent to determine which Identity header fields
>        should be copied from the 3xx into any new requests resulting from
>        the redirection, if any: use of these Identity header fields by
>        entities receiving a 3xx response is OPTIONAL.
>     
>     Is the idea that making this use optional obviates any need for a
>     negotiation mechanism where the originating user agent indicates support
>     for receiving PASSporTs in the 300-class response?
> 
> It serves more of a purpose than that. An entity receiving a 3xx could just choose to send a new INVITE with a fresh PASSporT from its "orig" to the new "dest" imparted by the Contact header of the 3xx, ignoring the "div" PASSporT in the 3xx and in fact hiding that a redirection happened at all (the original called number might never appear in the new INVITE). In some respects, that’s a cleaner story than using the received "div" PASSporT. Where "div" is potentially relevant in 3xx responses is for a narrow but common set of use cases like freephone routing, where an 800 number (in the USA) is turned into a geographic number by some sort of database query, where you still want to convey the original 800 number and show that the right authority translated the freephone number into the geographical number - that's what the "div" there could do.
>     
>     Section 10.1.2
>     
>        Claim Description: Encapsulated JSON token
>     
>     Is it an encapsulated "JSON token" or "PASSporT [JSON Web Token]"?
> 
> This is part of what we're fixing with the IANA expert review, should be better now.
>     
>     Section 11
>     
>        However, as there may be unforeseen circumstances where the
>        revelation of service logic to the called party poses a privacy risk,
>        implementers and users of this or similar diversion-tracking
>        techniques should understand the trade-off.
>     
>     Don't the 300-class redirections also involve some revelation of
>     information to the calling party?  I think that could be worth
>     mentioning (though it's not specific to the PASSporT case).
> 
> I can mention that, though since the choice to send a 3xx is basically choosing to reveal that to the calling party, I'm not sure it's a potential leak as such - if you don't want the calling party to see the Contact choices, you retarget instead of redirecting. 
>     
>        Furthermore, it is a general privacy risk of identity mechanisms
>        overall that they do not interface well with anonymization services;
>        the interaction of STIR with anonymization services is detailed in
>        [RFC8224] Section 11.  Any forwarding services that acts as an
>        anonymizing proxy may not be able to provide a secure chain of
>        retargeting due to the obfuscation of the originating identity.
>     
>     Isn't there also a risk that an anonymizing proxy might not know to
>     remove all the (information contained in the) PASSporTs, thus
>     inadvertently leaking identity information?
> 
> If so, I don't think this spec is the right place to address it, that would be a general issue with PASSporT. But most likely they wouldn't. Anonymization service implementations act as B2BUAs and destroy the originating SIP request and create a new one, or at least they would, if they existed in the field outside of the imagination of the author of RFC3323.
>     
>     Section 12
>     
>        risk arises at the discretion of the retargeting domain: simply using
>        3xx response redirections rather than retargeting (with supply a
>        "div" per Section 7) mitigates the potential impact.  Under unusual
>     
>     nit: grammar is weird around "with supply a 'div'"
> 
> Fixed!
>     
>     Appendix A
>     
>     Thanks for including the keys needed to validate the examples!
>     (Alas, I don't have a JWT or JOSE library handy, so I didn't do so...)
> 
> NP, thanks again for the thorough read.
> 
> Jon Peterson
> Neustar, Inc.
>     
>     
>     
>     
>