[stir] Comments on draft-stir-callback

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 14 March 2018 07:53 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id F389B126DFF for <stir@ietfa.amsl.com>; Wed, 14 Mar 2018 00:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.32
X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3YlO08v58eLt for <stir@ietfa.amsl.com>; Wed, 14 Mar 2018 00:53:22 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net []) (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 C95811200C5 for <stir@ietf.org>; Wed, 14 Mar 2018 00:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1521013999; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FLIewZGkW67bjsQ8Yo8iaZrdrI5vkPncRnRBwCv7Z7Y=; b=HW/A8hSvGFnjZLFku32Y5zCCPHFHxSYTa+jGGLd5jDgFfuSAi6eVJHV00s52cW4g SJ5L5/m+fqAEJ5Le866VnDxwFwkqcQfcHBH/MNGJveF9Ns3hsNUaXjiW4TEo6+VO mQnPqeFz7iHNDExfCCBzplgbsrPXngQ9U+GnMzqnzZU=;
X-AuditID: c1b4fb3a-347ff700000067b4-c4-5aa8d4ef8a44
Received: from ESESSHC008.ericsson.se (Unknown_Domain []) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.E4.26548.FE4D8AA5; Wed, 14 Mar 2018 08:53:19 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([]) by ESESSHC008.ericsson.se ([]) with mapi id 14.03.0382.000; Wed, 14 Mar 2018 08:53:18 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "stir@ietf.org" <stir@ietf.org>
Thread-Topic: Comments on draft-stir-callback
Thread-Index: AQHTtR6koGFWqP8WoE6Onck/KJHQHw==
Date: Wed, 14 Mar 2018 07:53:18 +0000
Message-ID: <D6C415C7.2C225%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D6C415C72C225christerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdS/f9lRVRBt8bDCyWr93G5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHerfjMV3J7GXLHi4xy2Bsabr5i6GDk5JARMJO6smsXcxcjF ISRwmFHi6trTjBDOEkaJaRP/snYxcnCwCVhIdP/TBmkQEVCW2LLuDjuILSygIdF1fAc7RFxX 4tKKyUwQtp7Ex523WUBsFgFViXdXprGC2LwC1hJ3Lt9jBLEZBcQkvp9aA1bPLCAucevJfKiD BCSW7DnPDGGLSrx8/A+sVxRo5oYTt9kh4ooS7U8bGCF6EyQWb94JNV9Q4uTMJywTGIVmIRk7 C0nZLCRlEHEDiffn5jND2NoSyxa+hrL1JTZ+OcsIYVtLtOxpYERWs4CRYxWjaHFqcXFuupGR XmpRZnJxcX6eXl5qySZGYLwc3PLbagfjweeOhxgFOBiVeHgbLq2IEmJNLCuuzD3EKMHBrCTC u1UGKMSbklhZlVqUH19UmpNafIhRmoNFSZzXKc0iSkggPbEkNTs1tSC1CCbLxMEp1cCYzbHn WP5xwzsTLkU1Wpb3xJRM//DYPf/rnaeme/eqn/2m2Hb/ibi3j/IznWDppK3sMd2b2Oq+vN57 6gD73Kd3GJ77cWt3T/joa7gl7ZH9necnlh18eb3Y8GEZ3/uVH/YmVVycVcx5IVgit+WudvvG j7vvW35Wn7F2w8K24tSs9l8nN4o1u4kdVWIpzkg01GIuKk4EAEcYFFOTAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/kNFzNh9PinGmIme7KETGTs9TM68>
Subject: [stir] Comments on draft-stir-callback
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, 14 Mar 2018 07:53:24 -0000


On a high-level, for a “temporary solution”, I think this would take quite a bit of effort to deploy. Shouldn’t the focus be on getting the "certificate systems" up and running?

Also, how does this relate to activities like SHAKEN?

Anyway, assuming this would be needed, I have some comments on the protocol parts.

First, even though I do consider myself more pragmatic than purist, I think usage of INVITE, and the usage of error response codes to return the verification result, is a really ugly hack.

Second, there are also some operational issues with using INVITE:

  1.  Good old forking: The callback/verifying INVITE might get forked, and the terminating agent may receive a non-471/472 response.
  2.  SDP: The draft requires SDP in the INVITE, but at the same time says that it’s not used for anything. If so, why is it mandated? Because offerless INVITEs might get rejected? SDP in INVITE might trigger media resources etc to be reserved.
  3.  Section 7.3 talks about attacks by the agent receiving the callback/verifying INVITE, but it does not cover the case where the agent would send a 200 OK response – which would establish a session and could trigger charging. Alternatively, the attacker could remove the option-tag and forward the request somewhere. All this without the originally called party knowing anything. The terminating agent can of course terminate such “call" as soon as it gets the 200 OK, but it may already have triggered some charging etc.

Third, did the authors consider other mechanisms? For example, is there a reason e.g., SUB/NOT couldn’t be used for this? It would have none of the INVITE issues above (yes, a SUB can also get forked, but the client will receive NOT from each remote peer).

Finally, it seems like the callback request (whatever SIP method is used) contains the called party in the From header field. Is there a technical reason why that is needed, or is it just for convenience?