Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04

[Roque Gagliano <[e-mail]>]

Hi Alberto,

Please see inline.

Roque.

On Jul 7, 2010, at 2:39 PM, Alberto García wrote:

> Hi Roque, 
> Thanks for your fast answer.
> 
> |  -----Mensaje original-----
> |  De: Roque Gagliano [mailto:[e-mail]]
> |  Enviado el: miércoles, 07 de julio de 2010 11:12
> |  Para: Alberto García
> |  CC: 'Sandra Murphy'; [e-mail]; [e-mail];
> draft-ietf-csi-proxy-
> |  [e-mail]; [e-mail]; csi-
> |  [e-mail]
> |  Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04
> |  
> |  Hi Alberto,
> |  
> |  > In draft-ietf-csi-send-cert-05, section 7 (it is the same text as in
> cert-04) it
> |  discusses the messages that are authorized by each KeyPurposeId
> |  >
> |  > - "router authorization value indicates that the
> |  >    certificate has been issued for allowing the router to advertise
> |  >    prefix(es)"
> |  >
> |  >
> |  What about the following text?
> |  
> |  "router authorization value indicates that the
> |     certificate has been issued for allowing the router to generate RA
> messages for
> |  the
> |     prefix(es)  that are mentioned in the X.509 extensions for IP
> addresses""
> 
> Yes, although I would also include Redirect messages, since the 'router
> function' pack is RA+Redirect
> 

ok.

> |  
> |  
> |  > (I understand that implicitly states that it authorizes the generation
> of RA
> |  messages. It is not crystal clear for me if it authorizes NA for routers,
> although if
> |  I had to take this text literally, I would suppose routers would need an
> 'owner'
> |  authorization if this PKI model substitutes RFC3971 CGA authorization,
> |  considering that the prefix for NA would be narrowed in general to one
> address,
> |  while the RA authorization is prefix-wide)
> |  >
> |  > - "proxy authorization value indicates that the
> |  >    certificate has been issued for allowing the proxy to perform
> |  >    proxying of neighbor discovery messages for the prefix(es) that are
> |  >
> |  >    mentioned using the X.509 extensions for IP addresses"
> |  >
> |  > (I understand it now implicitly states it authorizes for ANY neighbor
> discovery
> |  message. By the way, this is the assumption underlying in general
> draft-ietf-csi-
> |  proxy-send-04: in the application scenarios, some require RA proxying,
> which is
> |  assumed to be performed by means of the proxy cert)
> |  >
> |  >
> |  What about the following text?
> |  
> |  - "proxy authorization value indicates that the
> |     certificate has been issued for allowing the proxy to perform
> |     proxying of RA messages for the prefix(es) that are
> |     mentioned in the X.509 extensions for IP addresses"
> 
> Yes, also including Redirect. 

ok.

> 
> |  
> |  
> |  > - "owner authorization [...]For an
> |  >    address in such certificate the host can assign the address, send/
> |  >    receive traffic from this address, and can respond to NSes about
> that
> |  >    address"
> |  >
> |  > (this is the clearest of all statements - although I think issuing
> secured NS and
> |  RS should also be considered)
> |  >
> |  What about the following text?
> |  
> |  - "owner authorization [...]For an
> |     address in such certificate the host can assign the address, send/
> |     receive traffic from this address, and can respond to ND messages
> about that
> |     address"
> 
> Ummm. I think this is more than 'respond', since it also authorizes the node
> to sign RS and NS. I would detail the messages that are covered by this
> authorization: NS, NA, RS.
> What do you think?
> 
>  - "owner authorization [...]For an
> |     address in such certificate the host can assign the address, send/
> |     receive traffic from this address, and can send NS, NA and RS messages
> about that     address"


ok, but lets keep the respond in the sentence:
 - "owner authorization [...]For an address in such certificate the host can assign the address, send/receive traffic from this address, and can send or respond NS, NA and RS messages about that     address"

> |  
> |  > So, as defined now in draft-ietf-csi-proxy-send-04, proxy certificates
> provide
> |  authorization for securing *any* ND message. Considering the application
> |  scenarios, some require proxying RA (PMIPv6 and RFC4389), and the MIPv6
> |  scenario just require NS/NA proxying.
> |  >
> |  > In summary so far, there is some specification of the authorization in
> draft-csi-
> |  send-cert, which I think it would be nice that it could be refined, and
> if so, my
> |  opinion is that the refinement of which ND message is authorized by each
> |  KeyPurposeId should be in that document.
> |  >
> |  > However, continuing with this issue, I must say that the way the 'proxy
> |  authorization' is defined, and the relationship with the other cases, is
> not
> |  satisfactory for me.
> |  >
> |  > I think the use of 'owner' should be restricted for hosts that really
> own the
> |  address (therefore, a substitution of the CGA mechanism) - as opposed to
> proxies.
> |  >
> |  > For the 'proxy authorization', I think it could be refined into
> something like
> |  "proxy host" authorization, and "proxy router" authorization.
> |  >
> |  > 'Proxy host' would authorize for proxying NA, NS and RS, and "proxy
> router"
> |  authorization would authorize RA and Redirect. This would provide a finer
> grain
> |  which I think would be desirable (for example, MIPv6 does not need
> protecting
> |  neither RA nor redirect).
> |  >
> |  >
> |  
> |  So, what you are proposing is to modify the name of the current EKU to
> "proxy
> |  router" and generate a new EKU named "proxy host"?
> 
> Yes.

Ok.

> 
> |  
> |  As a side note, I would like to proposse that you modify the first
> paragraph of
> |  Section 5.2.2 (Processing rules for receivers) by making a reference to
> the draft-
> |  csi-send-cert Section 9 as the certificate validation method.
> 
> Sure. I can include it in 5.2.2, processing step #2, in which certificates
> are considered
> 
> |  
> |  Additional, In the  draft-csi-send-cert document, we could add the
> following text
> |  at the end of Section 9 (validation):
> |  
> |  "The host  MUST verify that the required Key PurposedId(s) value is
> present as
> |  described in Section 7."
> |  
> |  In this sense we close the loop as:
> |  	- you validate the certificate using SIDR defined validation method.
> |  	- you then validate your particular KeyPurpisedId using the text in
> |  Section 9.
> 
> I agree that the validation section can be complemented a bit, for example,
> stating that at least one KeyPurposeId MUST be present. The part 'the
> required' in the text you propose is not clear to me: required... for what,
> in which sense?
> 

I was referring to verify that the KeyPurposeId matches the application. What about replacing "required" by "correspondent"

 "The host  MUST verify that the correspondent Key PurposedId(s) value is
present as described in Section 7."

> 
> Just one question (which could affect validation): I assume (maybe I'm
> wrong) that a certificate is bound to a Certified IPv6 address space, in the
> sense that the KeyPurposeId affects to ALL the addresses (or prefixes) of
> the certificate. Then, I don't understand how a given prefix can be at the
> same time 'router' or 'owner', or 'proxy router' or 'proxy host'. For me,
> all this functionalities should inherently incompatible for a given prefix
> (for example, a router maybe is authorized as a 'router' for a prefix, but
> should be authorized as 'owner' for just a single address of the prefix
> (don't think it is a good idea to allow to be 'owner' of the whole prefix,
> which in fact it is not). Also, either a node is 'router' for a prefix, or
> 'proxy router', but both do not make sense. The same for 'owner' and 'proxy
> owner/host'
> If some combinations are possible, but others are not, it should also be
> specified, I think.

It is true that some combinations do not work. You will need more than one certificate in those cases.

Roque.

> 
> Regards,
> Alberto 
> 
> 
> |  
> |  Roque.
> |  
> |  
> |  
> |  
> |  
> |  > I think this would work (if so, it should be changed in
> draft-csi-send-cert).
> |  >
> |  >
> |  >
> |  > What do you think? (both authors of draft-csi-send-cert, Sandra, etc.).
> |  >
> |  >
> |  >
> |  > Regards,
> |  >
> |  > Alberto
> |  >
> |  >
> |  >
> |  >
> |  >
> 
>