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

[Dave Crocker <[e-mail]>]

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