Re: [Sip] Review of draft-kupwade-sip-iba-00

Eric Rescorla <ekr@networkresonance.com> Wed, 27 February 2008 14:13 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 9CCE13A69D6; Wed, 27 Feb 2008 06:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.325
X-Spam-Level:
X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[AWL=0.112, 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 TOv7xGVg16kb; Wed, 27 Feb 2008 06:13:15 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235F63A6D84; Wed, 27 Feb 2008 06:13:09 -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 9167D28C31E for <sip@core3.amsl.com>; Wed, 27 Feb 2008 06:13:07 -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 5ps+YsvMtzUr for <sip@core3.amsl.com>; Wed, 27 Feb 2008 06:13:02 -0800 (PST)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id EF91F3A6D84 for <sip@ietf.org>; Wed, 27 Feb 2008 06:12:46 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 2C3025081A; Wed, 27 Feb 2008 06:14:31 -0800 (PST)
Date: Wed, 27 Feb 2008 06:14:31 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
In-Reply-To: <E6C2E8958BA59A4FB960963D475F7AC30BC778D633@mail.acmepacket.com>
References: <20080227003651.265505081A@romeo.rtfm.com> <E6C2E8958BA59A4FB960963D475F7AC30BC778D633@mail.acmepacket.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080227141431.2C3025081A@romeo.rtfm.com>
Cc: "sip@ietf.org" <sip@ietf.org>, "draft-kupwade-sip-iba@tools.ietf.org" <draft-kupwade-sip-iba@tools.ietf.org>
Subject: Re: [Sip] Review of 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

At Wed, 27 Feb 2008 01:47:23 -0500,
Hadriel Kaplan wrote:
> 
> Cool.  So if I understand this right (and I probably don't),
> ignoring rfc4474 identity and IBS for a moment and instead thinking
> about SRTP and IBE: I could use IBE to encrypt the
> security-descriptions attribute value using the intended target's
> SIP URI as a key, and only someone owning that URI (and sharing the
> same KG) or the KG itself could decrypt it to learn the sec-desc
> cleartext to use?

Yeah. This is how Voltage's email system works. (Seriously,
read the blog post I pointed at, whcih explains all this).
But of course this doesn't work correctly with a bunch of
retargeting scenarios. This is basically orthogonal to
MIKEY RSA mdoe, except that instead of doing certificate
retrieval you need to do parameter retrieval, and only
once for the domain.

Another sort-of-weird feature here is that you can encrypt to
someone who hasn't registered with the system, and then
they can register *afterward*. That works with email but
of course is too slow for VoIP.


> -hadriel p.s. the KG would actually be a problem for IBE, wouldn't
> it?  I mean the KG can always decrypt it. (at which point they would
> be the Key Generator Backdoor - aka, the KGB ;)

Yeah. This feature is generally referred to as "escrow" and is
one of the reasons why people don't want to have a single 
global KG.

-Ekr
_______________________________________________
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