[Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.txt
"James Kempf" <Kempf@docomolabs-usa.com> Wed, 24 August 2005 18:14 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zlL-0000JZ-OC; Wed, 24 Aug 2005 14:14:11 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7zlJ-0000JK-JV for mobopts@megatron.ietf.org; Wed, 24 Aug 2005 14:14:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09579 for <mobopts@irtf.org>; Wed, 24 Aug 2005 14:14:08 -0400 (EDT)
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E7zlg-00028o-74 for mobopts@irtf.org; Wed, 24 Aug 2005 14:14:32 -0400
Message-ID: <02a901c5a8d7$9aad97b0$196115ac@dcml.docomolabsusa.com>
From: James Kempf <Kempf@docomolabs-usa.com>
To: Jari Arkko <jari.arkko@kolumbus.fi>
References: <E1E7emX-00033A-MO@newodin.ietf.org> <430C5772.7090905@kolumbus.fi> <027501c5a8cf$e65abc90$196115ac@dcml.docomolabsusa.com> <430CB431.3010905@kolumbus.fi>
Date: Wed, 24 Aug 2005 11:14:01 -0700
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 2.4 (++)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Content-Transfer-Encoding: 7bit
Cc: mobopts@irtf.org
Subject: [Mobopts] Re: Comments on draft-kempf-mobopts-ringsig-ndproxy-02.txt
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Sender: mobopts-bounces@irtf.org
Errors-To: mobopts-bounces@irtf.org
> This is what RFC 3972 says: > > Note that the hash values are computed > over the entire CGA Parameters data structure, including any > unrecognized extension fields. > > Now, the field itself is underspecified although its usage in the > address calculation is clear (above). What we would probably need > to do is to specify first a TLV structure for the extensions, and > then one extension for the purposes of MCGA. But I don't > think we need to touch the calculation rules. > The draft has a specification for a generic TLV structure. I suppose it does no harm in including the TLV values into the calculation, but it is not the way most protocols I'm familiar with handle this. Typically, the semantically relevant fields are extracted and used, the identifying fields are discarded. But it does simplify the implementation, less parsing. > Btw, it seems that if the host's key is in the place where it > should be according to RFC 3972, the other keys are in > the extensions, you could easily use the RSA Signature, too, > as long as you are not currently proxying -- just sign with > the host's key. Of course you'd lose your privacy property. > But I thought I'd mention this because it may affect whether > you really want a new CGA type value or not. > You mean use an RSA signature that could have been generated by one of several key pairs rather than a ring signature? The location privacy aspect is lost as you say, but it is much more backward compatible with SEND. In effect, the ND options and basic address calculation would be covered by the existing RFCs, a new draft would only need to specify the CGA Parameters Extension and multi-key CGA generation. Since the address is constructed from multiple keys, I suppose no single key is designated as the owner, so an attribute cert delegating signing rights wouldn't be needed. Needs some thought, though, might be some subtle attack here. jak PS: BTW, we implemented the RST algorithm and the performance with two keys is about the same as RSA for signing and about twice as slow for verification. Signature size and performance scales with the number of keys, as expected. _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts
- [Mobopts] Comments on draft-kempf-mobopts-ringsig… Jari Arkko
- [Mobopts] Re: Comments on draft-kempf-mobopts-rin… James Kempf
- [Mobopts] Re: Comments on draft-kempf-mobopts-rin… Jari Arkko
- [Mobopts] Re: Comments on draft-kempf-mobopts-rin… James Kempf
- Re: [Mobopts] Re: Comments on draft-kempf-mobopts… Jari Arkko