Re: [Sip] comments on draft-kupwade-sip-iba-00

[Eric Rescorla <ekr at networkresonance.com>]

At Tue, 26 Feb 2008 21:18:07 -0500,
Jonathan Rosenberg wrote:
> 
> Harsh, Dean,
> 
> Thanks much for this document. Its great to see folks trying to tackle 
> new areas of work, especially tough ones like identity.
> 
> The concept of identity based security is a new one to me; how mature is 
> this stuff?

Well, my pairing based cryptography expert friends tell me
that the algorithms in this draft are pretty far off the current
state of the art, which would be something from the Boneh-Boyen
family. BB is pretty well regarded.


> Are there any commercial uses yet? 

Yes:
www.voltage.com
www.identum.com

(full disclosure: I'm on Voltage's TAB).


> What about intellectual 
> property issues?

Yes, there are a number of patents in the field. I don't know about
these specific algorithms, but given that they post-date the
original Boneh-Franklin IBE patent, it wouldn't be surprising
if they were covered by patents. Dean?



> Has it been well-studied by experts to assess its 
> robustness? i.e., have folks been trying to crack it, and so far its 
> held up?

Yes, at least for the Boneh-Franklin and Boneh-Boyen stuff.
As with all modern algorithms, there are security reductions
to some assumed hard problem. HArd to know how much that
should comfort you.

> 
> I agree with Ekr that the primary advantage from a pure signature 
> perspective is the ability to eliminate the fetching of the certificate. 
> I think this is more beneficial than just 'compression'. Identity-Info 
> presents the certificate by reference. The increasing numbers of NAT and 
> firewalls and SBCs are making me increasingly worried that the ability 
> to reach across the network, back to the originator, and fetch ANYTHING 
> over http, will be really hard in SIP deployments. So there is value in 
> eliminating this IMHO.

Sure, but we could just shove the certificate into the message
in a new header or in the body, at which point we are talking
about compression. Moreover, there's no requirement that the
certificate be on the UAC's machine. If people care about this,
then it seems pretty likely that the CA can operate a site
which hosts your certificate for you. This is especially true
when we're talking about one certificate per domain as assumed
by RFC 4474.


> I must say I didn't understand how revocation works. From the 
> description of the algorithm it seemed untenable. The verifier never 
> needs to obtain a cert and the public key is generated statically from 
> the identity. Once they have the private key, the sender can always sign 
> with it, so I don't see how revocation is possible.

The way this is done is with what's effectively short-lived
identities (you could do the same thing with short-lived
certificates) you treat the time as part of the identity.
E.g., you might be "jdrosen at cisco.com:March-April, 2008". So,
the user needs to periodically refresh his private key to match
the new identity. If the key has been revoked you don't issue
new keys.

-Ekr


_______________________________________________
Sip mailing list  https://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