Re: [stir] Comments on draft-ietf-stir-passport-divert

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

Thanks for the comments, Ben. A few notes below.    
    
    *** Substantive Comments ***
    
    §4.2:
    
    - What happens if a “div” passport chains back to a PASSporT object with an unknown “ppt” value? Is the answer the same if the offending ppt occurs at the innermost PASSporT vs in the middle of the chain? (That is, is there any possibility of traversing a ppt of unknown type when verifying the chain?)

<Jon>If you can't validate the innermost PASSporT in a chain, validation of that chain fails for you. I can put in specific text about the innermost if that is helpful; all of ones in the middle of the chain, though, should be of ppt "div", though, so I'm not sure there really is any possibility of traversing a PASSporT of unknown type in the middle of the chain.</Jon>
    
    - "The verification service SHOULD also verify
    that all other "div" PASSporTs in the chain share the same "orig"
    value.”
    
    What is the benefit of doing this? What would be the consequences of not doing it? What would be reasonable behavior if the verifier discovered a non-matching orig? (And depending on the answers: Why not MUST?)

<Jon>Yeah, it seems kind of belt-and-suspenders to do make verification services do it, which is why I'm fence-sitting a little. It's kind of hard to imagine what the non-matching orig-in-the-middle case would be, or how it could be exploitable for some sort of attack. If there were a non-matching orig, but the dests chained properly otherwise, it's unclear what vulnerability that could expose. I guess I'd be comfortable moving it to a MUST, just for the sake of being paranoid - in ordinary operations, it should always be true.</Jon>
    
    - "It
    is furthermore RECOMMENDED that the verification service check
    that the "iat" field of the innermost PASSporT is also within the
    date freshness interval; otherwise the verification service could
    allow attackers to replay an old, stale PASSporT embedded in a
    fresh "div”.”
    
    Why is this not a MUST? Do you envision situations where it would be reasonable not to comply?

<Jon>This would be a case where a call got bounced around just a ton by redirection, into call parking or something. The date freshness interval is a matter of local policy in 8224, it is just RECOMMENDED that it be sixty seconds. I'm just keeping this at around the same normative level.</Jon>
    
    - "PASSporT. Note
    that (per Section 4.1) a chain may terminate at more than one
    innermost PASSporT, in cases where a single "div" is used to
    retarget from multiple based PASSporTs.”
    
    What happens if some of the terminating PASSporTs fail verification but others succeed?

<Jon>In the baseline STIR philosophy, if an INVITE arrives with 5 Identity headers, and 4 of them fail, that's fine, you can use the 5th. The authorization decisions here are, again, a matter of local policy, but if you have at least one PASSporT that has a valid signature from a cert that you trust, you can pass that validation info to the application. This is really intended to cover cases where, say, there are multiple trust anchors in play, and maybe you trust certs issued by one of them but not the others; or cases where someone along the way has a borked implementation but the other ones are okay, things like that. The implication for multiple chains is that you trust chains that work and ignore ones that don’t.</Jon>
    
    §6:
    
     Is “opt" intended for general purpose use? If so, I suggest splitting it out into a separate draft. “Div" seems like a strange place to hide it.

<Jon>It's only here because "div-o" defines it and uses it.</Jon>
    
    Is there a hard 3 letter limit for passport parameter names? “opt” seems rather non-mnemonic due to the collision with the plain English word.

<Jon>Heh, no, we're just following the convention in the JWT Claim Registry, though as a convention, if you look it up in IANA, it is honored more in the breach than the observance... If this really causes any heartburn I can change it.</Jon>
    
    §11: Are there scenarios wheret the original destination in a diverted call could be privacy sensitive?
    
<Jon>It is probably worth having some Privacy Considerations sort of text about that. The short answer is that it is a trade-off in mechanisms like this (History-Info is the same way) that you can expose something like the service logic involved in routing the call to the terminating side. Whether we should really consider that a "privacy" risk is a bit hard to say, because it is in ordinary operations information about the routing policy of the called party being exposed to the called party - and if it isn't, for some reason, and calls are being forwarded involuntarily to the ultimate called party, it seems like the ultimate called party might be entitled to know about it. But it's probably worth talking about.</Jon>

<Jon>Nits below are appreciated, one clarification.</Jon>
    
    *** Editorial Comments and Nits ***
    
    - There are some minor complaints from IDNits that should be addressed prior to pubreq.
    
    - Please expand the following acronyms:
    
    PASSporT (in title, abstract and body)
    JWT
    STIR
    
    §1:
    - "practically speaking some operational environments do alter the
    To header field”
    That may be a bit of an understatement. Perhaps “some” should be “many”?
    
    - "and they both can capture minor syntactical changes in
    URIs that do not reflect a change to the actual target of a call.”
    
    I’m not sure what “capture” means in this contexrt. Are we talking about otherwise unnecessary H-I entries due to semantically equivalent but syntactically different URIs?

<Jon>Yes. I gather I should be a little more clear.</Jon>
    
    §2: Is there a reason not to use the updated boilerplate from RFC8174?
    
    §4.2: It seems early in the evolution of STIR to call base verification services “traditional” :-)