Subject: Re: [stir] Using PASSporT with things other than STIR

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 5 Jul 2016 20:14:28 +0000

I agree with that we need to nail this stuff down before we ship the
PASSporT spec.

>Can we offer any advice to the developer to help them decide when it is
>necessary to use an alternate set of claims?  Also, can we offer any
>advice regarding the properties that are needed to determine if an
>alternate claim set meets the security requirements?  For example,
>during the development of STIR we wanted to prevent cut-and-paste
>attacks.

This is a big one, I think. Pretty much any alternate set of claims would
need to meet some minimum security bar, like preventing cut-and-paste
attacks. There's a lot of language in RFC4474bis about why we think the
set of claims baseline PASSporT provides is sufficient for securing calls.
I think what we need to say here is pretty much that any specification of
an alternative set of claims needs a similar explanation of what threats
they prevent and what assurances they provide.

Otherwise, we could for example end up with an alternative PASSporT with
one claim - like, just the calling telephone number - which could easily
be cut-and-pasted by any attacker, and yet a SIP message containing it
would appear valid and secure, even though it offers no protections beyond
RFC3325, basically.

>Are there any implications on interoperability for adopting a different
>set of claims?

I do worry about "proprietary" one-offs that potentially could create a
needless interoperability failure. It's better to extend the bare minimum
when possible than it is do define a completely separate set of base
claims, as even if the recipient of an extended object doesn't understand
the additional data, it can still use the baseline to validate basic
Identity. Probably, we should only encourage people to adopt an
alternative set of claims that it not a superset of the PASSporT bare
minimum for applications that are genuinely distinct from the semantics of
placing a telephone call - pretty much anything that looks like a
telephone call will have the same requirements for the called/calling
party numbers (or URIs) and Date.

>Can we offer any guidance that tells the developer when it would
>be better to start fresh with JOSE JWS instead of trying to adjust
>PASSporT?  In other words, where should one try to apply the
>PASSporT framework, and where should one not bother.

If we only want to reserve alternative claims for use cases that don't
even look like telephone calls, presumably we'd want to say that PASSporT
is scoped to real-time personal communications, and that for uses that are
not salient to that, something building on baseline JWS would be more
appropriate?

Jon Peterson
Neustar, Inc.

---

From: Chris Wendt <[email-masked]>
Date: Tue, 5 Jul 2016 19:42:30 -0400

> On Jul 5, 2016, at 4:14 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 

I agree, perhaps we really do need to say that in order to be a PASSporT token, you must have the base claims, period.

I think that is ok for things like GETS and other use-cases we have talked about, certainly you wouldn’t want to allow or replay attacks or identity spoofing for these applications.  I don’t believe i can think of another PASSporT relevant/personal communications case that shouldn’t use the base claim, so maybe for now we just mandate it.

I’m good with that.

Plus that i think solves most of Russ’s concerns.

Maybe you can look at that as a shortcut, but i suspect we actually did allow for more flexibility than we really should have.

Shall I make the changes?  Any examples that anyone can think of that shouldn’t use the base set of claims?

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 6 Jul 2016 01:02:36 +0000

On 7/5/16, 4:42 PM, "Chris Wendt" <[email-masked]> wrote:

>I agree, perhaps we really do need to say that in order to be a PASSporT
>token, you must have the base claims, period.

That is the easiest way to deal with it - but we still need to be specific
about what "the base claims" are. At first, I think we could have gotten
away with saying you need an "otn", "dtn" and "iat". Now that we have
"ouri" and "duri" too, as well as the multi-destination claim, our
statement of what the "bare minimum" is needs to be a little more
versatile while still being specific. We should also remember to
future-proof, as future specifications might define new forms of claims
for the originator and destination identities to work with new
applications.

I think the PASSporT text should clarify right up front (either in Section
3, or maybe Section 3.2) that all PASSporTs need at least one claim
identifying the originator, and at least one identifying a destination,
along with an "iat", to meet the requirements for the base claims. For the
most common STIR use case, the first two will be "otn" and "dtn", but we
want to leave the door open for other identifiers to fulfill this
requirement.

We should also add to the text of PASSporT (probably 4.2) a note that any
future specifications that define claims need to state in their
specifications that if a claim is intended to serve as an originator or a
destination for this purpose.

>I think that is ok for things like GETS and other use-cases we have
>talked about, certainly you wouldn¹t want to allow or replay attacks or
>identity spoofing for these applications.  I don¹t believe i can think of
>another PASSporT relevant/personal communications case that shouldn¹t use
>the base claim, so maybe for now we just mandate it.

I agree, if only because the current mechanism requires you to go out and
register a new MIME type anyway, and clearly you could do that with or
without the blessing of the PASSporT spec. At best, the guidance today is
tells you when you might want to go do that, which isn't a bad thing in
and of itself, but we could definitely leave any guidance like this to
future work rather than doing it right off the bat.

Jon Peterson
Neustar, Inc.

>I¹m good with that.
>
>Plus that i think solves most of Russ¹s concerns.
>
>Maybe you can look at that as a shortcut, but i suspect we actually did
>allow for more flexibility than we really should have.
>
>Shall I make the changes?  Any examples that anyone can think of that
>shouldn¹t use the base set of claims?
>
>
>

---

From: Chris Wendt <[email-masked]>
Date: Wed, 6 Jul 2016 09:21:01 -0400

> On Jul 5, 2016, at 9:02 PM, Peterson, Jon <[email-masked]> wrote:
> 
> 
> 

Fair enough, totally agree, i will work that into the text.

>> talked about, certainly you wouldnąt want to allow or replay attacks or
>> identity spoofing for these applications.  I donąt believe i can think of
>> another PASSporT relevant/personal communications case that shouldnąt use
>> Iąm good with that.
>> Plus that i think solves most of Russąs concerns.
>> 
>> shouldnąt use the base set of claims?
>> 
>> 
>> 
>