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

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Feb 2008 16:36:51 -0800

$Id: draft-kupwade-sip-iba-00-rev.txt,v 1.1 2008/02/27 00:16:00 ekr Exp $

SIP has seen several attempts to use cryptographic signatures
to provide data origin authentication for SIP messages:

- RFC 3261 provided for S/MIME digital signatures by the
  end-user.
- RFC 4474 provided for "Identity" signatures by an 
  authentication proxy.

The RFC 3261 S/MIME scheme has seen almost no deployment.  This was
generally attributed to the difficulty of users obtaining
certificates. RFC 4474 was explicitly designed to avoid end-user
certs and is comparatively new so we don't know what kind
of deployment it will see.

This document describes an alternate mechanism using "Identity Based
Signatures". This is a little complicated to explain, but here's
the basic overview:

In a conventional asymmetric (public key) scheme, you
generate your own key pair, consisting of a public key and
a private key. Then when someone wants to encrypt to you,
they encrypt under your public key and you decrypt with
the private key. But how do people get your public key,
and how do they know it's yours? That's what certificates
are for. A certificate, of course, is a credential that
binds your name to your public key. But this is all kind of
inconvenient if you want to encrypt to someone who you've
never talked to before, because you need to get their certificate,
which brings up directory issues.

Identity-Based Encryption is a scheme that does without
the certificates. The idea is that you have two algorithms:

- P(string) which converts any string into a public key
- p(string, K) which converts any string into its corresponding
  private key.

K, of course, is a secret master parameter. So, instead of 
having a certificate authority you have a key generator (KG)
which knows K. KG's policy is only to issue private key
p(<name>, K) to the owner of <name> (this is the same
policy as the CA would have, of course). 

So, when you want to encrypt to "[email-masked]" you encrypt
to P("[email-masked]") secure in the knowledge that only
Alice could have gotten the private key. The nice thing about
this is that there is no need to have a certificate directory
because the public key is directly computable from the 
SIP URI. Where this seems useful is in settings where you
want to encrypt to people you have had no prior contact
with, like e-mail.
(more on this at
http://www.rtfm.com/movabletype/archives/2003_07.html#000315).

Unsurprisingly, IBE has a signature variant. In a conventional
public key system, when you want to sign a message you send
along [Message, Signature, Certificate]. The recipient extracts
your public key from the certificate and then verifies the
signature. In Identity Based Signatures (IBS), you can
do without the cert: the sender just send
[Message, Signature, Identity] since the receiver can compute
the public key directly from the Identity.

It shouldn't be hard to see that this is a lot less interesting
than IBE, since pretty much by definition the verifier is
reading a message from the signer and so the signer can
include a copy of (or a reference to) his certificate.
So, all this really does is provide a bit of message compression.

With all that in mind, this document describes how to use a
variant of Identity Based Signatures with SIP Identity.
Now, I've oversimplified a little bit, because there are
two other features it uses (neither of which are actually
that desirable).

- "Signcryption". When Alice sends a message to Bob, she
  can structure her signature so that only Bob can verify
  it. This pretty clearly interacts badly with retargeting.
- Hierarchical IBS. The system I described has only one
  key generator, but it's possible to use crypto to delegate
  authority so that there is a central KG which delegates
  "example.com" to one sub-KG and "example.org" to another.
  This doesn't make a lot of sense in an RFC4474 environment
  since there's only one key for any domain anyway.

The only thing that this document really does is allow you
to avoid having to have the trivial Web site RFC 4474 requires
you to have (or contract for) to stick your certificate on.
However, when you weigh that against the fact that the number
of CAs issuing identity-based signature keys currently stands
at 0, that seems to be a pretty marginal advantage.

-Ekr
  
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 27 Feb 2008 01:47:23 -0500

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?

-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 ;)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rescorla
> Sent: Tuesday, February 26, 2008 7:37 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Sip] Review of draft-kupwade-sip-iba-00
>
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2008 06:14:31 -0800

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

---

From: Harsh Kupwade <[email-masked]>
Date: Wed, 27 Feb 2008 07:43:08 -0800 (PST)

Key escrow problem has been tackled using B. Lee et. al’s algorithm.  They propose a single Private key generator who would perform the identity check and multiple KPAs (Key Privacy Authorities) who would distribute the partial private key. 
  Lee, B., Boyd, C., Dawson, E., Kim, K., Yang, J. and Yoo, S.,   "Secure Key Issuing in ID-based Cryptography," in Conferences in   Research and Practice in Information Technology, 2004, vol. 32, pp. 69-74.

Eric Rescorla <[email-masked]> wrote:  At Wed, 27 Feb 2008 01:47:23 -0500,

-Ekr

---------------------------------
Looking for last minute shopping deals?  Find them fast with Yahoo! Search.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2008 08:05:54 -0800

At Wed, 27 Feb 2008 07:43:08 -0800 (PST),
Harsh Kupwade wrote:
> 
> [1  <text/plain; iso-8859-1 (8bit)>]
> Key escrow problem has been tackled using B. Lee et. al’s
> algorithm.  They propose a single Private key generator who would
> perform the identity check and multiple KPAs (Key Privacy
> Authorities) who would distribute the partial private key.  Lee, B.,
> Boyd, C., Dawson, E., Kim, K., Yang, J. and Yoo, S., "Secure Key
> Issuing in ID-based Cryptography," in Conferences in Research and
> Practice in Information Technology, 2004, vol. 32, pp. 69-74.

I don't see how this really solves the problem. Obviously,
at a large cost you can have multiple KGs such that all of
them need to cheat in order to recover the message content,
but that doesn't really solve the problem. As the paper
you cite indicates, lawful intercept can be performed by
subpoenaing all the KGs.

Now, I'm not saying that escrow is necessarily bad, but
that just that this doesn't remove it.

-Ekr

> [2  <text/html; iso-8859-1 (8bit)>]
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 12:33:17 -0600

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.

> be the Key Generator Backdoor - aka, the KGB ;)

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

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2008 10:49:24 -0800

At Thu, 28 Feb 2008 12:33:17 -0600,
> 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

Citations, please?

-Ekr