Re: [stir] SIP PASSporT and Registrations

"Brian C. Wiles" <> Thu, 01 June 2017 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B061012ECA1 for <>; Thu, 1 Jun 2017 06:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.018
X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RatXMIwNAneY for <>; Thu, 1 Jun 2017 06:46:12 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7CA7E12ECA0 for <>; Thu, 1 Jun 2017 06:46:12 -0700 (PDT)
Received: from ([]) by : HOSTING RELAY : with SMTP id GQPXd4gqFStwFGQPXdEbN6; Thu, 01 Jun 2017 06:45:11 -0700
Received: (qmail 21601 invoked by uid 2); 1 Jun 2017 06:45:11 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_d3e53696a173d8cf95e4d0d86166a6cb"
Date: Thu, 01 Jun 2017 08:45:11 -0500
From: "Brian C. Wiles" <>
In-Reply-To: <>
References: <> <>
Message-ID: <>
User-Agent: RoundCube Webmail/0.5.1
X-CMAE-Envelope: MS4wfPCyp60TKBR5tdIe7TYXRNk9TCp2E+iZ+m5xExGjkkitguFp3aJ8pUEZ2ZXz7T3YpOoAHeZ0+uVX1eMUU3J91PeSQXoVA4IIKbgMR4T2AtKCMPvtV8Qv PblgLyxhs8CU0uuNibvAs4zGB4QO5rOpNR3iSypqOYefvIlVo9xvgWeTPa0Vm6eKOQ/ezluJEwoq12pntdbEwPqZt6iCTcIuJjU=
Archived-At: <>
Subject: Re: [stir] SIP PASSporT and Registrations
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 01 Jun 2017 13:46:14 -0000


Hi, Chris, 

 OK, that sounds fine then. Can we get a JWT
authentication scheme standardized for SIP? I'll write up the draft if
so. Also, would that be under SIPCORE? Thanks! 


On Thu, 1 Jun
2017 00:15:52 -0400, Chris Wendt wrote: 

> Hi Brian, 
> What you are
really looking for is not Passport but specifically an authentication
mechanism. Passport is not for authentication and is very specific to
proving an originator to a destination party. Thus the explicit
dependency on orig and dest as claims in the JWT. 
> There was some
recent work on using OAuth 2.0 with SIP, and as you say there is other
authentication mechanisms exist outside of SIP both using JWT and not.
But unfortunately, Passport is not going to be the right answer for
> -Chris 
>> On May 31, 2017, at 2:24 PM, Brian C.
Wiles wrote: 
>> Hi, Jon and Chris, 
>> I have been searching
for a way to use JSON Web Tokens in SIP, and it looks like PASSporT is
close to what I need. However, I see a couple of issues that would need
to be addressed in order for me to be able to use it. I was hoping we
could get some changes before it becomes a final RFC because I think
they are big issues for some uses of SIP, but it sounds like I'm a bit
too late. 
>> The main issue is that PASSporT is only designed for
INVITEs. There is no method for handling REGISTER events in the context
of a PASSporT. For example, I have clients that need to authenticate
with a SIP gateway to receive calls, and I'm trying to use JWT tokens so
that my SIP gateway doesn't have to contact an external database or web
service to verify the credentials. 
>> The other issue is that I
don't want to have to specify the destination in my PASSporT token. I
realize there are some security implications there, but using
expirations via the "exp" claim and other methods, I can protect against
replay attacks, etc. My architecture has its own security protocols to
prevent unauthorized use, and I don't really care how many calls are
made since they are only to other clients who have registered. 
My current implementation is close to PASSporT but using the
Authorization header like most other JWT implementations use. I'm fine
with using PASSporT if we can at least make the "dest" claim optional
and specify that it can be used with REGISTERs as well. Let me know what
you think. I'd like to get something drafted soon before I publish my
open source module. Thanks. 
>> -Brian