Subject: [CGA-EXT] Key Purpose Id specification and draft-ietf-csi-proxy-send

From: Alberto García <[email-masked]>
Date: Wed, 8 Sep 2010 15:27:56 +0200

Hi,

During IESG evaluation of draft-ietf-csi-proxy-send-04, Sandra Murphy
pointed out that "I believe that a discussion is needed of what messages
require or allow each particular key purpose authorization".
draft-ietf-csi-send-cert-06 has been updated (in section 7) to provide more
detail regarding to this issue.

However, in the process of addressing this comment, some authors of
draft-ietf-csi-proxy-send and draft-ietf-csi-send-cert have arrived to a
controversial point, which I refer to you, kindly requesting your opinion:

In the current version of draft-ietf-csi-send-cert, 3 Key Purpose Id are
defined: id-kp-sendRouter, id-kp-sendProxy and id-kp-sendOwner. The Key
Purpose Id intended for proxy operation is id-kp-sendProxy. With the current
wording, 
   "The inclusion of the proxy authorization value (id-kp-sendProxy)
   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."
 
it is not clear how a proxy requiring to proxy NA, NS and RS messages (in
fact, the three application cases considered in draft-ietf-csi-proxy-send)
would operate: 
a) Using id-kp-sendProxy for RA and Redirect, and id-kp-sendOwner for NA,
NS, RS? My feeling is that id-kp-sendOwner should be reserved for hosts
really owning the address, and not to be included in PS options.
b) Modifying id-kp-sendProxy, extending the authorization to NA, NS and RS,
so that id-kp-sendProxy authorizes ANY proxy operation
 
However, another option, 
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:

"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

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 16 Sep 2010 11:15:50 +0200

Hi Alberto,

Please see inline.
 
> In the current version of draft-ietf-csi-send-cert, 3 Key Purpose Id are defined: id-kp-sendRouter, id-kp-sendProxy and id-kp-sendOwner. The Key Purpose Id intended for proxy operation is id-kp-sendProxy. With the current wording, 
>    “The inclusion of the proxy authorization value (id-kp-sendProxy)
>    that are mentioned in the X.509 extensions for IP addresses.”
>  
> it is not clear how a proxy requiring to proxy NA, NS and RS messages (in fact, the three application cases considered in draft-ietf-csi-proxy-send) would operate: 

Actually, the text you are referring is already a modified version of the original text that got WGLC. That text represented your option b).

> a) Using id-kp-sendProxy for RA and Redirect, and id-kp-sendOwner for NA, NS, RS? My feeling is that id-kp-sendOwner should be reserved for hosts really owning the address, and not to be included in PS options.
> b) Modifying id-kp-sendProxy, extending the authorization to NA, NS and RS, so that id-kp-sendProxy authorizes ANY proxy operation
>  
> However, another option, 
> 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.

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.

Regards,

Roque

>  
> “The inclusion of the proxied routing authorization value (id-kp-sendProxiedRouter)
> The inclusion of the proxied owner authorization value (id-kp-sendProxiedOwner)
> 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)
>  
> _______________________________________________
> CGA-EXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Alberto García <[email-masked]>
Date: Fri, 17 Sep 2010 14:56:05 +0200

Hi Roque,

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:[email-masked]]
|  Enviado el: jueves, 16 de septiembre de 2010 11:16
|  Para: Alberto García
|  CC: [email-masked]
|  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.
[...]"

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

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

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

       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?

|  
|  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-masked]
|  > https://www.ietf.org/mailman/listinfo/cga-ext

---

From: Roque Gagliano <[email-masked]>
Date: Thu, 23 Sep 2010 17:53:12 +0200

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-masked]										Switzerland
Phone: +41 21 823 2805									

For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html

> Fine. Then, the main changes in draft-ietf-csi-proxy-send would be:

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

>       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

(Roque) again the term should be "encompass".

>          MUST belong to the prefix associated to that certificate.

(Roque) again the term should be "encompass".

>          associated to the certificate.

(Roque) again the term should be "encompass".

>       If any of these tests fails, the verification fails."

Sounds good.

Roque

---

From: Alberto García <[email-masked]>
Date: Fri, 24 Sep 2010 11:30:03 +0200

Roque

Thank you for your comments ! I have included them in the
draft-ietf-csi-proxy-send text.

Regards,

Alberto

  _____  

De: Roque Gagliano [mailto:[email-masked]] 
Enviado el: jueves, 23 de septiembre de 2010 17:53
Para: Alberto García
CC: [email-masked]
Asunto: Re: [CGA-EXT] Key Purpose Id specification and
draft-ietf-csi-proxy-send

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-masked]
Switzerland
Phone: +41 21 823 2805

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html 

Hi Roque,

[...]

CHANGE #1
--------------

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

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

CHANGE #3
--------------

CHANGE #4
--------------

Sounds good.

Roque

|  

Thanks and regards,
Alberto

|  
|  
|  
|  Regards,
|  
|  Roque
|  
|  
|  >