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

[Jari Arkko <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] En nombre
> de
> |  Jari Arkko
> |  Enviado el: jueves, 10 de diciembre de 2009 16:05
> |  Para: [e-mail]; [e-mail]
> |  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