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

Dean Willis <dean.willis@softarmor.com> Fri, 29 February 2008 05:09 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 F16C83A6AD5; Thu, 28 Feb 2008 21:09:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.587
X-Spam-Level:
X-Spam-Status: No, score=-0.587 tagged_above=-999 required=5 tests=[AWL=-0.150, 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 I-BXqbYDAHgc; Thu, 28 Feb 2008 21:09:07 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5356E3A6A3F; Thu, 28 Feb 2008 21:09:07 -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 DF4EA3A694D for <sip@core3.amsl.com>; Thu, 28 Feb 2008 21:09:06 -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 UtqcoN+xN6Uw for <sip@core3.amsl.com>; Thu, 28 Feb 2008 21:09:06 -0800 (PST)
Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E90883A6A3F for <sip@ietf.org>; Thu, 28 Feb 2008 21:09:05 -0800 (PST)
Received: from [192.168.2.100] (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 m1T58rGN022659 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 28 Feb 2008 23:08:55 -0600
Message-Id: <EF47515B-BE59-4128-A986-141AB41D01BD@softarmor.com>
From: Dean Willis <dean.willis@softarmor.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC30BC782D250@mail.acmepacket.com>
Mime-Version: 1.0 (Apple Message framework v919.2)
Date: Thu, 28 Feb 2008 23:08:48 -0600
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> <E6C2E8958BA59A4FB960963D475F7AC30BC782D250@mail.acmepacket.com>
X-Mailer: Apple Mail (2.919.2)
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

On Feb 28, 2008, at 9:26 PM, Hadriel Kaplan wrote:

>
>
>> -----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.

But if both the "CLINTON" and "OBAMA" groups were both subsidiaries of  
the "DEMOCRAT" group, hierarchical inheritance takes care of the  
problem.

You can also do some things using DNS or the like to figure out which  
"group" an identity is in if you can't deduce from the domain.

But where it really shines is in bounded user groups -- say, the set  
of participants in Skype, or people in the Department of Defense, or  
employees of Walmart, when the communication is WITHIN that group.

And if we're talking about something like a single P2PSIP overlay or  
confederation of overlays, then group closure is easy.

The larger the group and the more relatively frequent communications  
are within that group, the greater the efficiency gain from IB crypto.

--
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@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip