[CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt

marcelo bagnulo braun <marcelo@it.uc3m.es> Sat, 14 March 2009 14:38 UTC

Return-Path: <marcelo@it.uc3m.es>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2EAC3A6A05 for <cga-ext@core3.amsl.com>; Sat, 14 Mar 2009 07:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.422
X-Spam-Level:
X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, 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 j84vZiU5ctaa for <cga-ext@core3.amsl.com>; Sat, 14 Mar 2009 07:38:07 -0700 (PDT)
Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by core3.amsl.com (Postfix) with ESMTP id C522D3A68A6 for <cga-ext@ietf.org>; Sat, 14 Mar 2009 07:38:05 -0700 (PDT)
Received: from marcelo-bagnulos-macbook-pro.local (205.pool85-53-145.dynamic.orange.es [85.53.145.205]) by smtp02.uc3m.es (Postfix) with ESMTP id 104AC6563F7; Sat, 14 Mar 2009 15:38:40 +0100 (CET)
Message-ID: <49BBC170.4010008@it.uc3m.es>
Date: Sat, 14 Mar 2009 15:38:40 +0100
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209)
MIME-Version: 1.0
To: Suresh Krishnan <suresh.krishnan@ericsson.com>, Ana Kukec <anchie@fer.hr>, cga-ext@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-TM-AS-Product-Ver: IMSS-7.0.0.3116-5.6.0.1016-16518.007
Subject: [CGA-EXT] about draft-krishnan-cgaext-send-cert-eku-03.txt
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 14 Mar 2009 14:38:08 -0000

Hi,

good work
I think this is in good shape, but i am really far from being an expert 
on this (as my question below reflect)
I have some comments and questions.

2.  Introduction

   Secure Neighbor Discovery [RFC3971] Utilizes X.509v3 certificates for
   performing router authorization.  It uses the X.509 extension for IP
   addresses to verify whether the router is authorized to advertise the
   mentioned IP addresses.

s/addresses/prefixes

   The SEND specification does not describe the set of extensions that
   need to be supported

This is strictly true, right? I mean section 6.3.1.  Router 
Authorization Certificate Profile of the send spec does define the cert 
profile.

4.1.  Extended Key Usage Values


  The inclusion of the router authorization value indicates that the
   certificate has been issued for allowing the router to advertise
   prefix(es) that are mentioned using the X.509 extensions for IP
   addresses and AS identifiers [RFC3779]

I understnad that this means that the router is auhtorized to advertise 
the prefix included in the RADV ND message, right?
I think this shoudl be described more explicitly, I mean, the main 
contribution of the draft is to define these EKU, so it should if very 
precisely, right? would these apply to DHCP prefix delegation for instance?


   The inclusion of the owner authorization value indicates that the
   certificate has been issued for allowing the node to use the
   address(es) or prefix(es) that are mentioned using the X.509
   extensions for IP addresses and AS identifiers [RFC3779]

i am not sure what do you mean about this
Are you aiming for the case we use SEND with non cga addresses? If so, 
it should be more clearly stated. In particualr, i fail to understnad 
why a host could announce more that one address i.e. why prefixes are 
acceptbale. Maybe describing thesecould help

then the draft reads:

   Inclusion of multiple values indicates that the certified public key
   is appropriate for use by a node performing more than one of these
   functions.

     send-kp OBJECT IDENTIFIER ::=
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) TBA1 }

     id-kp-sendRouter OBJECT IDENTIFIER ::= { send-kp 1 }

     id-kp-sendProxy OBJECT IDENTIFIER ::= { send-kp 2 }

     id-kp-sendOwner OBJECT IDENTIFIER ::= { send-kp 3 }


I don't understnad what do you mean by the data strcuture you include 
here... could you clarify? (is it just an example? if, so, please tag it 
as one)

then...

   Certificate-using applications MAY require the extended key usage
   extension to be present in a certificate, and they MAY require a
   particular KeyPurposeId value to be present (such as id-kp-sendRouter
   or id-kp-sendProxy)

where are these keypurposeid are defined?
maybe additng a reference would be useful


then it reads

5.  Backward Compatibility

   The disadvantages of this model are related to the fact that the SEND
   specification was developed before the standardization of the RPKI.
   Hence, SEND is not completely compliant with the RPKI specifications
   since it defines its own IP prefix validation routine and it is not
   suitable for the use with CRLs, while the RPKI suports only CRLs.
   This means that SEND implementations supporting this profile will not
   be able to interoperate with legacy SEND implementations.

I don't fully understnad the implications of this
I mean, what needs to be changed in a current send implementation to be 
compatible with this new format?
I mean, the optimal would be that current send implementations accept 
RPKI certs but skip the new extensions and that new send implementations 
are able to read the new extensions defined by this document. is this 
not possible?

I am missing the part where you actually defines the EKU values for the 
3 usages you have defined... wouldn't this be in the IANA cosiderations 
part of the draft? If not, shouldn't this be somehwere else? I mean, i 
understnad you are assigning 3 values of a registry for that usage? Or 
does this work in a different way?

Regards, marcelo