[sipcore] SIP Federation, authentication and interoperability with WebRTC
Filippos Vasilakis <vasilakisfil@gmail.com> Tue, 05 May 2020 08:46 UTC
Return-Path: <vasilakisfil@gmail.com>
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 E01DD3A15D9 for <sipcore@ietfa.amsl.com>; Tue, 5 May 2020 01:46:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jm2ObtmVUiFB for <sipcore@ietfa.amsl.com>; Tue, 5 May 2020 01:46:11 -0700 (PDT)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 42F483A15DA for <sipcore@ietf.org>; Tue, 5 May 2020 01:46:11 -0700 (PDT)
Received: by mail-ot1-x331.google.com with SMTP id k110so1024204otc.2 for <sipcore@ietf.org>; Tue, 05 May 2020 01:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=XjSXbQv8ZXKQWUvcB5mFAPBIg/InFOkSp5b6spXKMCI=; b=n4e0FcrDvrry8Mo1+IOlv8IC1nUl62G52krzTRDdAjQFx+LVyBs5ynz8ZD8bJMRtwn KTAzkYyuaTdvI49NjlPBg884AC4EzqwMTAefQcpMl57VHO+H4Ue8gG1CMbEflcxj/gNr Ce/0lNDevlSuRmW9mSTY+DvlZobhejwz+9C/DCQhdmRM0lgn6EHw9Vdtl2NtoN9PRzFR sXacvgXEJIecuSQk3FK8tZ7wvF09RWeDoFF0rvu1YZS1hFrfBNYf/VcppMSlDc/GvKqy boTHYSoMmgsOfpvUYotSIc27Jgi/+jA2GVK+SIegHIPRyfpoGUEsTb0cyQoq/gJQN6f5 K7oA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=XjSXbQv8ZXKQWUvcB5mFAPBIg/InFOkSp5b6spXKMCI=; b=M4BTh/hz+o6oSk8xpiwZZ7FnQNa8d2AF+yhjmft8E3mY/HkQiNeOVtEmIP9e5YautE x/ePps1lL3FKl+SGbHneYBz8j7A6ZQDymIHi9QHM+ry/xGRD1mnmIWuqDTpeS6BJfAuR GOjqV20humqPa0VtXq5FRgHjzTk7gBOy0gGJQcy2lZrAn4rxGwb6sm7jJ6gkAU+/HwXQ drHnvXtT8aW2N5hLByqb+ujvQI1YGEraD7e37ftw0Z8azJudwmMoRiveOpz1ru0ERQ31 yy69LX05UYP8GU1NpwRqYzzGJGAO9Bh1LpvJ+pDxti4gvYpdIpeEz38DaMeHjQ8fsR+b /rhA==
X-Gm-Message-State: AGi0Pub9rff54AP7HZemAxxPE9yqEoiCZCpL1TZRGB6kG2nJKyRBuZVP AewNlBXMv/SiTNsY4cktKj3OEEyaP3Ee6HxHNGDLhWjLwbw=
X-Google-Smtp-Source: APiQypL3gZYicGzVFo+NTOn4xEJ4Wbjm7BY8XwvixBNDFbU02D1Z0FbuYJqneyEgUyd67LH0RoQ9l9nKQDqX8q4NJqM=
X-Received: by 2002:a05:6830:1dda:: with SMTP id a26mr1641581otj.29.1588668370207; Tue, 05 May 2020 01:46:10 -0700 (PDT)
MIME-Version: 1.0
From: Filippos Vasilakis <vasilakisfil@gmail.com>
Date: Tue, 05 May 2020 10:45:59 +0200
Message-ID: <CANJ+WfdCPwkoBkn4KmncYduzn+XRtf8Bkae+LAoFxOLw3DfkLw@mail.gmail.com>
To: sipcore@ietf.org
Content-Type: multipart/alternative; boundary="000000000000df487d05a4e2adf1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/_pzB1XRM0aa8sHMWlpb_U3PsFas>
Subject: [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 08:46:14 -0000
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? 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. 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 ? 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 ? I guess I fired too many questions, but I would love to get back some clarifications. [0] https://datatracker.ietf.org/wg/stir/documents/ [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 [2] https://www.youtube.com/watch?v=FO1N6gEjxUo
- [sipcore] SIP Federation, authentication and inte… Filippos Vasilakis
- Re: [sipcore] SIP Federation, authentication and … Olle E. Johansson
- Re: [sipcore] SIP Federation, authentication and … Brian Rosen