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

Alberto García <alberto@it.uc3m.es> Wed, 07 July 2010 12:39 UTC

Return-Path: <alberto@it.uc3m.es>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EC5E3A67A1; Wed, 7 Jul 2010 05:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.699
X-Spam-Level:
X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_28=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oi4920nTwVFd; Wed, 7 Jul 2010 05:39:08 -0700 (PDT)
Received: from smtp01.uc3m.es (smtp01.uc3m.es [163.117.176.131]) by core3.amsl.com (Postfix) with ESMTP id AE5123A67EB; Wed, 7 Jul 2010 05:39:07 -0700 (PDT)
X-uc3m-safe: yes
Received: from bombo (bombo.it.uc3m.es [163.117.139.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp01.uc3m.es (Postfix) with ESMTP id E78DEBE6349; Wed, 7 Jul 2010 14:39:03 +0200 (CEST)
From: Alberto García <alberto@it.uc3m.es>
To: 'Roque Gagliano' <rogaglia@cisco.com>
References: <E7FA9617215B4AE08B038FC422C42568@bombo> <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com>
Date: Wed, 07 Jul 2010 14:39:00 +0200
Message-ID: <BF131EAB4CA44007987AC10FFB4F0158@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <99775B3B-8619-4EDC-9F6F-23C231C44F18@cisco.com>
Thread-Index: AcsdtGjQw9p8LRybRauUN66MJTFk3gAEcssQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17490.007
X-Mailman-Approved-At: Wed, 07 Jul 2010 05:58:03 -0700
Cc: draft-ietf-csi-send-cert@tools.ietf.org, secdir@ietf.org, 'Sandra Murphy' <Sandra.Murphy@sparta.com>, draft-ietf-csi-proxy-send.all@tools.ietf.org, iesg@ietf.org, csi-chairs@tools.ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-csi-proxy-send-04
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Jul 2010 12:39:09 -0000

Hi Roque, 
Thanks for your fast answer.

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:rogaglia@cisco.com]
|  Enviado el: miércoles, 07 de julio de 2010 11:12
|  Para: Alberto García
|  CC: 'Sandra Murphy'; iesg@ietf.org; secdir@ietf.org;
draft-ietf-csi-proxy-
|  send.all@tools.ietf.org; draft-ietf-csi-send-cert@tools.ietf.org; csi-
|  chairs@tools.ietf.org
|  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
|  >
|  >
|  >
|  >
|  >