[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 [127.0.0.1]) 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-Level:
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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcvTstY7i1yD; Tue, 26 Feb 2008 16:35:09 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) 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 [127.0.0.1]) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [74.95.2.173]) 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 [127.0.0.1]) 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 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 "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 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 sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip
- [Sip] Review of draft-kupwade-sip-iba-00 Eric Rescorla
- Re: [Sip] Review of draft-kupwade-sip-iba-00 Hadriel Kaplan
- Re: [Sip] Review of draft-kupwade-sip-iba-00 Eric Rescorla
- Re: [Sip] Review of draft-kupwade-sip-iba-00 Harsh Kupwade
- Re: [Sip] Review of draft-kupwade-sip-iba-00 Eric Rescorla
- Re: [Sip] Review of draft-kupwade-sip-iba-00 Dean Willis
- Re: [Sip] Review of draft-kupwade-sip-iba-00 Eric Rescorla