Re: [sipcore] SIP Federation, authentication and interoperability with WebRTC

Brian Rosen <br@brianrosen.net> Tue, 05 May 2020 12:46 UTC

Return-Path: <br@brianrosen.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 21DBE3A0404 for <sipcore@ietfa.amsl.com>; Tue, 5 May 2020 05:46:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
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 jWHZ5WKg0s3m for <sipcore@ietfa.amsl.com>; Tue, 5 May 2020 05:46:13 -0700 (PDT)
Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F5B3A0408 for <sipcore@ietf.org>; Tue, 5 May 2020 05:46:12 -0700 (PDT)
Received: by mail-qk1-x744.google.com with SMTP id k81so2061241qke.5 for <sipcore@ietf.org>; Tue, 05 May 2020 05:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3OPwnE7AHniDsYIKNM124UQRQ6vg2LJE0B3hRDSw6hU=; b=iaRDXnQYttVXPpAfats/1RfqqF40xKAKV3MA7ndmmAvnYjpKNm7iUgCUKe7A7GvuDX dnS2xrfAk/qqLCkUyu2lmXb7Fhh6K4Nf2ObtMRd96Ke7a7qNzhb+OF2gZ0ujGIztGNMX ri4U759wQZB/TMmQRJW1kmuQXCJd1YvkV/nGaXGlQO0UxQWPYqRiMGTKMDEdhApyVxay fTMsf5FF6/QW3Gu1hJkdxmvZfShxrdZ0dK+Wle/m9Rpxk7JAreoeh1vOD4JgZAmVXlgG iOt1/zotx2eja7kJGoM9epE4aohw0uvuydELJGNat+NqOOxvl06tybWj5uz04sbRK08P ocLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3OPwnE7AHniDsYIKNM124UQRQ6vg2LJE0B3hRDSw6hU=; b=Zw0ta8FmkvjRiY+mEy8fCXlpgwvtBNa4qHrNm2xarkeZYvmzF7rfmOUikVscRNukP+ VsIQtUGRX+qtnbwRNYG0kg/N9UV87n4+lwc3X+jDvuG5kM/ZIfaEtqrjf1MsPN3x0xh4 9wBsZuNMlz2Yhq5DMYfjklgY4bTeptEiKuXN2McFMHZe6n41A8TiwPQ4E1Ds8jyokiQf hUR3Qt1BGvWHXFdk2Yb9Tf2eWDYA2PnNCZ6Fr8hR6erwhJLZkcB02swtNz5JmQfKBXTL N6yHcNPtT84NIp48F21JcdkKWGgrPw/EqDPHooNF/R/Dup2vGfV30b+MhFHP752iNTj9 Ezbw==
X-Gm-Message-State: AGi0PuZSWTOqxnwOLQNWjZuTFvrlndkqbpHk2V0VUdGch8fEn+6k3GlR WqGPOdYENIr+fPB3unoK+404JQ==
X-Google-Smtp-Source: APiQypLFhbdUllYE8VNJDIC8xvQ00q6PYZJNI/7CFUkfcfRAPVrk5TZP50d6saqqzy9dGEtjNrs+4w==
X-Received: by 2002:a37:47c3:: with SMTP id u186mr3021936qka.117.1588682771731; Tue, 05 May 2020 05:46:11 -0700 (PDT)
Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id m7sm1712273qke.124.2020.05.05.05.46.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 05:46:11 -0700 (PDT)
From: Brian Rosen <br@brianrosen.net>
Message-Id: <75951579-9835-449A-BC2F-B3DEFCDC127C@brianrosen.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D86F974-107A-4BDA-B3E1-834A22488733"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Tue, 05 May 2020 08:46:07 -0400
In-Reply-To: <CANJ+WfdCPwkoBkn4KmncYduzn+XRtf8Bkae+LAoFxOLw3DfkLw@mail.gmail.com>
Cc: sipcore@ietf.org
To: Filippos Vasilakis <vasilakisfil@gmail.com>
References: <CANJ+WfdCPwkoBkn4KmncYduzn+XRtf8Bkae+LAoFxOLw3DfkLw@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/wwHZvoDsSYY_BWeTTY3KYDR90v8>
Subject: Re: [sipcore] SIP Federation, authentication and interoperability with WebRTC
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, 05 May 2020 12:46:16 -0000

This email list is for discussions of work in the IETF on core SIP, mostly extensions and bug fixes for SIP.  It’s not a general SIP discussion forum.  But, to answer your questions:

> On May 5, 2020, at 4:45 AM, Filippos Vasilakis <vasilakisfil@gmail.com> wrote:
> 
> Hello everyone,
> 
> I first sent this email to sip-implementers mailing list as I was pointed out by @sobomax and @oej, but that mailing list told me that the things I ask are more related to this group, so here I am.
> 
> I started looking into SIP over the past months because I find it quite interesting protocol. I have went through various RFCs and technical documents and I have some questions that might be naive, but due to lack of experience I need some guidance and clarifications. Also, I hope I am in the right place asking those questions.
> 
> 1) What's the status of SIP Federation? It seems like there is no official standard in there, but do we need it in order to achieve it ? The Secure Telephone Identity Revisited IETF group [0] has done some amazing work over the past years regarding SIP authentication (especially from the callee side). Is that enough for having secure SIP Federation, or are there missing pieces in the puzzle?
Depends on what you mean by “Federation”.  Reliable authentication <> federation but it’s a piece. As deployed, SIP either uses telephone numbers (or extensions) as identity, or SIP URIs within a domain.  Stir addresses authentication for telephone numbers.  It certainly can also be used to secure identity with other forms of SIP URIs.  What else do you think you need for federation?  Of course SIP is successfully used in IMS networks which power virtually all of the worldwide mobile networks, and it’s also used in most VoIP, cable and enterprise phone systems.  
> 
> 2) The WebRTC seems like it's taking a completely different road regarding federation [1]. There, it seems like the signaling protocol (which is not defined yet, but SIP is a major candidate), is used only for passing over the user identities, and then the actual federation checks take place inside the browser. I guess that's needed in case you don't trust the site you are sitting on, like a poker site, but still need to communicate with your friends, and verify that these are your friends, whose identity might belong to a completely different server/domain from yours and different from the poker site you are sitting on. Actually that scenario is explained by [1]. But still, that's quite different with SIP, so how is SIP interoperability is going to work with that? Has anyone give a thought? Feels super important to me that these 2 don't divert.
As deployed, virtually all WebRTC is within a single domain.  There just aren’t any large cross domain instances.  There is work in something called “IVC” that is trying to encourage cross domain video conferencing, which would use telephone numbers as identities, and thus can also use stir.  But there is no work on federation between WebRTC domains.  
> 
> 3) Olle Johannson, in a talk in Kamailio conference, said that SIP still hasn't solved the end-to-end encryption and integrity, mostly because, at some point the route might go through a non TLS connection. Well that's not an easy problem to solve, but I think that [0] has solved most of that (the integrity part), or am I wrong ? I mean, sure the SIP request might be come with the headers stripped off, but that's something that the callee SIP server shouldn't trust much. If it has the necessary headers though (the passport), then the caller should be who says it is. Of course the encryption is still remaining open, but is this solvable at all? Anyone working on that that ?
The end to end problem comes about because SIP signaling is hop by hop.  If you use TLS on every hop, that’s good but a) the endpoints don’t know if that happened or not, and (b) that isn’t end-to-end encryption.  There was early work that used S/MIME which would be end-to-end, but it was never implemented.  We aren't currently motivated to deal with that.

> 
> 4) How people do authentication mostly in SIP, when some kind of federation is needed? Is RFCs from [0] a common practice now? Is DANE (which from what I understand depends on DNSSEC) something that is used at all ? Something else ?
stir is being implemented widely in some places (the United States PSTN for example).  It’s being implemented to stop robocalling, but it’s also going to stop things like SWATing.  There isn’t much else going on.  No one I know uses DANE with SIP except accidentally, and while secure DNS is always desirable, it’s only a small part of authenticating sip.

> 
> I guess I fired too many questions, but I would love to get back some clarifications.
Those are mine.  You should probably drop sipcore from any reply you have to this.

Brian
sipcore co-chair
> 
> [0] https://datatracker.ietf.org/wg/stir/documents/ <https://datatracker.ietf.org/wg/stir/documents/>
> [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20>
> [2] https://www.youtube.com/watch?v=FO1N6gEjxUo <https://www.youtube.com/watch?v=FO1N6gEjxUo>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore