STIR WG / IETF 97 Seoul, Nov 2016 Jon PASSporT Extensions STIR WG / IETF 97 Seoul, Nov 2016 Jon

Twofold PASSporT extensibility model First, just throwing in new claims For adding claims beyond the bare minimum Any new claims signed in addition to the baseline Requires normal JWS IANA registration procedures for claims Requires full form PASSporT as well Second, “ppt”

Demonstrating extensibility Before we ship rfc4474bis/PASSporT Be nice to know if the extensibility model works Both with and without a “ppt” Added a single claim for display-name “cna” – short for CNAM Captures display-name in SIP in a “nam” subelement Though it is extensible for additional data Also added a claim for diversion information “div” - we’ll talk about that one first

draft-peterson-passport-divert-00 A feature many people have asked about How do we handle retargeting? To header field of SIP is signed by PASSporT Original value may be lost with retargeting We could define a special Identity header track it With its own “ppt” – “div” for “divert” Different from History-Info and Diversion? Yes, as it is signed by the original destination domain Useful for things like SIPBRANDY where integrity protection for retargeting matters

Inverting the usual rule Mandatory extensions let you alter baseline behavior An Identity header with “div” always points to some prior Identity header Though that header may in turn contain a div… Chains back to an original assertion A diverting auth service takes an existing PASSporT, moves the “dest” to “div,” and populates “dest” with the new target Instead of signing for the “orig” value, the auth service for “div signs the “dest”

For an original PASSporT… Header: { "typ":”passport", "alg":”ES256“, "x5u":"https://www.example.com/cert.pkx" } Claims: { ”orig":{“uri”:”alice@example.com”}, ”dest":{“uri”:”firsttarget@example.com”}, "iat": 1443208345 }

“div” with “ppt” Header: Claims: { "typ":”passport", "alg":”ES256“, "ppt":”div“, "x5u":"https://www.example.com/cert.pkx" } Claims: { ”orig":{“uri”:”alice@example.com”}, ”dest":{“uri”:”secondtarget@example.com”}, "iat": 1443208345, “div”:{“uri”:”firsttarget@example.com”} }

draft-peterson-stir-cnam-01 Operates in two modes Without “ppt” This signifies that an originating authentication service provides the caller name Same entity that signs for the originating number With “ppt” This signifies that a third party provides the assertion Different entity than signs for the originating number Signature can come from someone that doesn’t own the TN Different Identity header field as well

“cna” without “ppt” Header: Claims: { "typ":”passport", "alg":”ES256“, "x5u":"https://www.example.com/cert.pkx" } Claims: { ”orig":{“tn”:"12155551212”}, ”dest":{“tn”:"12155551213”}, "iat": 1443208345, “cna”:{“nam:”Alice Atlanta”} }

“cna” with “ppt” Header: Claims: { "typ":”passport", "alg":”ES256“, "ppt":”cna“, "x5u":"https://www.example.com/cert.pkx" } Claims: { ”orig":{“tn”:"12155551212”}, ”dest":{“tn”:"12155551213”}, "iat": 1443208345, “cna”:{“nam:”Alice Atlanta”} }

Elaborating on “cna” Possible to add more claims than “nam” in the “can” element Could include information about organizations Maybe some fields in Henning’s Caller-Info parameters Location, potentially Likely be reference rather than by value Other rich data associated with the originating persona Creates an IANA registry allowing allocation of more related elements

Sanity checking So we have some examples of PASSporT extensions Oh yeah, one more – SIPBRANDY “msec” If there’s interest, we could go there Sure, STIR isn’t chartered to do CNAM now… But we have a charter discussion today Crucial now to make sure people understand extensibility for STIR If we’re getting it wrong, we’d better fix it soon