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

[Dean Willis <[e-mail]>]

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

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

true.

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

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

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?



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

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:[e-mail]". 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:[e-mail];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
_______________________________________________
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