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

Hi,

I agree with Chris. JWT is NOT a mechanism to sign any arbitrary JSON structure. JWT is a mechanism to sign data, and it uses a specific JSON structure (header, claims etc) for doing so. In addition, it provides a mechanism to signal what data/algorithm is used to calculate the signature.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Chris Wendt<mailto:chris-ietf@chriswendt.net>
Sent: ‎31/‎07/‎2016 00:08
To: dcrocker@bbiw.net<mailto:dcrocker@bbiw.net>
Cc: Christer Holmberg<mailto:christer.holmberg@ericsson.com>; Peterson, Jon<mailto:jon.peterson@neustar.biz>; IETF STIR Mail List<mailto:stir@ietf.org>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

Hi Dave,

I’m not following your argument that because there isn’t a JSON object to sign, we can’t use JWT?
In general, most/all uses of JWT don’t sign an existing object, a set of claims are constructed into a JSON payload that is signed.
There are JWT defined claims precisely defined to create a secure token intentionally meant to be only signed in a JWT.

So to me, we are more than appropriately using JSON and JWT.

It is in 4474bis, we define the exact information to construct the JSON payload object to be signed, so please refer to that.

There are many advantages to using the JWT construct both for STIR charter specifically and elsewhere.

Is that a bad thing?

-Chris

> On Jul 30, 2016, at 9:03 AM, Dave Crocker <dhc@dcrocker.net> wrote:
>
> Christer,
>
> Thanks for the background...
>
> On 7/30/2016 4:30 AM, Christer Holmberg wrote:
>> 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,
>
> Actually, it isn't.
>
> It's own opening text [RFC 7519] says it is "a compact, URL-safe means of representing claims to be transferred between two parties" but more importantly for this issue, it goes on to say:
>
>   "encoded as a JSON object that is used as the payload of a JSON
>   Web Signature (JWS) structure or as the plaintext of a JSON Web
>   Encryption (JWE) structure"
>
> That is, it provides value-added functions... to a JSON object (structure).  However SIP doesn't have a JSON object to sign.  So the working group has had to invent a JSON-based abstraction of SIP header information and then sign it.
>
> Now it has to invent an encoding for the resulting signature.  It would have to do that for a SIP call, no matter the signature's computational abstraction, but because that abstraction is actually an independent format, it wound up distracting the wg from doing a complete job -- so far, after 3 years -- of defining all the details for a complete authentication mechanism.
>
> From what I can tell of the email record for the wg, the unfortunate part of the discussion about choices here was to count JSON/JWT as something other than an abstraction.
>
> Signing an object requires defining the data over which the signature will be made, and how that data will be fed into the signing algorithm. Necessarily, that defines an abstraction of the data.  (Canonicalization seems to be a common component of that abstraction, for example.)
>
> There might be nothing different or better (or, probably, worse) about JWT in those terms; I haven't tried to evaluate it in those terms.  The problem is that its existence as a distinct format has caused the working group to worry about that new and independent object as distinct from the SIP data being signed, rather than as a computational result that then needs to be stored into the SIP header.  So all of the discussion about what to do with the JWT object is additional wg overhead and, IMO, a complete distraction for the primary task of the working group.  (My guess is that there is also added overall system complexity, but I won't press that concern, at this point.)
>
> Arguments that it's a general mechanism for use in other aspects of this space are always appealing. However they are, so far, without merit in the working group context: There are no specifications for any of those other uses.
>
> And the wg still hasn't resolved the very basic and very essential step of putting the signature into the SIP header.
>
>
>
>>     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.
>
> Well, yeah, I thought/think that too, which was why I originally suggested adapting DKIM. (DANE might be another relevant choice.)  DKIM offers an extremely high point of departure for SIP header signing.  The continued lack of complete specification details about use with SIP demonstrates that JWT doesn't.
>
>
>> 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.
>
> Right.  And the point I'm raising is not about the details of that choice but the fact that it still hasn't been made at this very late stage.
>
> Besides merely being a missing, essential bit of system specification, it suggests that the wg is still not completely clear about the concrete use of this capability.
>
>
> d/
> --
>
>  Dave Crocker
>  Brandenburg InternetWorking
>  bbiw.net
>
> _______________________________________________
> stir mailing list
> stir@ietf.org
> https://www.ietf.org/mailman/listinfo/stir