[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