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
- [Sip] RLS and identity Aki Niemi
- [Sip] Re: RLS and identity Adam Roach
- Re: [Sip] Re: RLS and identity Adam Roach
- RE: [Sip] Re: RLS and identity Milinski Alexander
- RE: [Sip] Re: RLS and identity Drage, Keith (Keith)
- Re: [Sip] Re: RLS and identity Adam Roach