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

Jari Arkko <jari.arkko@piuha.net> Tue, 23 March 2010 01:28 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 250E83A6935 for <cga-ext@core3.amsl.com>; Mon, 22 Mar 2010 18:28:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.775
X-Spam-Level:
X-Spam-Status: No, score=0.775 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MIME_8BIT_HEADER=0.3]
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 megZPHLo+oUd for <cga-ext@core3.amsl.com>; Mon, 22 Mar 2010 18:28:08 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 26DCC3A691D for <cga-ext@ietf.org>; Mon, 22 Mar 2010 18:28:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C9B992CF42; Tue, 23 Mar 2010 03:28:23 +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 dAMfxQTKI8Wc; Tue, 23 Mar 2010 03:28:22 +0200 (EET)
Received: from [IPv6:::1] (unknown [IPv6:2001:14b8:400::130]) by p130.piuha.net (Postfix) with ESMTP id CDBC02CF3B; Tue, 23 Mar 2010 03:28:21 +0200 (EET)
Message-ID: <4BA81934.7050602@piuha.net>
Date: Mon, 22 Mar 2010 18:28:20 -0700
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
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> <4B210E23.4000908@piuha.net> <E4AAC190AE204187B5B8653E5FE614CC@bombo>
In-Reply-To: <E4AAC190AE204187B5B8653E5FE614CC@bombo>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-csi-proxy-send@tools.ietf.org, cga-ext@ietf.org
Subject: Re: [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: Tue, 23 Mar 2010 01:28:10 -0000

Alberto García kirjoitti:
> Hi Jari,
>
> The changes commented in the rest of the email refer to
> draft-ietf-csi-proxy-send-02.
>
> |  -----Mensaje original-----
> |  De: cga-ext-bounces@ietf.org [mailto:cga-ext-bounces@ietf.org] En nombre
> de
> |  Jari Arkko
> |  Enviado el: jueves, 10 de diciembre de 2009 16:05
> |  Para: draft-ietf-csi-proxy-send@tools.ietf.org; cga-ext@ietf.org
> |  Asunto: [CGA-EXT] Review of draft-ietf-csi-proxy-send
> |  
> |  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.
>
> We have changed this section to better address compatibility for all these
> cases. 
>   

Great!

> |  
> |  > 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.
>
> Agreed.
> We have removed this part, since (as you comment below), this is problem
> statement, and should be just in the problem statement document.
>   

OK.

> |  
> |  > 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.
>
> Yes, routers do not need to use CGAs, but need to be certified. We correct
> this part.
>   

OK

> Besides, there is an issue here regarding to RFC3971. From my understanding
> of what it is written in RFC3971, a router can act a proxy with the current
> specification. In the certificate allowing a router to operate as such, it
> is not clear that the 'subject' should be an IP address (moreover in the
> example of section 6.3.1, it is a FQDN), and it is not specified to check
> that the IP address of the subject is the same as the source address, etc.
> of the messages to validate with that public key. So I understand that the
> router could use its public key to sign messages coming from ANY address. 
>   

Since it is a router, presumably it is allowed to advertisize anything 
it wants in RAs, including that all prefixes are off-link. This would 
allow it work as a proxy.

> >From my point of view, this allows an attacker controlling the router to
> impersonate any other host, and doing this at the SEND security level. I
> think this should not be the default behavior, but if a proxy is required,
> this mode of operation should be authorized explicitly (as is proposed in
> the Certificate Profile and Secure Proxy ND).
>
> Assuming routers are not proxies, if the PMIPv6 is to be solved without
> Secure Proxy ND, each MAG should be configured with 1 certificate per
> possible link local address required by a MN. When using the Secure Proxy ND
> mechanism, only one certificate is required for this purpose, so the
> deployment is made easier. Therefore, the use of the proxy is just an
> optimization.
>
> Do you think this analysis is correct?
>   

I think so.

>
> |  
> |  > 4. Application Scenarios
> |  
> |  There seemed to be some duplication with respect to
> |  draft-ietf-csi-sndp-prob.
>
> Duplication has been removed (at least partially). Now 'Application
> scenarios' has moved after the specification of the mechanism, and now the
> approach is to show how the Secure Proxy ND is deployed for the application
> scenarios considered.
>   

OK, good.

> |  
> |  > 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.
>
> Well, I interpret that the sentence originally referred to the fact that
> when a node receives a message including the PSO option, this option makes
> the message to be 'as secure' as if a CGA option + RSA option is received.
> In any case, it has been removed.
> Your comment about the original message having security or not, I think it
> is now covered in the 'Compatibility' section. 
>   

OK.

> |  
> |  >       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.
>
> I follow up this topic in another email.
>   

...

> |  
> |  > 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.
>
> This is now discussed in the 'Compatibility' section. 
>   

Good.

> |  
> |  > 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.
>
> Not removing previous information is problematic. RFC3971 hosts (i.e. hosts
> not aware of this Secure Proxy ND specification) would process the packet
> with a RSA signature... to see that the message information (for example,
> the link layer address contained) has changed because of the proxy function,
> and the signature is not valid. The message would be discarded (instead of
> being considered as unsecure).
>   

OK. I understand that problem now.

> Secondly, not all proxied messages are translations of SEND messages, but in
> some cases (for example the MIPv6 and the PMIPv6 case) the ND messages are
> synthesized from the scratch by the proxy (without receiving a SEND message
> from the proxied host). So I assume the decision of whether a cache entry
> must be overridden or not must depend just on the proxy sending or not PSO
> options, requiring appropriate configuration in the proxy. More on this on
> the 'compatibility' section of the v02 of the draft.
>   

OK. I need to read it...

> What do you think? 
>
> |  
> |  > 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.
>
> Hope this has been clarified
>
> |  
> |  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.
>
> I think it should be clearer with the new structure of the document.
>   

Good. Thanks for the hard work on updating the draft.

Jari