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

[Dean Willis <[e-mail]>]

On Feb 28, 2008, at 2:14 PM, Michael Thomas wrote:

> Eric Rescorla wrote:
>> At Thu, 28 Feb 2008 12:46:21 -0600,
>> Dean Willis wrote:
>>
>>>
>>> A global or semi-global KG makes excellent sense in large domains,
>>> 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?

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


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

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?

>
>>
>>> And of
>>> course, IBE could provide for message privacy as well as integrity
>>> across the untrusted peers that will be serving as proxies.
>>>
>>
>> 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.
>>
>
> 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




_______________________________________________
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