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

[Dean Willis <[e-mail]>]

On Feb 29, 2008, at 12:32 AM, Eric Rescorla wrote:

> 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.
>

I see it as applying directly to IBS. Every message carries enough  
information (without the overhead of carrying a cert) for any  
recipient in the hierarchy to be able to validate a signature on that  
message. That's very useful in a P2P sort of world.

For example, if you're a peer making an admitting decision, you can  
validate a signature on an admission request without having to "get"  
the cert for that user from the DHT.

>
>
>>>  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.

But by examination, it's easy to solve for IB systems. You say the  
same solution can apply to cert-based systems.

Why doesn't anyone do it that way? There must be more to it -- maybe  
just a cognitive gap, but there MUST be some underlying reason or  
reasons.

Skype, for example, has the "feel" of an IB system as I describe it,  
even though it's really more conventional crypto underneath. But they  
don't pretend to be a CA.

>
>
>
>> 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.

As noted above, it DOES. Anybody who has an identity within the  
hierarchy can validate signatures on messages without needing to fetch  
a cert.

>
>
>
>
>>>  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.

Given that we have a two-layer model with permanent and temporary  
secrets, the permanent secret could be used to encrypt the temporary  
private key, making it work just like a protected cert.

But wait, there's more. There is math available that makes the thing  
that comes back from the PKG a "partial" key that then has to be  
combined with the secret held by the user to be useful. As such, the  
partial key isn't secret -- it can be transmitted in plain text.
>
--
Dean

_______________________________________________
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