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

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

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

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

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

6. For an original PASSporT…
Header:
{ "typ":”passport",
"alg":”ES256“,
"x5u":" }
Claims: {
"iat": }

7. “div” with “ppt” Header: Claims: { "typ":”passport", "alg":”ES256“,
"ppt":”div“,
"x5u":" }
Claims: {
"iat": , }

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

9. “cna” without “ppt” Header: Claims: { "typ":”passport", "alg":”ES256“,
"x5u":" }
Claims:
{ ”orig":{“tn”:" ”},
”dest":{“tn”:" ”},
"iat": ,
“cna”:{“nam:”Alice Atlanta”} }

10. “cna” with “ppt” Header: Claims: { "typ":”passport", "alg":”ES256“,
"ppt":”cna“,
"x5u":" }
Claims:
{ ”orig":{“tn”:" ”},
”dest":{“tn”:" ”},
"iat": ,
“cna”:{“nam:”Alice Atlanta”} }

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

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