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

[Hadriel Kaplan <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of Eric
> Rescorla
> Sent: Tuesday, February 26, 2008 7:37 PM
> To: [e-mail]
> Cc: [e-mail]
> 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 "[e-mail]" you encrypt
> to P("[e-mail]") 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 [e-mail] for questions on current sip
> Use [e-mail] 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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip