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

Eric Rescorla <ekr@networkresonance.com> Wed, 27 February 2008 00:35 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 []) by core3.amsl.com (Postfix) with ESMTP id B16A928C2EA; Tue, 26 Feb 2008 16:35:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.003
X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[AWL=-0.160, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, J_CHICKENPOX_16=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id AcvTstY7i1yD; Tue, 26 Feb 2008 16:35:09 -0800 (PST)
Received: from core3.amsl.com (localhost []) by core3.amsl.com (Postfix) with ESMTP id 798E43A697B; Tue, 26 Feb 2008 16:35:09 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id AD5823A68D3 for <sip@core3.amsl.com>; Tue, 26 Feb 2008 16:35:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id ornsj24SmexO for <sip@core3.amsl.com>; Tue, 26 Feb 2008 16:35:06 -0800 (PST)
Received: from romeo.rtfm.com (unknown []) by core3.amsl.com (Postfix) with ESMTP id CCC1F3A689E for <sip@ietf.org>; Tue, 26 Feb 2008 16:35:06 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com []) by romeo.rtfm.com (Postfix) with ESMTP id 265505081A; Tue, 26 Feb 2008 16:36:51 -0800 (PST)
Date: Tue, 26 Feb 2008 16:36:51 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: sip@ietf.org
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: <20080227003651.265505081A@romeo.rtfm.com>
Cc: draft-kupwade-sip-iba@tools.ietf.org
Subject: [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: <http://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: <http://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

$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
- 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 "alice@example.com" you encrypt
to P("alice@example.com") 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

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.

Sip mailing list  http://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