Re: [Sip] comments on draft-kupwade-sip-iba-00

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 29 February 2008 03:27 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E318B3A6EE2; Thu, 28 Feb 2008 19:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.389
X-Spam-Level:
X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
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 rIy2uensCTqw; Thu, 28 Feb 2008 19:27:05 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0F9B3A6E88; Thu, 28 Feb 2008 19:27:04 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10583A6E01 for <sip@core3.amsl.com>; Thu, 28 Feb 2008 19:27:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 yLonVN7EejhI for <sip@core3.amsl.com>; Thu, 28 Feb 2008 19:27:03 -0800 (PST)
Received: from etmail.acmepacket.com (host6.216.41.24.conversent.net [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 091983A6C2C for <sip@ietf.org>; Thu, 28 Feb 2008 19:27:02 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.240.5; Thu, 28 Feb 2008 22:26:39 -0500
Received: from mail.acmepacket.com ([216.41.24.7]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Thu, 28 Feb 2008 22:26:39 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Eric Rescorla <ekr@networkresonance.com>, Dean Willis <dean.willis@softarmor.com>
Date: Thu, 28 Feb 2008 22:26:13 -0500
Thread-Topic: [Sip] comments on draft-kupwade-sip-iba-00
Thread-Index: Ach6Pg0Uj2oPtqKrTCOl6qxgkS+bCQAP+KuA
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC30BC782D250@mail.acmepacket.com>
References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <20080228191408.677435081A@romeo.rtfm.com>
In-Reply-To: <20080228191408.677435081A@romeo.rtfm.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "sip@ietf.org" <sip@ietf.org>
Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00
X-BeenThere: sip@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@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric
> Rescorla
> Sent: Thursday, February 28, 2008 2:14 PM
>
> > And of
> > course, IBE could provide for message privacy as well as integrity
> > across the untrusted peers that will be serving as proxies.
>
> And now we're talking about something totally different: IBE.
> I agree that IBE has significantly different characteristics from
> PKI. The problems with IBE in SIP are totally different: namely
> not knowing the actual identity of the recipietn of the message.
> This is the norm in both SIP (retargeting) and P2P (churn)
> systems.

Not to belabor this topic, but I don't think retargeting is an issue for SIP use of IBE, if by that you mean Alice sent a request to Bob and it got retargeted to Charles and thus Charles could not decrypt it.  It would be considered a feature to some folks.  It would take a second request to fix it, but that's only if retargeting occurs, and then the caller gets to decide if they want to do it to Charles.

The real killer for SIP usage of IBE is that Alice has no idea what KG group Bob is a member of a priori.  For example if Alice is a member of a KG group called "CLINTON", and Bob is a member of KG group "OBAMA".  Alice won't know ahead of time that Bob is a member of OBAMA.  Even if Alice had the OBAMA keying info at hand to use, she wouldn't know Bob is a member of it until she tries reaching Bob.  Since that would happen a lot, there's no serious advantage over conventional pub-key retrieval to encrypt, methinks.

-hadriel
_______________________________________________
Sip mailing list  https://www.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