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

From: Alberto García <[email-masked]>
Date: Tue, 6 Jul 2010 17:32:41 +0200

Hi,

The text of this email has been extracted from a thorough review of
draft-ietf-csi-proxy-send being made by Sandra Murphy. 

The reason why the email has been separated is to include the authors of
draft-ietf-csi-send-cert in the discussion of this part of the text, since I
think some of the issues raised by Sandra affect this document.

I include my comments inline.

|  -----Mensaje original-----

|  De: Sandra Murphy [mailto:[email-masked]]

|  Enviado el: viernes, 02 de julio de 2010 2:31

|  Para: [email-masked]; [email-masked];
[email-masked]

|  Asunto: secdir review of draft-ietf-csi-proxy-send-04

|  

|  This is a review of draft draft-ietf-csi-proxy-send-04.txt.

|  

|  I have reviewed this document as part of the security directorate's

|  ongoing effort to review all IETF documents being processed by the IESG.

|  These comments were written primarily for the benefit of the security
area

|  directors. Document editors and WG chairs should treat these comments
just

|  like any other last call comments.

|  

|  This document provides new Neighbor Discovery options that will secure

|  proxied Neighbor Discovery messages.  It is an update to:

|  

|  RFC4861: Neighbor Discovery in IPv6

|  RFC4389: Neighbor Discovery Proxies (ND Proxy)

|  RFC3971: Send Neighbor Discovery (SEND)

|  

|  This draft relies on draft draft-ietf-csi-send-cert-04.txt.

|  

|  The need for new mechanisms for security for proxied messages is
explained

|  in draft-ietf-csi-sndp-prob-04.txt.

|  

|  I've read all of these, but it is pretty new to me, so I could have
missed

|  something.

|  

|  The Neighbor Discovery protocol communicates link-level addresses in the

|  protocol messages.  The ND Proxy extension would make changes to those

|  fields.  SEND, which secures the base ND protocol, relies on the sender
of

|  a message computing a signature associated with the source IP address of

|  the message.  Any ND Proxy changes to messages would invalidate the

|  signature and the ND Proxy itself could not generate a new signature

|  (since it would not have the private key associated with the source IP

|  address).  This draft introduces a Proxy Signature (PS) option to secure

|  the proxied messages.

|  

|  RFC3971, the base SEND spec, defines a new Router Authorization

|  Certificate profile, dependent on RFC3779, which authorizes the router to

|  act as a router and act for certain prefixes.  Message authorization in

|  SEND of some ND messages checks the prefixes listed in the certificate

|  against the prefixes mentioned in those messages.  There is no explicit

|  representation in the certificate of the authority to act as a router.

|  Possession of the certificate in SEND serves as implicit authorization to

|  act as a router, as that was the only authorization defined.

|  

|  With the introduction of proxies, there was a need to distinguish the

|  various roles that a node might have in the network.  No longer is

|  possession of a certificate adequate authorization.  The draft

|  draft-ietf-csi-send-cert-04.txt uses the KeyPurposeId field to
distinguish

|  three different roles: router, proxy and owner.  That draft notes that

|  multiple key purposes are possible.  I believe that it is also possible
to

|  have single roles - so a node could be a proxy but not a router.

Yes, of course single roles are supported.

|  With the extensions of the csi-send-cert draft, possession of a

|  certificate is no longer proof of any particular authorization.  It seem

|  clear to me that the authorization validation described in RFC3971 is no

|  longer sufficient.  I believe that a discussion is needed of what
messages

|  require or allow each particular key purpose authorization.  Issuing an

|  RA, for example, seems likely to require the "router" value of the key

|  purpose field, if the new certificate format was used for authorization.

|  Issuing an NA may require the "owner" value of the key purpose field, if

|  the new certificate format was used for authorization rather than a CGA.

|  I do not know if that discussion would be more appropriate here or in the

|  csi-send-cert draft, or another draft entirely that updates RFC3971

|  directly.

|  

|  If a SPND proxy was using SEND to communicate with other nodes that

|  understood SPND, would it be OK to use a new format cert (with the

|  "router" KeyPurposeId) as a router certificate for the SEND RSA Signature

|  Options?

|  

I see. I agree that this needs more precision.

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

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

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

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

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

---

From: Sandra Murphy <[email-masked]>
Date: Tue, 6 Jul 2010 12:55:43 -0400 (Eastern Daylight Time)

Thank you.  I was debating whether a message about message authorization 
vs cert authorization values was more appropriately directed to the csi 
group or the send-cert authors.  This spares me the trouble of trying to 
make up my mind.  :-)

I think this should prove to be an interesting discussion.

--Sandy

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 7 Jul 2010 11:11:31 +0200

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

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

   proxying of RA messages for the prefix(es) that are

   mentioned in the X.509 extensions for IP addresses"

> (this is the clearest of all statements - although I think issuing secured NS and RS should also be considered)
> 
What about the following text?

   receive traffic from this address, and can respond to ND 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"?

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. 

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.

Roque.

> I think this would work (if so, it should be changed in draft-csi-send-cert).
> 
>  
>

---

From: Alberto García <[email-masked]>
Date: Wed, 7 Jul 2010 14:39:00 +0200

Hi Roque, 
Thanks for your fast answer.

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:[email-masked]]
|  Enviado el: miércoles, 07 de julio de 2010 11:12
|  Para: Alberto García
|  CC: 'Sandra Murphy'; [email-masked]; [email-masked];
draft-ietf-csi-proxy-
|  [email-masked]; [email-masked]; csi-
|  [email-masked]
|  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
|  >
|  >
|  >
|  >
|  >

---

From: Roque Gagliano <[email-masked]>
Date: Wed, 7 Jul 2010 15:26:09 +0200

Hi Alberto,

Please see inline.

Roque.

> function' pack is RA+Redirect

ok.

> Yes, also including Redirect. 

ok.

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

> |  router" and generate a new EKU named "proxy host"?

Ok.

> required' in the text you propose is not clear to me: required... for what,

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

> If some combinations are possible, but others are not, it should also be

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

Roque.

---

From: Alberto García <[email-masked]>
Date: Wed, 7 Jul 2010 18:28:07 +0200

Hi Roque

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:[email-masked]]
|  Enviado el: miércoles, 07 de julio de 2010 15:26
|  Para: Alberto García
|  CC: 'Sandra Murphy'; [email-masked]; [email-masked];
draft-ietf-csi-proxy-
|  [email-masked]; [email-masked]; csi-
|  [email-masked]
|  Asunto: Re: secdir review of draft-ietf-csi-proxy-send-04
|  
|  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:[email-masked]]
|  > |  Enviado el: miércoles, 07 de julio de 2010 11:12
|  > |  Para: Alberto García
|  > |  CC: 'Sandra Murphy'; [email-masked]; [email-masked];
|  > draft-ietf-csi-proxy-
|  > |  [email-masked]; [email-masked];
csi-
|  > |  [email-masked]
|  > |  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"

I wonder if the 'respond' close to the 'RS' may induce the reader to think
that the 'owner' could generate a RA, which in fact it can't. I would take
out the respond, but if you think it is clear enough... 

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

ok

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

In fact, I don't know if there is any combination that work (I think there
is no one). If there is no one, then only one KeyPurposeId MUST be allowed
per certificate (even if in the future there are cases in which many
authorization roles are possible, then many certificates should be used). 
Or, if you think that many KeyPurposeIds must be supported, it should be
clearly stated which combinations are not allowed (I think all of the
combinations of KeyPurposeId currently being defined).
Or I am missing anything?

Regards,
Alberto

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