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

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

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

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

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

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

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


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.

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