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

[Eric Rescorla <ekr at networkresonance.com>]

$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 at example.com" you encrypt
to P("alice at 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 at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip