[sipcore] SIP client certs

"Olle E. Johansson" <oej@edvina.net> Tue, 24 November 2020 12:31 UTC

Return-Path: <oej@edvina.net>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79A153A0A00 for <sipcore@ietfa.amsl.com>; Tue, 24 Nov 2020 04:31:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 7VOnLuSR1-Ux for <sipcore@ietfa.amsl.com>; Tue, 24 Nov 2020 04:31:14 -0800 (PST)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (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 44A373A0A06 for <sipcore@ietf.org>; Tue, 24 Nov 2020 04:31:12 -0800 (PST)
Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 19E153291; Tue, 24 Nov 2020 13:31:09 +0100 (CET)
From: "Olle E. Johansson" <oej@edvina.net>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <DFD5CD1A-B55F-4239-8538-75BC09AC6122@edvina.net>
Date: Tue, 24 Nov 2020 13:31:08 +0100
Cc: Olle E Johansson <oej@edvina.net>
To: sipcore@ietf.org
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/MkttBrLqR2Ex6zPoq9RDe8cRCYg>
Subject: [sipcore] SIP client certs
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Nov 2020 12:31:17 -0000

Hi!
I hope everyone stays safe in these times.

During last week’s IETF I ended up in a discussion in RUM about using TLS client certs in SIP. I have been testing this a long time ago, but obviously not fully. The question I got I failed to find an answer to, which is annoying :-)

Here it goes, let’s see if you can help:

SIP UA -> Ingress proxy -> Registrar

If the Ingress Proxy requires a client cert for authentication, that certificate is only seen on the first hop between the UA and the proxy. How can we make the registrar validate and trust the client cert for the registration?

If there is absolute trust between the ingress proxy and the registrar, I guess we could parse out a lot of cert info and add to SIP headers and send forward. If there is no trust relationship (let’s say the Ingress Proxy is an enterprise SBC and the registrar is a service provider) then we have a problem.

In HTTP there’s a CONNECT method so the SIP UA can establish a direct TLS session to the registrar through a proxy. There is a very old expired draft for a SIP connect method that could potentially be helpful here.

I do remember that we had a SIP Connect draft many years ago.

Any ideas?

Cheers,
/Olle