[stir] SIP PASSporT and Registrations

"Brian C. Wiles" <brian@poldon.com> Wed, 31 May 2017 18:25 UTC

Return-Path: <brian@poldon.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCD3127337 for <stir@ietfa.amsl.com>; Wed, 31 May 2017 11:25:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.3
X-Spam-Level:
X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZdldrAKNs4i for <stir@ietfa.amsl.com>; Wed, 31 May 2017 11:25:44 -0700 (PDT)
Received: from p3plsmtpout003.prod.phx3.secureserver.net (p3plsmtpout003.prod.phx3.secureserver.net [208.109.80.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522961286B1 for <stir@ietf.org>; Wed, 31 May 2017 11:25:44 -0700 (PDT)
Received: from ip-208-109-238-122.ip.secureserver.net ([208.109.238.122]) by : HOSTING RELAY : with SMTP id G8IVdO7Y1Rf1vG8IVdd1sY; Wed, 31 May 2017 11:24:43 -0700
x-originating-ip: 208.109.238.122
Received: (qmail 28963 invoked by uid 2); 31 May 2017 11:24:43 -0700
To: <stir@ietf.org>, <jon.peterson@neustar.biz>, <chris-ietf@chriswendt.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_6813036402f30b945ab23a56cf72c78a"
Date: Wed, 31 May 2017 13:24:43 -0500
From: "Brian C. Wiles" <brian@poldon.com>
Message-ID: <01be31dd33c2c3dc576e8c73f0393b37@poldon.com>
X-Sender: brian@poldon.com
User-Agent: RoundCube Webmail/0.5.1
X-CMAE-Envelope: MS4wfKW18VhVxsYzUSJdpiO2kddpt/o1GX0BDOMbXfD6SzZHYG6maSZeEu8mZqsF622eDiTzsKfNa0nST7xJ6rBM0vJNdGUqd7lC1Jb3b+TErP6OHc/4TBCk hmxevHAPPqBvPa3/19lPU6t4qSp1pJeqb8ZK+Y0Da3kzKszawzvTVgmpw+UwR3yeV0AZhKKlFAo1ijg0Xweq6DtHIOm945t03ts=
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/NMY0DGWaRObCcpGYe1ZHUlTRVIE>
Subject: [stir] SIP PASSporT and Registrations
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 May 2017 18:25:45 -0000

  

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