[CGA-EXT] Review of draft-ietf-csi-proxy-send

Jari Arkko <jari.arkko@piuha.net> Thu, 10 December 2009 15:05 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59F3A3A683B for <cga-ext@core3.amsl.com>; Thu, 10 Dec 2009 07:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.544
X-Spam-Level:
X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599]
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 dnNaJip1vu-d for <cga-ext@core3.amsl.com>; Thu, 10 Dec 2009 07:05:22 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id BB6993A67EE for <cga-ext@ietf.org>; Thu, 10 Dec 2009 07:05:21 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 20B9DD4978; Thu, 10 Dec 2009 17:05:10 +0200 (EET)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HiCqLmojpjjK; Thu, 10 Dec 2009 17:05:09 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id 323CFD4930; Thu, 10 Dec 2009 17:05:09 +0200 (EET)
Message-ID: <4B210E23.4000908@piuha.net>
Date: Thu, 10 Dec 2009 17:05:07 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: draft-ietf-csi-proxy-send@tools.ietf.org, cga-ext@ietf.org
References: <alpine.LNX.2.00.0911191100150.7833@whitebox> <BF345F63074F8040B58C00A186FCA57F1C66087842@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911201144010.7546@whitebox> <BF345F63074F8040B58C00A186FCA57F1C65FB277D@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911211025090.11248@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2942@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911242317130.11124@localhost.localdomain> <BF345F63074F8040B58C00A186FCA57F1C65FB2A51@NALASEXMB04.na.qualcomm.com> <alpine.LNX.2.00.0911260951580.7596@whitebox> <37915D90-B246-48E4-9C7B-69DAF54FA43A@lacnic.net>
In-Reply-To: <37915D90-B246-48E4-9C7B-69DAF54FA43A@lacnic.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [CGA-EXT] Review of draft-ietf-csi-proxy-send
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2009 15:05:23 -0000

I have reviewed this draft.

In general, I'm quite happy with the approach it takes with respect to 
authorizing proxies with an explicit authorization certificate. I think 
it is a good and sufficient approach.

I do have a number of other technical issues, however. My biggest issue 
is that this specification could do a much better job with respect to 
backwards compatibility and mixed nd/send/proxy environments.

> It is not possible to apply the current SEND specification to protect
> the NA message issued by the HA. 

Strictly speaking this is not entirely correct. You only cannot support 
certain modes of operation. For instance, the virtual home link 
operation is trivially compatible with SEND. Also, since the home agent 
and the mobile node need to agree on a home address, the actual owner of 
the IP address (and corresponding private keys) could be either the home 
agent or the mobile node. Current SEND specifications do not support 
signatures for the same address coming from either the home agent or the 
mobile node. But it would be possible for the home agent to sign the NA 
messages, if it was the original owner of the home address. I'm not sure 
any of this has much practical significance, but I wanted to bring this 
up anyway, because the statements in the draft should be correct.

> The approach described above and the current SEND specification are
> incompatible since:
>
>   Sharing the same link-local address on different MAGs would
>   require all MAGs of a PMIPv6 domain to construct the CGA and the
>   RSA Signature option with the same public-private key pair, which
>   is not acceptable from a security point of view.
>   

AFAIK there is no requirement that routers construct CGAs.

> 4. Application Scenarios

There seemed to be some duplication with respect to 
draft-ietf-csi-sndp-prob.

> When any of these
> messages is received with a valid Proxy Signature option, it is
> considered as secure even if it doesn't contain a CGA option.
>   

I think there needs to be a difference with respect to whether the 
original message had a CGA option or not. The receiver on the other side 
needs to know this in order to decide whether to override an cache entry 
or not, in a manner similar to what RFC 3971 already does.

>       This field starts after the Key Hash field.  The length of the
>       Digital Signature field is determined by the length of the RSA
>       Signature option minus the length of the other fields (including
>       the variable length Pad field.)
>
>    Padding
>
>       This variable-length field contains padding, as many bytes long as
>       remain after the end of the signature.
>   

I don't understand how to calculate the length of the Signature field, 
because the padding field's length is not described anywhere.

> The modifications described in the following section applies when a
> SEND message contains the Proxy Signature option (PSO), i.e. the
> message was sent by a Secure Proxy ND.
>   

This does not seem like the only required modification. I would also 
like to see what a host on the other end should do if it has a cache 
entry that came from a PSO signed SEND message, and the host now 
receives a classic 4861 or 3971 message.

> When any of these
> messages is received with a valid Proxy Signature option, it is
> considered as secure even if it doesn't contain a CGA option.
>   
...
> A ICMPv6 message sent by a Secure Proxy ND for a proxied address MUST
> contain a Proxy Signature option (PSO) and MUST NOT contain CGA and
> RSA Signature options.
>   

I read the first statement as the CGA being optional, and now you are 
saying its a MUST NOT. Maybe the first statement needs to be made clearer.

Nevertheless, wouldn't it be good if the proxy didn't actually remove 
any information from the messages? First of all, its a little bit tricky 
to ensure that a proxy is capable of removing all SEND options that 
might be defined over time. Secondly, it seems like the wrong thing to 
do conceptually. You want to inform the other side that this message was 
proxied, but you may also want to know that the message was initially 
signed. This can be important, for instance, to decide whether to 
override a cache entry. I would not override a secure entry based on a 
securely proxied insecure message, for instance.

> 7. Backward Compatibility with legacy SEND nodes
The specification does not explain how a receiver treats different 
combinations of existing cache entries involving a ND, SEND, or proxy 
SEND source and a new message from a ND/SEND/proxy SEND source.

Finally, I'm not sure the draft does a good job of explaining which 
scenarios it covers from sndp-prob and which not. FWIW, I think this 
draft is all we need and we do NOT need to cover all possible scenarios 
from sndp-prob. But the readers would still like to understand the 
situation.

Jari