Alberto, see inline comments.
I will then modify the text in the document and submit the changes. I will also
write to PKIX asking for the new EKU.
Regards,
Roque
----------------------------------------------------------------------------------------------------------------------------------------------
Roque Gagliano
Cisco Systems International Sàrl
Software Engineer
Mailstop ROL01/2/
Corporate Development Technology Group Avenue
des Uttins 5
1180 Rolle
[email protected]
Switzerland
Phone: +41 21 823 2805
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html
On Sep 17, 2010, at 2:56 PM, Alberto García wrote:
> Hi Roque,
>
> | -----Mensaje original-----
> | De: Roque Gagliano [mailto:[email protected]]
> | Enviado el: jueves, 16 de septiembre de 2010 11:16
> | Para: Alberto García
> | CC: [email protected]
> | Asunto: Re: [CGA-EXT] Key Purpose Id specification and
> draft-ietf-csi-proxy-send
> |
>
> [...]
>
> | > c) could be to have 2 Key Purpose Ids for proxy operation instead of
> one
> | (therefore replacing id-kp-sendProxy), in which case the following text
> could be
> | included in draft-ietf-csi-send-cert, section 7:
> |
> | I take option c).
> |
> | When I first thought about this, I remembered the old times of modem
> access
> | and Proxy-ARP in routers. I see now a use-case for
> "id-kp-sendProxiedOwner"
> | even without considering MIP6.
> |
> | I agree that we should go this path, it will make a better set of
> documents.
> | However, I believe that if we go this path, we need also to make sure
> that there
> | is a synchronization between this document and the proxy document to
> reflect
> | the correct sender/receiver behavior.
>
> Fine. Then, the main changes in draft-ietf-csi-proxy-send would be:
>
> CHANGE #1
> --------------
> "5.2.1. Processing rules for senders
>
> A Secure ND Proxy MUST NOT use a key to sign NDP message types which
> do not correspond to the authorization granted to the considered key.
> NA, NS and RS messages MUST be signed with a key corresponding to a
> Secure Proxy ND certificate with a KeyPurposeID value
> [I-D.ietf-csi-send-cert] of id-kp-sendProxiedOwner, and the source
> addresses of the messages MUST belong to the prefix associated to the
> certificate. RA and Redirect messages MUST be signed with a key
> corresponding to a Secure Proxy ND certificate with a KeyPurposeID
> value of id-kp-sendProxiedRouter. The prefix included in the RA
> message for on-link determination and/or stateless address
> autoconfiguration, and the Target Address of the Redirect message,
> MUST be equal or be included into the prefix associated to that
> certificate.
> [...]"
>
(Roque) Why not use the terminology of draft-ietf-sidr-res-certs-18 instead of
"equal or included"? I believe the correct term is "encompass".
> CHANGE #2
> --------------
> Rule #2 in "5.2.2. Processing rules for receivers"
> "2. The Key Hash field MUST indicate the use of a known public key.
> A valid certification path (see [RFC3971] Section 6.3) between
> the receiver's trust anchor and the sender's public key MUST be
> known.
(Roque) I would mention rather than RFC3971, the draft-ietf-csi-send-cert-06
section 9. I would also use the word "valid", which means that the validation
process has been successful.
> The Secure Proxy ND's X509v3 certificate MUST contain an
> extended key usage extension including the appropriate
> KeyPurposeId value and prefix for the message to validate:
>
> * For RA messages, a KeyPurposeId value of id-kp-
> sendProxiedRouter MUST exist for the certificate, and the
> prefix included in the RA message for on-link determination
> and/or stateless address autoconfiguration MUST be equal or be
> included into the prefix associated to that certificate.
(Roque) again the term should be "encompass".
> * For Redirect messages, a KeyPurposeId value of id-kp-
> sendProxiedRouter MUST exist for the certificate, and the
> prefix included in the Target Address of the Redirect message
> MUST belong to the prefix associated to that certificate.
(Roque) again the term should be "encompass".
> * For NA, NS and RS messages, a KeyPurposeId value of id-kp-
> sendProxiedOwner MUST exist for the certificate, and the
> source addresses of the messages MUST belong to the prefix
> associated to the certificate.
(Roque) again the term should be "encompass".
> If any of these tests fails, the verification fails."
>
> CHANGE #3
> --------------
> Modification of the application scenarios to detail how the certificates are
> configured. For example, for PMIPv6:
>
> " To provide SEND protection, each MAG is configured to act as a proxy
> by means of a certificate associated to the PMIPv6 domain,
> authorizing each MAG to proxy securely NA and RS messages by means of
> a KeyPurposeId value of id-kp-sendProxiedOwner. In addition, the
> certificate must also authorize the MAG to advertise prefixes, by
> associating to the same certificate a KeyPurposeId value of id-kp-
> sendProxiedRouter. Note that the inclusion of multiple KeyPurposeId
> values is supported by [I-D.ietf-csi-send-cert]."
>
> CHANGE #4
> --------------
> And finally, in the following paragraph would be included in the security
> considerations section:
>
> " A compromised Secure ND Proxy provisioned with an authorization
> certificate with a KeyPurposeId value of id-kp-sendProxiedRouter is
> able, like a compromised router to siphon off traffic from the host,
> or mount a man-in-the-middle attack, for hosts communicating to off-
> link hosts. However, a Secure ND Proxy with an authorization
> certificate with a KeyPurposeId value of id-kp-sendProxiedOwner can
> also siphon off traffic or mount a man-in-the-middle attack for
> communication between on-link hosts, even if the hosts use SEND.
> Note that different application scenarios may require one type of
> authorization, the other, or both. To minimize security risks,
> authorization capabilities SHOULD NOT exceed the ones strictly
> required by the application scenario to be deployed."
>
>
> Do you think the new text is reasonable?
Sounds good.
Roque
>
> |
> | Finally, I would like to clarify the validation behavior when listen
> several EKUs in
> | a certificate. At this time, the document states that the existence of a
> particular
> | EKU is a sufficient condition. This means that if a certificate has a
> id-kp-
> | sendProxiedRouter and a id-kp-sendRouter EKU and I am validating a RA
> with or
> | without the proxy option, it will validate in either cases using the same
> key. I
> | believe this should be the correct behavior as it should be the operator
> to decide
> | how it want to configure its network.
>
> I agree that a certificate could hold both id-kp-sendProxiedRouter and
> id-kp-sendRouter EKUs and validate RA or Redirect/RA proxying with the same
> key.
>
> I think the text provided above allows this behavior.
>
> Thanks and regards,
> Alberto
>
> |
> |
> |
> | Regards,
> |
> | Roque
> |
> |
> | >
> | > "The inclusion of the proxied routing authorization value (id-kp-
> | sendProxiedRouter)
> | > indicates that the certificate has been issued for allowing the proxy
> | > to perform proxying of RA and Redirect messages for the prefix(es)
> | > that are mentioned in the X.509 extensions for IP addresses. When a
> | > node's only certificate includes a prefix and only the
> | > id-kp-sendProxiedRouter authorization KeyPurposeId value, the node
> cannot
> | > perform proxying of NS, NA and RS messages.
> | >
> | > The inclusion of the proxied owner authorization value (id-kp-
> | sendProxiedOwner)
> | > Indicates that the certificate has been issued for allowing the proxy
> to
> | > perform proxying of NS, NA and RS messages for any address in the
> prefix of
> | > such certificate. When a node's only certificate includes a prefix and
> only
> | > the id-kp-sendProxiedOwner authorization KeyPurposeId value, the node
> | > cannot advertise that prefix in an RA."
> | >
> | > The benefit of option c) is that proxy security is tailored to the
> proxy
> | requirements, in the sense that different application scenarios may
> require one
> | type of authorization, the other, or both. For example, MIPv6 would use a
> | certificate with just id-kp-sendProxiedOwner, while PMIPv6 and RFC4389
> would
> | use a certificate with both id-kp-sendProxiedRouter and sendProxiedOwner.
> | Compromising a MIPv6 HA would not allow an attacker to issue RA and
> Redirects.
> | My personal opinion is that, to minimize security risks, authorization
> capabilities
> | should not exceed the ones strictly required by the application scenario
> to be
> | deployed, and two Key Purpose Ids for proxy operation provide appropriate
> | granularity for this.
> | >
> | > (sorry if I fail to expose fairly the benefits of all options - feel
> free to comment,
> | of course)
> | >
> | > For me, b) would acceptable, but I think c) should be better.
> | > What do you think?
> | >
> | > Regards,
> | > Alberto
> | >
> | > _______________________________________________
> | > CGA-EXT mailing list
> | > [email protected]
> | > https://www.ietf.org/mailman/listinfo/cga-ext
>
>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ CGA-EXT mailing list [email protected] https://www.ietf.org/mailman/listinfo/cga-ext
