Re: [Sip] Re: RLS and identity

Adam Roach <adam@nostrum.com> Tue, 30 November 2004 19:29 UTC

Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23342 for <sip-web-archive@ietf.org>; Tue, 30 Nov 2004 14:29:22 -0500 (EST)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDls-0004qL-6A for sip-web-archive@ietf.org; Tue, 30 Nov 2004 14:34:44 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDTy-0006jQ-7A; Tue, 30 Nov 2004 14:16:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZDKn-0003dE-4n for sip@megatron.ietf.org; Tue, 30 Nov 2004 14:06:45 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21247 for <sip@ietf.org>; Tue, 30 Nov 2004 14:06:43 -0500 (EST)
Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CZDPx-0004Av-Ap for sip@ietf.org; Tue, 30 Nov 2004 14:12:05 -0500
Received: from [10.1.11.198] (inetgate.teknekron.com [192.138.162.245] (may be forged)) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id iAUJ6eWg028635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Nov 2004 13:06:42 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <41ACC4C0.8050907@nostrum.com>
Date: Tue, 30 Nov 2004 13:06:40 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Drage, Keith (Keith)" <drage@lucent.com>
Subject: Re: [Sip] Re: RLS and identity
References: <475FF955A05DD411980D00508B6D5FB00C290256@en0033exch001u.uk.lucent.com>
In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C290256@en0033exch001u.uk.lucent.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Content-Transfer-Encoding: 7bit
Cc: SIP WG <sip@ietf.org>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Content-Transfer-Encoding: 7bit

Drage, Keith (Keith) wrote:

>Adam is also making generalisations when he states "inherently insecure P-Asserted-Identity mechanism". Noone has made any justification of this statement. I accept that P-Asserted-Identity has a restricted applicability, in that it needs a trust domain, and needs to fulfil a number of criteria, as listed by the template at the back of RFC 3325, but that does not make it insecure. Any mechanism is insecure if you do not follow the rules.
>  
>

I consider any network that has security properties of "crunchy security 
shell with soft, easily compromised filling" to be inherently insecure 
-- a single compromise anywhere in the system can be used to exploit the 
entire system; in 3GPP, this weakness can even be exploited across 
domains. Any network architecture with such a design guarantees that the 
security of any node in the system is no better than the security of the 
least secure node in the system. For sufficiently large systems, this 
degenerates to the same properties as little or no security, since the 
probability of at least one node being compromisable goes up 
geometrically with the number of nodes in the system [1].

Since P-Asserted-Identity works only in the framework of such systems, 
and relies exclusively on the crunchy shell for protection, I consider 
it inherently insecure.

/a

[1] For example, if you have a system with 2,000 nodes, each
    of which has a 99.9% chance of having been designed and
    configured to have appropriate security properties, there
    is still an 86.5% chance that at least one of those nodes
    will be exploitable, meaning that there is an 86.5% chance
    that the entire system can be exploited.
    (99.9% ^ 2000 = 13.5%)

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip