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

[Eric Rescorla <[e-mail]>]

At Thu, 28 Feb 2008 22:54:17 -0600,
Dean Willis wrote:
> >
> >   2.  Key discovery: Callers can generate the public key of the callee
> >       from the identity (SIP URI) of the callee and vice versa.  This
> >       eliminates a requirement for a key discovery mechanism using
> >       external sources, making deployment significantly easier.
> >
> > Or you can ship the key or cert in the signaling too.
> 
> yes, although those keys may be big (a problem for network resource  
> constrained environments), AND you have to ship them before they can  
> be used for encryption. For signing, I can send my cert along with a  
> signed message. But if I'm going to encrypt the message to you, I need  
> your public  key BEFORE sending the message.
> 
> Since the IB model generates public keys from SIP URIs, if I have  
> enough info on you to send you the message, then I also have enough to  
> encrypt it.

Yes, this is a clear advantage of IBE over PKI-based systems. But
as I said, it doesn't apply to IBS. Moreover, if there's any
kind of retargeting, then IBE has real problems.



> >   3.  Certificate validation: As a result caller or callee need not go
> >       through the complex path construction process to retrieve the
> >       public keys of a chain of CAs from the public key depositories
> >       which are controlled by the respective CAs.  This allows
> >       deployment in a peer-to-per modality without a need to route SIP
> >       messages through a centralized identity service or trust peer
> >       nodes to operate as identity services.
> >
> > What is the KG if not a centralized entity? I guess I don't
> > understand this part.
> 
> It's a centralized entity, but OUTSIDE of the signaling path.  
> Interaction with it is independent of interaction within the signaling  
> plane.
> 
> Consider, for example, a P2PSIP deployment that may initially  
> bootstrap in a connected environment. Everybody talks to their PKGs  
> and gets keyed up. Then a disaster occurs, people jump in their  
> response vehicles, and rush off to the impact zone where they form an  
> ad-hoc network. Their keys still work without further access to the PKG.
> 
> Contrast this to RFC 4474 identity servers, where each SIP request has  
> to go through a server, where a cryptographic process occurs. This is  
> a very load-sensitive centralized device without which the system  
> cannot function.

But this is *by design* because the original system for public key
end-to-end authentication, S/MIME which *did* use end-user
certificates, was determined to be impractical, because--wait for
it--end-entity enrollment was such a PITA. A situation which is
*exactly* the same for IB* systems.


> Sure, we could do something similar by having the "initial bootstrap"  
> include a CA process wherein everbody gets a cert. But now we need a  
> way of distributing the certs, either by broadcast or some sort of  
> query protocol. Why bother when an identity-based-encryption model  
> makes it so much easier?

Again, you're conflating encryption with data origin authentication.
Yes, this is an advantage of IBE, for encryption. It doesn't make it
any easier for signature however, as noted above.



> >   4.  Revocation: The ease of minting new identities and discovering
> >       keys allows short-lived identities, reducing the need for
> >       certificate revocation lists and the checking thereof.  This
> >       offers very large operational advantages in resource constrained
> >       environments.
> >
> > I don't understand why this is "easy". Enrollment is
> > "hard" unless there's something really new here. And
> > if I wanted a short-lived identity, I could just gin
> > up a new public key pair and use that as the identity
> > too. But I thought that the real problem was dealing with
> > long term identities like, oh say, [e-mail].
> >
> 
> Secondary enrollment, or at least minting a new identity, is  
> relatively easy, While the server load for crypto is comparable to  
> that of generating a cert, the amount of data on the wire is much  
> smaller.

Uh, sure. You authenticate to the CA/KG and it sends you your new
credential. In the case of the PKI, you get a new certificate, which
is definitely less than 1KB, but since it's almost exactly the same as
the old cert, what you really need is the new signature, so we can
compress that down to 320-1024 bits, depending on the signature
algorithm.

In the case of BB signatures, to take one instantiation, the private
key is 320 bits, so we're basically looking at a wash. Except,
of course, that you need to transmit the private key securely
whereas the certificate can be distributed over an insecure
protocol, so once you factor in the overhead of the SSL connection
(or S/MIME, or whatever) you use to distribute the private key,
things start to look a lot worse.

	

> Let's talk about conventional certificate revocation. There are ways  
> to make it better, but the basic model is that the CA builds a file of  
> every certificate it has ever revoked. It keeps this file forever  
> (theoretically, it could prune expired certs, but nobody does as they  
> keep getting used past their expiry), and keeps adding stuff to it.  
> Every time it adds something, it has to re-sign the file using the CA  
> cert. This file is called a "certificate revocation list", or CRL.
> 
> If a user of certs from that CA wants to see if a cert that has not  
> expired is still valid, it does a GET of the CRL. This might be a very  
> large file. Assuming, say, 1 million users, 100 bytes per cert (only a  
> part of the cert needs to be in the CRL), and a revocation rate of  
> just 10%, after a year the CRL is over a megabyte in size. Since stuff  
> constantly gets added, every time a user needs to check a cert it has  
> to download the whole thing (or it checks periodically, giving us  
> windows during which revoked certs will continue to be used).  Then  
> the user software does a liner search through the CRL every time it  
> wants to use a key.
> 
> This sucks, so we have things like OSCP to add validity-verification  
> protocols that add round-trip operations before every usage of a cert.  
> Gee, that's very helpful if your network is resource constrained or  
> partitioned. I happen to be following the IETF's "server migration"  
> test list, and I'll note that two weeks after cutover, we're still  
> reporting OSCP problems. It is non-trivial to get right. At the  
> moment, one of our Most Notable Persons is reporting that the OSCP  
> servers used by IETF aren't reachable from his digs in Australia,  
> meaning all accesses to IETF's secured web sites fail authentication  
> checks and pop up nasty errors after an unconscionable delay. This  
> would NOT be helpful to first-responders in a disaster zone, I assure  
> you.

Strangely, enough it happens, that I'm aware of all this, but the
situation is *no different* for Identity-based signature. The
way that IBS handles revocation is to make each identity short-lived
and force the user to periodically fetch a new private key.
This is *totally equivalent* to forcing the user to get a new
certificate instead. Yes, people do generally use CRLs, because
short-lived certs are actually a PITA, but PKI models can definitely
be operated the same way that an IBS system can.


Once again, all the advantages you're talking about are advantages of
IBE, not IBS. And yes, IBE indeed does have different operational
characteristics than PKI and these certainly may be an advantage in
some environments.  But that's not what this draft is abut. This draft
is about IBS. And as noted in my original review, the benefits of IBS
over conventional PKI in this setting are marginal at best.

So, if you want to propose a draft that uses IBE for SIP encryption
(and note that since there's are IBE for S/MIME drafts, this is simply
a matter of reprofiling the algorithm set) you'll get a totally
different reaction from me. But to keep talking about advantages
of IBE as if they apply to this draft completely confuses the
issue.

-Ekr

_______________________________________________
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