[splices] draft-yusef-splices-invoke: Digest auth?

Adam Roach <adam@nostrum.com> Tue, 26 July 2011 17:54 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416721F8ACC for <splices@ietfa.amsl.com>; Tue, 26 Jul 2011 10:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.59
X-Spam-Level:
X-Spam-Status: No, score=-101.59 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRKCPGJakwbt for <splices@ietfa.amsl.com>; Tue, 26 Jul 2011 10:54:11 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id B847521F8AB8 for <splices@ietf.org>; Tue, 26 Jul 2011 10:54:10 -0700 (PDT)
Received: from dhcp-1418.meeting.ietf.org ([130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p6QHs7J8027280 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 26 Jul 2011 12:54:08 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4E2EFF3F.7020300@nostrum.com>
Date: Tue, 26 Jul 2011 13:54:07 -0400
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: draft-yusef-splices-invoke@tools.ietf.org, splices@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism)
Subject: [splices] draft-yusef-splices-invoke: Digest auth?
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 17:54:11 -0000

I'm not commenting on the larger issue of whether INVOKE is an 
appropriate means to accomplish what it intends in this email, as that's 
a far broader conversation.

However, one thing that jumped out at me in the current version of 
draft-yusef-splices-invoke is the following normative requirement:

    In most cases, the same user will be logged in to the different
    devices using the same credentials provided in the REGISTER requests.
    In this case, all INVOKE requests MUST be challenged using the digest
    authentication mechanism described by [RFC3261].

In practice, Digest was barely passable when we specified it in RFC 
3261, and we knew it. In the 15 years since we first did that, 
additional cracks have been made in the façade of MD5 that make Digest 
an even worse idea. The only real reason it's there is because there 
wasn't anything better available at the time. In fact, MD5-based Digest 
is so bad, you have protocols already deprecating it altogether (see RFC 
6331, for example).

At the same time, we do have additional means of authentication (mTLS, 
SIP Identity, and SIP Certs with S/MIME come to mind) that can be 
employed in certain architectures, and with far better security 
properties than Digest ever did (even back when MD5 was considered a 
good crypto algorithm). With any luck, one or more of these will become 
somewhat more widespread in the future.

So, if we *are* going to specify something in this area, I think that 
requiring Digest -- or, really, even suggesting it as a preferred 
mechanism -- are somewhat misguided. Yes, we need authentication for 
these types of operations. But Digest isn't a reasonable way to do it.

/a