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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Feb 2008 21:18:07 -0500

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? Are there any commercial uses yet? What about intellectual 
property issues? 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?

The document talks about encrypting the signature for the target but I 
don't see what security benefit this brings. Indeed, encrypting content 
in the signaling for an intended target has proven very problematic. 
Besides the (so-far) hugely hard cert problem, there is also the issue 
of retargeting. Also you have cases of multiple receiving devices - 
forking for example. Maybe Dean is just hoping it goes away, but how 
would this solution work there? Then there are things like shared lines, 
  contact centers, etc...

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.

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.

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Feb 2008 21:41:05 -0800

At Tue, 26 Feb 2008 21:18:07 -0500,
Jonathan Rosenberg wrote:
> 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 

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.

> over http, will be really hard in SIP deployments. So there is value in 

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.

> 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 "[email-masked]: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

---

From: Dean Willis <[email-masked]>
Date: Tue, 26 Feb 2008 23:55:22 -0600

> if they were covered by patents. Dean?

We expect to have IPR on some related material, but I don't believe it  
is required for the subject discussed in the draft.

There are rumors that Boneh's folks have a lot of IPR in the area.

...

> when we're talking about one certificate per domain as assumed

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

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

Here's a novel thing:

Let's say I know your identity is sip:[email-masked], 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:[email-masked];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.

I didn't need to check a CRL (or worry about known-text attacks, etc.)  
for your cert, because I in effect forced the creation of a new one.

> the new identity. If the key has been revoked you don't issue

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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Feb 2008 22:08:46 -0800

At Tue, 26 Feb 2008 23:55:22 -0600,
> 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)

> the massive problem of CRL management.

Which is equally possible with certificates.

> then go to your PKG and retrieve said key and use it to verify the  

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.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Feb 2008 22:12:36 -0800

At Tue, 26 Feb 2008 22:08:46 -0800,
> relying party has no opportunity to insist that you provide an

Oh, I should mention: what's the value of needing a new key to
*verify* the message? What does that do for the sender?
The relying party can simply assume the signature is valid.
If the sender wants to force the recipient to have a new 
key, they need to encipher the whole message or require
a signed receipt from the recipient.

-Ekr

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Feb 2008 10:02:21 -0600

>the new identity. If the key has been revoked you don't issue

naive question

what burden does this put on a peer (or all peers) to (conceivably) 
have to constantly discover JDR's public key, for example (because 
they don't know how long the private key is good for)?

Or is this problem known/expected or solved easily already?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2008 08:11:04 -0800

At Wed, 27 Feb 2008 10:02:21 -0600,
> Or is this problem known/expected or solved easily already?

Well, the feature of IBE schemes is that once you have the public
parameters for the KG, you can compute the public key without
fetching further data from the CA/KG. This is a lot more interesting
for encryption than it is for signature, since, as I said, you
can force the signer to just send you a new certificate, so the
retrieval cost is minimized.

-Ekr

---

From: Harsh Kupwade <[email-masked]>
Date: Wed, 27 Feb 2008 08:30:11 -0800 (PST)

Forcing a signer to send a certificate is fine, but if the signer’s root CA is not same as the receiver’s root CAs, then the receiver has to go through a complex path construction process which is not a trivial problem. 
  Diana Berbecaru, Antonio Lioy and Marius Marian “On the Complexity of Public-Key Certificate Validation”
   
  http://www.springerlink.com/content/1c77by87fcm34pp9/

Eric Rescorla <[email-masked]> wrote:  At Wed, 27 Feb 2008 10:02:21 -0600,

-Ekr

---------------------------------
Be a better friend, newshound, and know-it-all with Yahoo! Mobile.  Try it now.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2008 08:39:00 -0800

At Wed, 27 Feb 2008 08:30:11 -0800 (PST),
Harsh Kupwade wrote:
> Forcing a signer to send a certificate is fine, but if the
> signer’s root CA is not same as the receiver’s root CAs, then
> the receiver has to go through a complex path construction process
> which is not a trivial problem.

Huh? The entire Web security system operates on the principle that you
can verify certificates from random CAs. This has not turned out to be
a serious problem in practice.

Moreover, *exactly* the same problem exists wrt the KG in identity-based
systems.

-Ekr

---

From: Harsh Kupwade <[email-masked]>
Date: Wed, 27 Feb 2008 08:59:10 -0800 (PST)

How can we verify a certificate from a random CA? It will definitely be a serious threat in the near future. 
   
  Self signed certificates are not very reliable either. 

   A malicious KG is equivalent to a malicious CA. A malicious CA can also tag a public key to a different user and pose the same threat level. 

Eric Rescorla <[email-masked]> wrote:

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2008 09:07:01 -0800

At Wed, 27 Feb 2008 08:59:10 -0800 (PST),
Harsh Kupwade wrote:
> 
> [1  <text/plain; iso-8859-1 (8bit)>]

Uh, that the trust anchors are publicly known and compiled into
your client. 

>    A malicious KG is equivalent to a malicious CA. A malicious CA
>    can also tag a public key to a different user and pose the same
>    threat level.

Yes, a malicious CA is bad.
No, a malicious CA is not anywhere near as bad as a malicious KG.
A malicious CA has to mount MITM attacks on all your traffic
in order to decrypt. A malicious KG can passively decrypt.

Again, some people view escrow as a feature, but its simply
not true that the security properties of PKI-based systems
are the same as those IBE-based systems.

-Ekr

---

From: Harsh Kupwade <[email-masked]>
Date: Wed, 27 Feb 2008 09:14:26 -0800 (PST)

What if the trust anchors are not complied into your client? Then verifying a digital signature is not a trivial problem. 
   
  Cross certificate validation is a challenging issue?

Harsh Kupwade wrote:
> [1 ]

-Ekr

---------------------------------
Never miss a thing.   Make Yahoo your homepage.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 27 Feb 2008 09:19:01 -0800

At Wed, 27 Feb 2008 09:14:26 -0800 (PST),
Harsh Kupwade wrote:
> What if the trust anchors are not complied into your client? Then
> verifying a digital signature is not a trivial problem.
>

Which is why nobody does it in practice in the private sector.

In any case, I'm not sure why we're having this discusion since
all the same trust issues apply to IBE schemes. The only respect
in which they don't apply to IBE schemes is if you have a single
global KG, but of course you could have a single global CA,
too. It's just that nobody wants to do either.

-Ekr

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 27 Feb 2008 13:16:42 -0600

At 10:30 AM 2/27/2008, Harsh Kupwade wrote:
>Forcing a signer to send a certificate is fine, but if the signer's 
>root CA is not same as the receiver's root CAs, then the receiver 
>has to go through a complex path construction process which is not a 
>trivial problem.

I think this was what I was asking about... and it appears as if it 
might be a hindrance

><?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
>Diana Berbecaru, Antonio Lioy and Marius Marian "On the Complexity 
>of Public-Key Certificate Validation"
>
><http://www.springerlink.com/content/1c77by87fcm34pp9/>http://www.springerlink.com/content/1c77by87fcm34pp9/
>
>
>Be a better friend, newshound, and know-it-all with Yahoo! Mobile. 
><http://us.rd.yahoo.com/evt=51733/*http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ>Try 
>it now.

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 12:38:16 -0600

> Uh, that the trust anchors are publicly known and compiled into

Ok, so check out https://www.softarmor.com and tell me how it works out.

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 12:46:21 -0600

> too. It's just that nobody wants to do either.

A global or semi-global KG makes excellent sense in large domains,
especially where there are significant resource constraints.

Consider, for example, the 3GPP world of GSM phones. A KG hierarchy
rooted at the GSMA with each operator then having a subordinate KG could
make a lot of sense. We could get end-to-end security with significantly
fewer bits being transmitted than if users had to send copies of their
certificates along with every message.

Similar characteristics apply in peer-to-peer cases. The enrollment
process could include a KG interaction. The resulting identity could be
used with IBS for node identification in the overlay as well as message
source verification ("identity" in and RFC 4474 context). This helps
prevent a number of the easy attacks on P2P infrastructure. And of
course, IBE could provide for message privacy as well as integrity
across the untrusted peers that will be serving as proxies.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2008 11:06:41 -0800

At Thu, 28 Feb 2008 12:38:16 -0600,
> Ok, so check out https://www.softarmor.com and tell me how it works out.

What point are you trying to make? A certificate is a data format.
Obviously, it's possible to have a certificate signed by a trust
anchor that isn't commonly trusted. So what?

For the Nth time, this is equally possible with an identity-based
scheme.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2008 11:14:08 -0800

At Thu, 28 Feb 2008 12:46:21 -0600,
Dean Willis wrote:
> prevent a number of the easy attacks on P2P infrastructure.

Yes, and this is all equally possible with PKI systems. As I
said at the beginning, the only thing that IBS is bringing
to the party here is a smaller credential. As far as I'm
awre, the size of the cert is not the primary reason for lack
of adoption of any of these schemes 

Again, what does IBS bring to the party except compression? [0].

> And of

And now we're talking about something totally different: IBE.
I agree that IBE has significantly different characteristics from
PKI. The problems with IBE in SIP are totally different: namely
not knowing the actual identity of the recipietn of the message.
This is the norm in both SIP (retargeting) and P2P (churn)
systems.

-Ekr

[0] It's worth noting that the combination of using ECC and 
doing LZW on certificates would significantly shrink the
size of the cert. I haven't done the math, but I suspect down
to the point where it's not the dominant factor.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 28 Feb 2008 12:14:02 -0800

>> especially where there are significant resource constraints.

Are we talking about a trust anchor that isn't DNS and isn't shipped in
web browsers currently?
> Again, what does IBS bring to the party except compression? [0].

I just read through this too and I saw that in the abstract, and
also thought the size of credentials might be  "a problem" but isn't
"THE PROBLEM" with deployment.

Reading (quickly) through draft, I didn't get a sense for what
other problems this solves if any. I'll mention that in addition to
compression you can also use other methods to make key/name
bindings too which don't rely on krufty ASN.1 blobs to make
the point.
> This is the norm in both SIP (retargeting) and P2P (churn)

So there's no majick here seemingly. Darn.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 28 Feb 2008 13:01:46 -0800

Dean Willis wrote:
> [] The enrollment
> process could include a KG interaction. 

This to my mind is the _actual_ problem hindering deployment. Does
this scheme help that problem or just rearrange the deck chairs? Something
that posits yet another trust anchor would strike me as the latter.

 From the conclusion:

  The advantages with the proposed methods are:

   1.  Key size: Elliptic-curve cryptography arguably provides
       equivalent security with smaller operands than the RSA technique
       typically used with [7 <http://tools.ietf.org/html/draft-kupwade-sip-iba-00#ref-7>].  This provides some advantage for
       resource-constrained environments such as mobile telephones.  It
       also reduces the cryptographic load on large-scale devices doing
       frequent authentication checks.

You can do this with PKI or key-centric schemes too.

   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.

   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.

   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, [email-masked].

		Mike

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 28 Feb 2008 22:26:13 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Eric
> Rescorla
> Sent: Thursday, February 28, 2008 2:14 PM
>
> > And of

Not to belabor this topic, but I don't think retargeting is an issue for SIP use of IBE, if by that you mean Alice sent a request to Bob and it got retargeted to Charles and thus Charles could not decrypt it.  It would be considered a feature to some folks.  It would take a second request to fix it, but that's only if retargeting occurs, and then the caller gets to decide if they want to do it to Charles.

The real killer for SIP usage of IBE is that Alice has no idea what KG group Bob is a member of a priori.  For example if Alice is a member of a KG group called "CLINTON", and Bob is a member of KG group "OBAMA".  Alice won't know ahead of time that Bob is a member of OBAMA.  Even if Alice had the OBAMA keying info at hand to use, she wouldn't know Bob is a member of it until she tries reaching Bob.  Since that would happen a lot, there's no serious advantage over conventional pub-key retrieval to encrypt, methinks.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 22:20:01 -0600

> Are we talking about a trust anchor that isn't DNS and isn't shipped  

Yes. It would be a trust anchor that would be bound on enrollment in  
the domain, such as when signing up to use a P2p service, or buying a  
mobile phone SIM. One could perhaps bootstrap it from DNS, perhaps  
using a conventional cert as a trust anchor for the process.

Here's a possible sequence: browse to https://p2psip.example.com.  
Complete an enrollment form. Receive a SIP URI and a private key.

Later on, launch your P2PSIP client and connect to the overlay. Sign  
the PUT request for your registration using your private key.  The  
peer you;re talking to can check the signature and validate your  
identity without having to retrieve your public key

> bindings too which don't rely on krufty ASN.1 blobs to make

True.

There are a lot of other problems with "deployment" that crop up. Many  
are of "perfect is the enemy of good enough". Nobody really wants to  
"run a CA", what with all the dire warnings about the responsibility  
and all the key management issues, and questions about what those  
certs are going to be used for, and so on. But nobody seems to be all  
that averse to running a password database for authentication.

We could easily envision a simple web-service API for PKG services  
that bootstraps off a secured HTML page and a password database, and  
use that to launch a production system that would be considered "very  
deployable" and easy to operate.

We could probably also do the same sort of thing with a CA instead of  
a PKG. It SEEMS easy enough. But nobody does it. Why?

> So there's no majick here seemingly. Darn.

Actually, there's no reason you can't know the identity of the  
recipient of a message. You may not know it in advance of them  
actually receiving the message, but given that they have a key that's  
meaningful to you, they can sign a response to the message. They could  
potentially even sign a response to a message that they couldn't  
actually understand fully -- all they need to know is enough to get  
the response back to you, along with a copy of the message.

We've considered "response identity" a hard problem in SIP. There are  
a couple of reasons:

1) We assume SIP UAs do not have keys that are meaningful to each  
other, due to the difficulty of solving "the CA problem", so end-user  
verification is not available.

2) We assume servers rely on HTTP digest authentication to establish  
an identity relationship. Since digest authentication applies only to  
requests and not responses, identity services only work on requests.  
Of course, draft-ietf-sip-outbound makes it feasible for an identity  
server to be colocated with the "outbound proxy", thereby giving it  
the option of a persistent TLS connection to the UA from which  
identity could reasonably be inserted in responses. But we haven't  
internalized this yet (and "outbound" remains hung up in the process).  
So John Elwell's draft relies on the authentication of messages in the  
opposing direction, giving us "connected identity" instead of  
"response identity". This only works in a subset of cases.

3) We have the unanticipated respondent problem. Somebody on the path  
can retarget requests to somebody with whom you have no prior  
relationship, making any authentication of the recipient a dicey  
proposition. Of course, in an IB-system, everybody has some prior  
relationship (via whatever top-level KG roots the hierarchy), so you  
can validate an identity assertion on any response from within that  
hierarchy. We still don't have a way to know whether such a  response  
is reasonable or not (although IB does allow for some interesting  
possibilities towards solving this too).

So yeah, if you're willing to accept the constrains of an IB model  
(namely, some variation on single-root), then there is majick.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 22:54:17 -0600

On Feb 28, 2008, at 3:01 PM, Michael Thomas wrote:

>       typically used with [7 <http://tools.ietf.org/html/draft-kupwade-sip-iba-00#ref-7 
> >].  This provides some advantage for

true.

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

> What is the KG if not a centralized entity? I guess I don't

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.

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?

> long term identities like, oh say, [email-masked].

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.

What we have in effect is a two-tier model with "permanent" and  
"temporary" keysets or secrets. Initial enrollment gets you the  
"permanent" keyset. This is then used to generate "secondary" keysets  
on an as-needed basis. One can easily model a single-request API for  
generating the secondaries.

Here, the "permanent" keyset is known only to the user and the PKG.  
The "secondaries" are the identities that are used by everybody else.

So for example, take "sip:[email-masked]". You'd probably never be  
contacted using precisely this identity. Instead, we'd use some sort  
of well-known convention to parameterize this identity. For example,  
we might use a time-based convention to delimit the identity to the  
current month: "sip:[email-masked];valid=200802". A monthly validity  
period is roughly equivalent to using certs that expire after 30 days  
-- but the important point is that your correspondents wouldn't need  
to get a new cert for you next month. Instead, knowing the convention,  
they'd just change the identity they use when sending you SIP  
messages. It's even possible to "stock up" on identities in advance --  
for example, generate your 200802 keyset, your 200803 keyset, and so  
on in advance, then just use the right one when you need it.

The important thing is that when somebody knows your base URL, the  
conventions of your domain, and the fixed identity-to-key transform  
algorithm (basically some kind of hash), they can generate your  
current working public key WITHOUT having to talk to some kind of  
centralized server.

While expiry is not a general answer to certificate revocation, it  
does help by making the CRLs very short, and in some cases by  
completely eliminating a requirement for revocation.

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.

--
Dean

Time-constrained

---

From: Dean Willis <[email-masked]>
Date: Thu, 28 Feb 2008 23:08:48 -0600

On Feb 28, 2008, at 9:26 PM, Hadriel Kaplan wrote:

> Not to belabor this topic, but I don't think retargeting is an issue  
> for SIP use of IBE, if by that you mean Alice sent a request to Bob  
> and it got retargeted to Charles and thus Charles could not decrypt  
> it.  It would be considered a feature to some folks.  It would take  
> a second request to fix it, but that's only if retargeting occurs,  
> and then the caller gets to decide if they want to do it to Charles.
>
> The real killer for SIP usage of IBE is that Alice has no idea what  
> KG group Bob is a member of a priori.  For example if Alice is a  
> member of a KG group called "CLINTON", and Bob is a member of KG  
> group "OBAMA".  Alice won't know ahead of time that Bob is a member  
> of OBAMA.  Even if Alice had the OBAMA keying info at hand to use,  
> she wouldn't know Bob is a member of it until she tries reaching  
> Bob.  Since that would happen a lot, there's no serious advantage  
> over conventional pub-key retrieval to encrypt, methinks.

But if both the "CLINTON" and "OBAMA" groups were both subsidiaries of  
the "DEMOCRAT" group, hierarchical inheritance takes care of the  
problem.

You can also do some things using DNS or the like to figure out which  
"group" an identity is in if you can't deduce from the domain.

But where it really shines is in bounded user groups -- say, the set  
of participants in Skype, or people in the Department of Defense, or  
employees of Walmart, when the communication is WITHIN that group.

And if we're talking about something like a single P2PSIP overlay or  
confederation of overlays, then group closure is easy.

The larger the group and the more relatively frequent communications  
are within that group, the greater the efficiency gain from IB crypto.

--
Dean

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Feb 2008 22:32:14 -0800

At Thu, 28 Feb 2008 22:54:17 -0600,
> enough info on you to send you the message, then I also have enough to  

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.

> a very load-sensitive centralized device without which the system  

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.

> query protocol. Why bother when an identity-based-encryption model  

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.

> that of generating a cert, the amount of data on the wire is much  

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.

> would NOT be helpful to first-responders in a disaster zone, I assure  

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 29 Feb 2008 12:14:50 -0600

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

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

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

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Feb 2008 10:26:45 -0800

At Fri, 29 Feb 2008 12:14:50 -0600,
> message. That's very useful in a P2P sort of world.

We're going around in circles. The only overhead here of carrying
the cert is the certificate data itself. In other words, this is a
fancy form of certificate compression, just as I said at the 
beginning.

I've deleted the rest of your message since it primarily goes over
the same ground.

-Ekr