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

[Christer Holmberg <[e-mail]>]

Hi,

As Richard said, there is still work to do related to how things look in the wire, especially since we are not going to include the encoded JWT object string in one piece. But, again, I think that is more an 4474bis issue.

I do not, however, think that other "bodies" shall have to clarify the encoding on the wire - that needs to be clear in the core spec (other bodies might profile exactly what information is used to calculate the signature etc).

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Richard Shockey<mailto:[e-mail]>
Sent: ‎01/‎08/‎2016 01:04
To: [e-mail]<mailto:[e-mail]>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

Yep… +1

Dave whats the problem here? What do you want?

We choose JWT for a perfectly rational and technically elegant reasons.  We do know what data we want assert and sign.

On one point we totally agree. I have been less than satisified on how this actually looks on the wire. Examples. Jon has acknoledged this in his presentation in Berlin.

Fine picture from my presentation to the Genband conference BTW.

Where do the claims go in the INVITE.  I’m prepared to accept less than perfect since I know there are other bodies ready to provide guidence in order to accelerate adoption among the vendor community.

We think it will work and we have virturilly the entire US voice communicaitons industry using E164 addressing,  as well at the NRA in the US and elsewhere lined up ready to GO.

I support the last call I have trust the authors can provide revisions that can address some of the issues raised.


Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN [phone]




From: stir <[e-mail]> on behalf of Victor Pascual <[e-mail]>
Date: Sunday, July 31, 2016 at 2:44 PM
To: Christer Holmberg <[e-mail]>
Cc: Chris Wendt <[e-mail]>, "[e-mail]" <[e-mail]>, "Peterson, Jon" <[e-mail]>, IETF STIR Mail List <[e-mail]>
Subject: Re: [stir] Review of: draft-ietf-stir-passport-05

Fully agree

On 31 Jul 2016, at 19:54, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
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:[e-mail]>
Sent: ‎31/‎07/‎2016 00:08
To: [e-mail]<mailto:[e-mail]>
Cc: Christer Holmberg<mailto:[e-mail]>; Peterson, Jon<mailto:[e-mail]>; IETF STIR Mail List<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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<http://bbiw.net>
>
> _______________________________________________
> stir mailing list
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/stir
_______________________________________________
stir mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/stir
_______________________________________________ stir mailing list [e-mail] https://www.ietf.org/mailman/listinfo/stir