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

Alberto García <alberto@it.uc3m.es> Wed, 07 July 2010 16:28 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 594EA3A67B3; Wed, 7 Jul 2010 09:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.949
X-Spam-Level:
X-Spam-Status: No, score=-4.949 tagged_above=-999 required=5 tests=[AWL=0.750, 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 iuPIJvdkZ0Ma; Wed, 7 Jul 2010 09:28:13 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7C1A73A679F; Wed, 7 Jul 2010 09:28:12 -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 smtp02.uc3m.es (Postfix) with ESMTP id 294086FC4D2; Wed, 7 Jul 2010 18:28:10 +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> <BF131EAB4CA44007987AC10FFB4F0158@bombo> <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com>
Date: Wed, 07 Jul 2010 18:28:07 +0200
Message-ID: <EC159F64304A4E95A9464BC6DD666B41@bombo>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-15"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acsd1/xnb/cMiJktQZa01B3qXSQOsQAGB08w
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931
In-Reply-To: <911338BA-7E6A-41CB-BB01-BFF7A819F050@cisco.com>
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-6.0.0.1038-17492.000
X-Mailman-Approved-At: Wed, 07 Jul 2010 10:51:18 -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 16:28:14 -0000

Hi Roque

|  -----Mensaje original-----
|  De: Roque Gagliano [mailto:rogaglia@cisco.com]
|  Enviado el: miércoles, 07 de julio de 2010 15:26
|  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,
|  
|  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: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
|  >
|  
|  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
|  > |  >
|  > |  >
|  > |  >
|  > |  >
|  > |  >
|  >
|  >