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

[Alberto García <[e-mail]>]

Hi,

Thanks for your comments. 
Just one topic to discuss:

|  -----Mensaje original-----
|  De: Jari Arkko [mailto:[e-mail]]
|  Enviado el: martes, 23 de marzo de 2010 2:28
|  Para: Alberto García
|  CC: [e-mail]; [e-mail]
|  Asunto: Re: [CGA-EXT] Review of draft-ietf-csi-proxy-send
|  

[...]
  
|  > |
|  > |  > 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

Well, actually I've changed my mind about this. 
First of all, I must say that the way routers sign ND messages is not
crystal clear in the SEND specification. 
As Julien pointed out in a previous email, RFC3971 states that the CGA
option MUST be present in all NS and NA. Then, I assume that routers must
have a CGA, and NS and NA must sign the NS and NA messages with the key
associated to the CGA. 
There are other places in the specification that suggest that routers should
use a CGA, for example: "By default, a SEND-enabled node SHOULD use only
CGAs for its own addresses." (RFC3971 section 7.1, addressing).

However, SEND specification present some 'holes' which could make the
previous assertions not to hold (at least, as I understand the text):
- A router could issue a NS or NA containing a CGA, but sign the message
with a different key (with the key authorized by a certificate derived from
a trust anchor). Note that the RSA option has a field in which a 'pointer'
to the key used, the Key Hash, is included. There is no rule stating that
the receiver should check that Key Hash of the RSA option should point to
the key of the CGA contained in the message (in fact, there is section 5.2.3
saying that the binding requirements between the RSA option and the type of
key used should be configurable per ND message type - unfortunately, it does
not set default values for this, which would be clarifying). However, I
interpret that the statement saying that the CGA must be present always
means that the key used should be the CGA, even for the router. This
behavior also allows the router using two different keys, one for signing RA
messages, and other for NA/NS (for example NUD), which prevents excessive
exposing of the certified key. 
- Communication on behalf of a proxied router (as in the PMIPv6 case) could
proceed without NS or NA exchange, since reachability (NUD) can rely on
hints from upper-layer protocols. The proxy (router) could issue a RA
message, with the address of the proxied router, signed with a key different
from a CGA but the key authorized by a valid certification path. This RA can
include the link-layer address of the proxy router. Then, upper-layer
information could maintain reachability, without requiring NS and NA
exchange. Since CGA is not required, in this scenario a router could perform
as a proxy for other router. Of course, I think this is much more a corner
case than a common situation; this is just to show that there are some cases
in which CGA would not be required.

Overall, I don't think we can assume that a router could behave as a proxy
on behalf of other addresses different than its own address, even in the
PMIPv6 case. 
Consequently to this, the text in 03 for the PMIPv6 case now presents it as
a solution, more than a way of making things easier.

What do you think?

Regards,
Alberto

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