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

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

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. 

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

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

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


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

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

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

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

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.

Regards,
Alberto
|  
|  Jari
|  
|  _______________________________________________
|  CGA-EXT mailing list
|  [e-mail]
|  https://www.ietf.org/mailman/listinfo/cga-ext