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

Hadriel Kaplan <> Wed, 27 February 2008 06:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD5B028C526; Tue, 26 Feb 2008 22:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.106
X-Spam-Status: No, score=-0.106 tagged_above=-999 required=5 tests=[AWL=-0.269, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iC3KtNg0qjf4; Tue, 26 Feb 2008 22:49:36 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 0BEFF28C471; Tue, 26 Feb 2008 22:49:36 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 87E2928C437 for <>; Tue, 26 Feb 2008 22:49:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Nh1-q0+yTASm for <>; Tue, 26 Feb 2008 22:49:28 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D040928C421 for <>; Tue, 26 Feb 2008 22:49:27 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 27 Feb 2008 01:49:05 -0500
Received: from ([]) by ([]) with mapi; Wed, 27 Feb 2008 01:49:03 -0500
From: Hadriel Kaplan <>
To: Eric Rescorla <>, "" <>
Date: Wed, 27 Feb 2008 01:47:23 -0500
Thread-Topic: [Sip] Review of draft-kupwade-sip-iba-00
Thread-Index: Ach42JyGP7MVVjB3TiScFbtmqRpFigAM4NUw
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Sip] Review of draft-kupwade-sip-iba-00
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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?

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: [] On Behalf Of Eric
> Rescorla
> Sent: Tuesday, February 26, 2008 7:37 PM
> To:
> Cc:
> Subject: [Sip] Review of draft-kupwade-sip-iba-00
> $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 "" you encrypt
> to P("") 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
>   "" to one sub-KG and "" 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
> This list is for NEW development of the core SIP Protocol
> Use for questions on current sip
> Use for new developments on the application of sip
Sip mailing list
This list is for NEW development of the core SIP Protocol
Use for questions on current sip
Use for new developments on the application of sip