[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Alternative SIP Identity Approach (was re: Thoughts on SIP Identity)
On Jul 31, 2008, at 2:14 PM, Adam Roach wrote:
On 7/31/08 1:49 PM, Dean Willis wrote:
Here's an example:
1) alice at example.com calls bob at example.net
2) The example.com AS authenticates Alice using a mechanism such as
proxy-authenticate, then adds an appropriate Identity and Identity-
Info header field.
3) Bob's B2BUA verifies the Identity header field
4) Bob's B2BUA checks the Identity value value against Bob's
whitelist and chooses to allow the call.
5) But Bob is out, so the B2BUA wants to forward the call to Bob's
mobile phone. But Bob's administrative policy requires recording
the call.
Since Bob's administrative policy requires recording the call,
Bob's b2bua steers the media through a recorder. This requires
either "editing the SDP" or termination of media on the SBC. in
either case, it is not reasonable to send the existing Identity
header on to Bob, since it's going to be broken.
6) Bob's B2BUA elides the previous Identity and Identity-Info and
adds a new Reasserted-Identity and Reasserted-Identity-Info header From sip-bounces at ietf.org Fri Aug 1 03:05:30 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 9DB413A6D6C;
Fri, 1 Aug 2008 03:05:30 -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 62DCE3A6B15
for <sip at core3.amsl.com>; Fri, 1 Aug 2008 03:05:29 -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=[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 QfoiQgeOfAnI for <sip at core3.amsl.com>;
Fri, 1 Aug 2008 03:05:27 -0700 (PDT)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164])
by core3.amsl.com (Postfix) with ESMTP id D10F23A6D6C
for <sip at ietf.org>; Fri, 1 Aug 2008 03:05:27 -0700 (PDT)
Received: from dwillis-mb1.meeting.ietf.org ([130.129.21.41])
(authenticated bits=0)
by nylon.softarmor.com (8.13.8/8.13.8/Debian-3) with ESMTP id
m71A5Ltg014903
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT);
Fri, 1 Aug 2008 05:05:23 -0500
Message-Id: <8151E805-AEF1-4889-8F71-EF33659661A6 at softarmor.com>
From: Dean Willis <dean.willis at softarmor.com>
To: Adam Roach <adam at nostrum.com>
In-Reply-To: <4891BAA4.7040305 at nostrum.com>
Mime-Version: 1.0 (Apple Message framework v928.1)
Date: Fri, 1 Aug 2008 11:05:15 +0100
References: <0D5F89FAC29E2C41B98A6A762007F5D0F266CD at GBNTHT12009MSX.gb002.siemens.net> <02829328-7B0E-41AB-B325-01246363D09C at cisco.com> <4DAE5E60BA49D8419D7C8832503F5FFC072817AF26 at EVS10.ams.gblxint.com> <FE11649F-C3C2-494F-8C40-569E83E91B80 at softarmor.com> <0D5F89FAC29E2C41B98A6A762007F5D0F26D3A at GBNTHT12009MSX.gb002.siemens.net> <4DAE5E60BA49D8419D7C8832503F5FFC072817B5A6 at EVS10.ams.gblxint.com>
<06BFFD03-B8FC-47FC-8659-43BF4B60A3B6 at softarmor.com>
<4891BAA4.7040305 at nostrum.com>
X-Mailer: Apple Mail (2.928.1)
Cc: SIP IETF <sip at ietf.org>, Adam Uzelac <Adam.Uzelac at globalcrossing.com>
Subject: Re: [Sip] Alternative SIP Identity Approach (was re: Thoughts on
SIP 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"; DelSp="yes"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
On Jul 31, 2008, at 2:14 PM, Adam Roach wrote:
On 7/31/08 1:49 PM, Dean Willis wrote:
Here's an example:
1) alice at example.com calls bob at example.net
2) The example.com AS authenticates Alice using a mechanism such as
proxy-authenticate, then adds an appropriate Identity and Identity-
Info header field.
3) Bob's B2BUA verifies the Identity header field
4) Bob's B2BUA checks the Identity value value against Bob's
whitelist and chooses to allow the call.
5) But Bob is out, so the B2BUA wants to forward the call to Bob's
mobile phone. But Bob's administrative policy requires recording
the call.
Since Bob's administrative policy requires recording the call,
Bob's b2bua steers the media through a recorder. This requires
either "editing the SDP" or termination of media on the SBC. in
either case, it is not reasonable to send the existing Identity
header on to Bob, since it's going to be broken.
6) Bob's B2BUA elides the previous Identity and Identity-Info and
adds a new Reasserted-Identity and Reasserted-Identity-Info header
fiel
field to the new request, adds a flag saying that the identity
being re-asserted was learned from a verified Identity header, then
sends it.
7) Bob's mobile sees the new request, knows that it trusts Bob's
B2BUA as a re-asserter, then checks its whitelist policy and finds
that it is willing to accept calls from alice at example.com as long
as the assertion strength is either a direct Identity or a re-
asserted Identity based on verified Identity.
Here's the problem... if I trust a B2BUA, it doesn't necessarily
mean that I'll trust everything it trusts. If Bob's UA is going to
make an informed choice, we need it to be able to examine a chain of
custody for the identity, at the very least.
Is the stack of "verified by" parameters in history-Info adequate, or
do you want to be able to check each transitive crypto operation?
If the latter, we'd have to do something like add each pre-edit
message as a sipfrag body onto the current message. That could make
for some rather large SIP requests. Maybe a diff format could make it
better, but it is still going to get chunky.
--
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
d to the new request, adds a flag saying that the identity
being re-asserted was learned from a verified Identity header, then
sends it.
7) Bob's mobile sees the new request, knows that it trusts Bob's
B2BUA as a re-asserter, then checks its whitelist policy and finds
that it is willing to accept calls from alice at example.com as long
as the assertion strength is either a direct Identity or a re-
asserted Identity based on verified Identity.
Here's the problem... if I trust a B2BUA, it doesn't necessarily
mean that I'll trust everything it trusts. If Bob's UA is going to
make an informed choice, we need it to be able to examine a chain of
custody for the identity, at the very least.
Is the stack of "verified by" parameters in history-Info adequate, or
do you want to be able to check each transitive crypto operation?
If the latter, we'd have to do something like add each pre-edit
message as a sipfrag body onto the current message. That could make
for some rather large SIP requests. Maybe a diff format could make it
better, but it is still going to get chunky.
--
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