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

Michael Thomas <mat@cisco.com> Thu, 28 February 2008 20:14 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C507A28C9CC; Thu, 28 Feb 2008 12:14:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.46
X-Spam-Level:
X-Spam-Status: No, score=-1.46 tagged_above=-999 required=5 tests=[AWL=-1.023, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5NM1EE2XGHbl; Thu, 28 Feb 2008 12:14:14 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBA3C3A6C2F; Thu, 28 Feb 2008 12:14:14 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30C653A69D8 for <sip@core3.amsl.com>; Thu, 28 Feb 2008 12:14:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5i70-t9nH+O for <sip@core3.amsl.com>; Thu, 28 Feb 2008 12:14:08 -0800 (PST)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 4F8843A68EE for <sip@ietf.org>; Thu, 28 Feb 2008 12:14:08 -0800 (PST)
Received: from sjc12-sbr-sw3-3f5.cisco.com (HELO imail.cisco.com) ([172.19.96.182]) by sj-iport-6.cisco.com with ESMTP; 28 Feb 2008 12:14:01 -0800
Received: from dhcp-171-71-97-210.cisco.com (dhcp-171-71-97-210.cisco.com [171.71.97.210]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id m1SK0Qgk028682; Thu, 28 Feb 2008 12:00:27 -0800
Message-ID: <47C7160A.9030606@cisco.com>
Date: Thu, 28 Feb 2008 12:14:02 -0800
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.9) Gecko/20071031 Thunderbird/2.0.0.9 Mnenhy/0.7.5.666
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <20080227170702.5A5C05081A@romeo.rtfm.com> <132324.81291.qm@web65509.mail.ac4.yahoo.com> <20080227171901.8EAE95081A@romeo.rtfm.com> <47C7017D.5020301@softarmor.com> <20080228191408.677435081A@romeo.rtfm.com>
In-Reply-To: <20080228191408.677435081A@romeo.rtfm.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3016; t=1204228827; x=1205092827; c=relaxed/simple; s=oregon; h=To:Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mat@cisco.com; z=From:=20Michael=20Thomas=20<mat@cisco.com> |Subject:=20Re=3A=20[Sip]=20comments=20on=20draft-kupwade-s ip-iba-00 |Sender:=20 |To:=20Eric=20Rescorla=20<ekr@networkresonance.com>; bh=QQ6ZAtLSnUSBFcAHt5F9QfvjJ12Jo+e4RXkzUiBj6lw=; b=nBkb/NdTagFoKR+IkjBR8X6fP9lbu9LHVB5+n8cPgQzWUqa5NRpGqQ37CD BBNaC3Hg1Zavv6RHKLs4O0uMj8x66eU7EBbNu90+EWlKccbCnjcqyjQSmIHb A0YN6I4J6p;
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( sig from cisco.com/oregon verified; );
Cc: sip@ietf.org, Dean Willis <dean.willis@softarmor.com>
Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

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

       Mike
> -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.
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org for new developments on the application of sip
>   

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip