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

[Eric Rescorla <ekr at networkresonance.com>]

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