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

Eric Rescorla <ekr@networkresonance.com> Thu, 28 February 2008 18:50 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 A0B963A6ECE; Thu, 28 Feb 2008 10:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.347
X-Spam-Level:
X-Spam-Status: No, score=-0.347 tagged_above=-999 required=5 tests=[AWL=0.090, 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 cw1qZCtshm4A; Thu, 28 Feb 2008 10:50:22 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5F5228C8E0; Thu, 28 Feb 2008 10:49:53 -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 3E43328C919 for <sip@core3.amsl.com>; Thu, 28 Feb 2008 10:49:53 -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 CQV3N-m52zZO for <sip@core3.amsl.com>; Thu, 28 Feb 2008 10:49:47 -0800 (PST)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id B982828C9E4 for <sip@ietf.org>; Thu, 28 Feb 2008 10:47:39 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 7174A5081A; Thu, 28 Feb 2008 10:49:24 -0800 (PST)
Date: Thu, 28 Feb 2008 10:49:24 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Dean Willis <dean.willis@softarmor.com>
In-Reply-To: <47C6FE6D.1040504@softarmor.com>
References: <20080227003651.265505081A@romeo.rtfm.com> <E6C2E8958BA59A4FB960963D475F7AC30BC778D633@mail.acmepacket.com> <47C6FE6D.1040504@softarmor.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: <20080228184924.7174A5081A@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 Thu, 28 Feb 2008 12:33:17 -0600,
Dean Willis wrote:
> 
> 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?
> 
> Actually, there are partial-key models where the KG couldn't decrypt it
> either.
> 
> There are modes of operation that allow the full private key to be a
> product of a secret (retained by the user) and the output of the PKG.
> Hence you need to know both parts to decrypt or sign a message.

Not precisely.

1. There are schemes which have multiple KGs which all have to cooperate
   in order to recover the private key (that's what Harsh referred
   to the other day).
2. There are "forward secure" schemes (Gentry) in which the 
   KG forgets your private key and the ability to regenerate it.

However, both of these still have escrow as a sort of inherent property.

It's pretty easy to see that any true IBE scheme has to have escrow:

The fundamental IBE property is that any random person can encrypt
to any identity I knowing only the public system parameters P_pub,
and then for the KG to be able to provide the appropriate K_priv
from P_priv and I.

In order for this to work, you need to be able to compute:

- K_pub =    F1(P_pub, I)
- K_priv =   F2(P_priv, I)

If the user provides some information X that's not known to the KG
*and* X is required to decrypt, then it clearly must affect
K_pub, i.e.,

- K_pub = F1(P_pub, I, X)

But that violates the invariant that K_pub is deterministically
generated from I and P_pub--and it's precisely this invariant that
makes IBE interesting.

This doesn't apply to IBS, of course, since there's no requirement
that the verifier be able to independently compute K_pub. In
fact, one could argue under one definition that a PKI scheme is
an IBS scheme and that X is the user's public key and F1 is
certificate verification. But it's precusely because this invariant
isn't interesting in IBS that IBS doesn't add much value over
PKI.



> Yep. Early IB systems worked as you describe. But they don't HAVE to
> work that way.

Citations, please?

-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