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

Alberto García <alberto@it.uc3m.es> Tue, 06 July 2010 15:32 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 9E06A3A63C9; Tue, 6 Jul 2010 08:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.698
X-Spam-Level:
X-Spam-Status: No, score=-3.698 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, 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 vxLrCCPqEkF8; Tue, 6 Jul 2010 08:32:44 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id 7E10A3A6973; Tue, 6 Jul 2010 08:32:42 -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 EF31E65521E; Tue, 6 Jul 2010 17:32:42 +0200 (CEST)
From: Alberto García <alberto@it.uc3m.es>
To: 'Sandra Murphy' <Sandra.Murphy@sparta.com>, iesg@ietf.org, secdir@ietf.org, draft-ietf-csi-proxy-send.all@tools.ietf.org, draft-ietf-csi-send-cert@tools.ietf.org
Date: Tue, 06 Jul 2010 17:32:41 +0200
Message-ID: <E7FA9617215B4AE08B038FC422C42568@bombo>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_008C_01CB1D31.3C488620"
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcsdIELAT3gnY73lTtidmX3OxNhNnQ==
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.000
X-Mailman-Approved-At: Tue, 06 Jul 2010 08:40:01 -0700
Cc: 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: Tue, 06 Jul 2010 15:32:54 -0000

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:Sandra.Murphy@sparta.com]

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

|  Para: iesg@ietf.org; secdir@ietf.org;
draft-ietf-csi-proxy-send.all@tools.ietf.org

|  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