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

Sandra Murphy <Sandra.Murphy@sparta.com> Tue, 06 July 2010 16:55 UTC

Return-Path: <Sandra.Murphy@cobham.com>
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 85D783A69B0; Tue, 6 Jul 2010 09:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level:
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=1.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 LG5OtfvlYrj2; Tue, 6 Jul 2010 09:55:43 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id E7C613A699C; Tue, 6 Jul 2010 09:55:42 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id o66GtiRh009030; Tue, 6 Jul 2010 11:55:44 -0500
Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id o66GtiwB029134; Tue, 6 Jul 2010 11:55:44 -0500
Received: from SMURPHY-LT.columbia.ads.sparta.com ([157.185.81.96]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 6 Jul 2010 12:55:43 -0400
Date: Tue, 6 Jul 2010 12:55:43 -0400 (Eastern Daylight Time)
From: Sandra Murphy <Sandra.Murphy@sparta.com>
To: =?ISO-8859-15?Q?Alberto_Garc=EDa?= <alberto@it.uc3m.es>
In-Reply-To: <E7FA9617215B4AE08B038FC422C42568@bombo>
Message-ID: <Pine.WNT.4.64.1007061253310.4996@SMURPHY-LT.columbia.ads.sparta.com>
References: <E7FA9617215B4AE08B038FC422C42568@bombo>
X-X-Sender: sandy@nemo.columbia.sparta.com
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="326479267-6848-1278435343=:4996"
X-OriginalArrivalTime: 06 Jul 2010 16:55:43.0592 (UTC) FILETIME=[1279A680:01CB1D2C]
Cc: draft-ietf-csi-proxy-send.all@tools.ietf.org, csi-chairs@tools.ietf.org, iesg@ietf.org, draft-ietf-csi-send-cert@tools.ietf.org, secdir@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 16:55:46 -0000

Thank you.  I was debating whether a message about message authorization 
vs cert authorization values was more appropriately directed to the csi 
group or the send-cert authors.  This spares me the trouble of trying to 
make up my mind.  :-)

I think this should prove to be an interesting discussion.

--Sandy


On Tue, 6 Jul 2010, Alberto García wrote:

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