Re: [stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

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

PASSporT is indeed an object format in its own individual specification,
if that's what you mean by the "level of indirection". I consider it a
point of architectural modularity. The working group agreed to organize
the work this way because we did not want to tie STIR too closely to any
particular using protocol (such as SIP). The actual job that needs to be
done here is mitigating the threats defined in our charter and threat
model, which are not specific to SIP. Even though we've repeatedly
explained to you that this independence from SIP was the motivation for
adopting PASSporT, it still does not seem to be sinking in, as you keep
saying things below about how the role of PASSporT is SIP-specific.

Although you seem to feel that this modularity is for some reason a matter
of impossible complexity, the working group, as far as I can tell, is
comfortable with this architecturally. I'm aware of a couple of early
implementations, of running code that does this today. While the situation
you describe sounds very alarming, it is also as far as I can tell utterly
detached from reality. If there's a practical problem here worthy of a
fundamental reconsideration of our direction, it is not coming through in
your objections.

Jon Peterson
Neustar, Inc.

On 8/8/16, 2:21 PM, "Dave Crocker" <[e-mail]> wrote:

>On 8/6/2016 10:50 AM, Peterson, Jon wrote:
>> Briefly, there is and always has been a "bare minimum" set of headers
>> and claims that are mandatory for PASSporT. Ultimately, the question of
>> what headers and claims are mandatory in PASSporT is a stir-passport
>> question. SIP as a using protocol of PASSporT defines only which fields
>> in a SIP request will populate those mandatory components of a PASSporT
>> object, and that information is given in considerable detail in RFC
>> 4474bis today.
>>
>> Extensions may propose additional claims that will appear in PASSporT
>> objects. The extensibility model of PASSporT is similarly a matter for
>> the PASSporT spec rather than RFC 4474bis, though we anticipate that
>> extensions may want to specify some initial using protocol behavior as
>> well. We should have a few examples of that soon.
>
>
>I've read through the above a few times, to make sure I understood it.
>(Really, it did take more than once.)
>
>
>The role being played by passport is to aid in authentication of the SIP
>caller-id information.  In terms of STIR's charter and the current round
>of specifications, that's is sole role. (I've phrased it with a generic
>term like 'caller-id' in order to encompass the variations that provide
>the value to be validated.)
>
>In spite of having carefully read the passport spec and slogging through
>the rfc4474bis spec, I had not fully appreciated the level of
>indirection and complexity being introduced with the passport construct,
>until your note above.
>
>This isn't just an encoding abstraction.  It's an entirely independent
>layer of complex mechanism, where the actual job that needs to be done
>is just finding a key and then hashing and signing some SIP header
>information.
>
>The aggregate complexity and indirection of the specs developed so far
>seem to make it essentially impossible to determine a specific usage
>scenario that is viable.  And from what I can tell, this includes an
>inability to determine what details are yet to be specified, before
>there is core, usable capability that can operate over the Internet.
>
>d/
>-- 
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net