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

[Eric Rescorla <ekr at networkresonance.com>]

At Tue, 26 Feb 2008 23:55:22 -0600,
Dean Willis wrote:
> On Feb 26, 2008, at 11:41 PM, Eric Rescorla wrote:
> >> 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.
> 
> The real benefit is not just the elimination of cert-fetching, but the  
> reduction of effort for cert validation. The entire validation tree is  
> essentially encoded in the mathematics. If it works at all, the key  
> was "good" (which doesn't say anything about whether it has been  
> compromised and/or revoked).

I'm sorry, but this is just not convincing.

1. The computational cost to do the certificate validation is
   trivial.
2. You have to have the code in your system to do TLS anyway.
3. The "one big KG in the sky" scheme that you describe is
   not one that anyone I know in the IBE world thinks is
   plausible. In fact, if you look at Voltage's system
   (see draft-ietf-smime-ibearch), they use a system where
   each domain has their own KG and certificates are used
   to authenticate the KG (full disclosure: US Patent 7017181)

   
> There's also some benefit to using time-limited identities to reduce  
> the massive problem of CRL management.

Which is equally possible with certificates.


> Here's a novel thing:
> 
> Let's say I know your identity is sip:ekr at networkresonance.com, and  
> that your relationship with the PKG allows you to retrieve keys for  
> parameterized versions of that identity.
> 
> I can construct a new cryptographic identity for you, perhaps "sip:ekr at networkresonance.com;ID=2009121222 
> " and use that to sign a message to you. You've never seen this  
> identity before and don't yet even have the private key for it. You  
> then go to your PKG and retrieve said key and use it to verify the  
> message.

Yes, this is a commonly discussed in the IBE world, but it doesn't
work as well with store-and-forward signature systems because the
relying party has no opportunity to insist that you provide an
identity of his choice.

 
> I didn't need to check a CRL (or worry about known-text attacks, etc.)  

known-text attacks? What are you talking about?


> for your cert, because I in effect forced the creation of a new one.

And of course, this is equally compatible with cert-based systems.
The reason people don't do it is it's an enormous pain.


> >> 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.
> 
> Right, that's a variation of the technique I outlined above.
> 
> If one has a convention for encoding the duration into the identity,  
> then it can be made to work very smoothly.
> 
> --
> Dean
_______________________________________________
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