Re: [stir] Review of: draft-ietf-stir-passport-05

[Christer Holmberg <[e-mail]>]

Hi Dave,

I am the one who originally suggested the usage of JWT. I don't understand the claim that JWT is "outside the context of SIP". JWT is a generic/standardized mechanism how to calculate and encode a signature, and that is the reason I suggested it - not because I saw usage outside of SIP, or because I wanted to extend the scope of the charter. I see no reason why JWT can't be used by SIP. If we would NOT use JWT we would probably have to define more STIR-specific procedures regarding the calculating/encoding of the signature ourselves. It's better to use a standardized mechanism in my opinion.

I am also the one who raised the encoding issue in Berlin. But that was not related to the usage of JWT as such, but to the fact that we don't carry the encoded JWT object in one piece in the SIP message. We "split" the object into two pieces, and carry one piece as the Identity header field value, and the other piece as the canon header field parameter value. I questioned that, and commented that we, if we want to do it that way, need more details on how the "split" is done and how the resulting parts are encoded. Jon promised to add more text to cover those comments. Also note that  my comment was not related to draft-passport, but to draft-4474bis.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Dave Crocker<mailto:[e-mail]>
Sent: ‎30/‎07/‎2016 02:59
To: Peterson, Jon<mailto:[e-mail]>
Cc: IETF STIR Mail List<mailto:[e-mail]>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

Jon,

On 7/29/2016 2:56 PM, Peterson, Jon wrote:
> The only thing JWT has to do with SIP is that JWT can be a container for a
> signed set of metadata and claims that might be useful in preventing
> impersonation in a SIP request. JWT was chosen not because it has any
> exclusive or special applicability to SIP, but instead because it could
> have applicability both to SIP and other protocols.

Sorry to be repetitious but I do not see that case made, discussed or
agreed to in the working group record.

What I did see was a repeated claim that using JWT was simpler, which I
suspect is quite simply wrong, if only because it requires more
mechanism that directly adding the necessary information to a SIP header
field. (cf, DKIM, of course.)


>> Note that during the wg session in Berlin there was /still/ question
>> about where to put the JWT information.
>
> Kind of. It was a question about the best syntax for transporting only

And there's the rub.  At this stage of the effort, after 3 years of wg
effort, and given three major drafts in wg Last Call, something as basic
as how to carry the necessary information for its primary use case is
not settled yet.  That's quite troubling, both in general and, given the
importance and urgency of that motivating use case, in particular.


>> The recording of that interim is not accessible and the very terse
>> summary text of the session show nothing about an intervention.
>
> The "intervention" is reflected in the summary text: "Chris Wendt
> introduced the verified token being discussed in the IP-NNI task force."

Sorry to belabor this but how does 'introducing' something equate to "a
major intervention in the work last fall to the effect that we
need to build more generically for real-time communications rather than
just SIP. We're interested in getting this to work properly with WebRTC..."?


>  We made a decision there to
> try to merge these into the core proposal, as the summary reads "An open
> design team was formed to discuss finding a common way to address the
> signaling."

Ahh, so that's what that was intended to mean.

Except that while the word 'signaling' does show up in the messages at
that time, it doesn't seem to apply to this point.


> You are absolutely correct that there were no submissions to the STIR
> mailing list immediately following the interim on Friday October 9. Not a
> single related email went out on Saturday the 10th, Sunday the 11th, or
> even Monday October 12th (which, incidentally, was Columbus Day). Then, on
> the 13th, the only mail that went out announced that the Doodle poll for
> the design team had (behind the scenes) resolved, and that its first
> meeting would be that coming Friday, the 16th. The day of that design call
> there were 44 messages sent to the list on related subjects.

So, I think I understand the general idea behind 'claims' in a larger
context of transactions and reputations.  As a general model for making
and maybe validating a variety of assertions /about/ an entity, it's
probably a reasonable approach, although the pragmatics of its
application at Internet scale are arguably unproven.

However the task of authenticating the proper use of an identifier in a
field is a rather more constrained requirement.  And there are a number
of operational examples, which happen not to require a general claims model.

Simply put, the task is to take an identifier, bind it to the object
that is relevant (such as a SIP Invite), where the binding mechanism
requires a basic demonstration of 'approval' of the identifier's use,
from the authority responsible for administering the identifier.  That
really is all there is to the required semantics.

Things only get complicated when the goal is made more general (which I
don't see prompted by the working group charter.)


>> Nor do I see anything in the mailing list postings that /do/ show up
>> those several days later.
>
> I can imagine that since I had to annotate even the summary text of the
> interim meeting in order to show how it related to this topic, it might
> not be clear from the threads on encoding, the NNI and so on how they were
> salient to these decisions if you weren't participating in the WG at the
> time. Maybe looking at the design team minutes for Oct 16th would be
> clearer? It at least mentioned JWT explicitly.

I had already looked at those notes.  They didn't help.  There is
nothing I saw that made this expanded scope obvious, nevermind justified.

>
> https://www.ietf.org/mail-archive/web/stir/current/msg02183.html
>
>> So I've no idea what you meant by "hard upon it."
>
> I understand you feel that progress should have been more immediate to
> justify my characterization.
>
>> Hence your explanation:
>>
>>      "we need to build more generically for real-time communications
>> rather than just SIP."
>>
>> does not seem to reflected in the wg record.
>
> Maybe you'll find the Oct 16th design team minutes clearer on this point.
> Or maybe they too would require more annotation to clarify the subject and
> thinking of the working group after the fact. The discussions that they
> reflect, anyway, were sufficient to drive consensus at the time.

Sorry.  I still don't see any discussion on the list for the specific
requirement of other uses.  Lots of discussion about delegation --
including one suggesting a lack of requirement for a 'nicely engineered,
convoluted, infinitely extensible, handles all corner cases certificate
delegation model' -- but not for the expanded scope I am asking after.

So perhaps it was agreed to by the group in the same fashion that was
apparently going to be expressed for the current draft during the Last
Call, namely silence.

d/

--

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

_______________________________________________
stir mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/stir