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 PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric > Rescorla > Sent: Tuesday, February 26, 2008 7:37 PM > To: sip@ietf.org > Cc: [EMAIL PROTECTED] > 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 "[EMAIL PROTECTED]" you encrypt > to P("[EMAIL PROTECTED]") 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 PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
