[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Signing P-Asserted-Identity
Dean Willis wrote:
I've been informed that despite what I incorrectly thought, transitive
signing doesn't require any modification to RFC 4474.
The 4474 spec requires that the subject of the cert used to sign
correspond to the domain of the From. This is different from requiring
that the common names match. So any SBC can re-sign anything at any
time and break nothing, at the expense of some crypto work.
So, let's say adam at nostrum.com calls mat at cisco.com. Nostrum's AS might
sign Adam's INVITE. Cisco's SBC might verify the signature, munge the
fields, mint itself a cert with a subject of "nostrum.com" (using its
well-known Nostrum CA key to sign thatFrom sip-bounces at ietf.org Wed Jul 16 12:35:37 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 596A13A6918;
Wed, 16 Jul 2008 12:35:37 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
by core3.amsl.com (Postfix) with ESMTP id 684F23A69A5
for <sip at core3.amsl.com>; Wed, 16 Jul 2008 12:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,
BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32])
by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id NsuV5OSOfKxn for <sip at core3.amsl.com>;
Wed, 16 Jul 2008 12:35:34 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164])
by core3.amsl.com (Postfix) with ESMTP id 8D81D3A6918
for <sip at ietf.org>; Wed, 16 Jul 2008 12:35:34 -0700 (PDT)
Received: from [192.168.2.101] (cpe-76-185-142-113.tx.res.rr.com
[76.185.142.113]) (authenticated bits=0)
by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
m6GJa26L030857
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
for <sip at ietf.org>; Wed, 16 Jul 2008 14:36:04 -0500
Message-ID: <487E4DA3.10001 at softarmor.com>
Date: Wed, 16 Jul 2008 14:36:03 -0500
From: Dean Willis <dean.willis at softarmor.com>
User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: SIP IETF <sip at ietf.org>
References: <E6C2E8958BA59A4FB960963D475F7AC30EEDF3C361 at mail.acmepacket.com> <029401c8e209$70e52e70$eaa36b80 at cisco.com> <48752F47.8060905 at nostrum.com> <048901c8e20d$1dddda70$eaa36b80 at cisco.com> <48753393.5090307 at nostrum.com> <48753605.5010604 at cisco.com> <487536D9.900 at nostrum.com> <48753B83.40205 at cisco.com> <5D1A7985295922448D5550C94DE291800210D663 at DEEXC1U01.de.lucent.com> <0D5F89FAC29E2C41B98A6A762007F5D0E3B735 at GBNTHT12009MSX.gb002.siemens.net> <4877812B.1090802 at nostrum.com> <48778FB9.4070206 at cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D0E3BC54 at GBNTHT12009MSX.gb002.siemens.net> <4877AAEA.5040906 at cisco.com> <4877ACE8.!
! 5060206 at nostrum.com> <E6C2E8958BA59A4FB960963D475F7AC30EEE09B636 at mail.acmepacket.com> <7BFB3CDA-4EFD-41C3-9CAB-210BE9BCF19F at softarmor.com> <E6C2E8958BA59A4FB960963D475F7AC30EEE09B652 at mail.acmepacket.com> <4AE4272D-1A8E-45D6-8649-84114C423CEB at softarmor.com>
<! 487BA4DA.2000909 at nostrum.com>
<A8E422CF-686B-4F08-B636-245D98477EAB at softarmor.com>
In-Reply-To: <A8E422CF-686B-4F08-B636-245D98477EAB at softarmor.com>
Subject: Re: [Sip] Signing P-Asserted-Identity
X-BeenThere: sip at ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
<mailto:sip-request at ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Dean Willis wrote:
I've been informed that despite what I incorrectly thought, transitive
signing doesn't require any modification to RFC 4474.
The 4474 spec requires that the subject of the cert used to sign
correspond to the domain of the From. This is different from requiring
that the common names match. So any SBC can re-sign anything at any
time and break nothing, at the expense of some crypto work.
So, let's say adam at nostrum.com calls mat at cisco.com. Nostrum's AS might
sign Adam's INVITE. Cisco's SBC might verify the signature, munge the
fields, mint itself a cert with a subject of "nostrum.com" (using its
well-known Nostrum CA key to sign that cert!) cert!) , and then sign the
request (replacing the Nostrum signature) using the new cert. Then
mat at cisco.com would verify Cisco's signature, and transitive trust is
created. Of course this doesn't say anything about why Michael should
trust that signature, although in this simplest case the rationale is
obvious. But for a 3rd service provider "in the middle", it is much
less obvious.
I've been informed that the above is also completely wrong. So I'm going
to shut up until I can beat the truth out of somebody.
And we wonder why implementors have trouble with our specs!
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
, and then sign the
request (replacing the Nostrum signature) using the new cert. Then
mat at cisco.com would verify Cisco's signature, and transitive trust is
created. Of course this doesn't say anything about why Michael should
trust that signature, although in this simplest case the rationale is
obvious. But for a 3rd service provider "in the middle", it is much
less obvious.
I've been informed that the above is also completely wrong. So I'm going
to shut up until I can beat the truth out of somebody.
And we wonder why implementors have trouble with our specs!
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip