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

From: Ben Campbell <[email-masked]>
Date: Mon, 8 Apr 2019 13:00:58 -0500

Hi,

I agreed in Prague to review draft-ietf-stir-passport-divert, and have done so. I think it’s mostly in good shape, but have some minor comments and questions.

Thanks!

Ben.

*** 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?)

- "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?)

- "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?

- "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?

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

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.

§11: Are there scenarios wheret the original destination in a diverted call could be privacy sensitive?

*** 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?

§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” :-)

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 17 Apr 2019 23:19:46 +0000

Thanks for the comments, Ben. A few notes below.    

    §4.2:

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

<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

<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

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

<Jon>It's only here because "div-o" defines it and uses it.</Jon>

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

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

    

    §1:

<Jon>Yes. I gather I should be a little more clear.</Jon>