Certificate Profile and Certificate Management for SEcure Neighbor Discovery (SEND)
draft-ietf-csi-send-cert-10

[Ballot comment]
In Section 7, there are several to-be-assigned values.  They have
  been assigned:

    id-kp-sendRouter  OBJECT IDENTIFIER ::= { id-kp 23 }
    id-kp-sendProxy    OBJECT IDENTIFIER ::= { id-kp 24 }
    id-kp-sendOwner    OBJECT IDENTIFIER ::= { id-kp 25 }

[Ballot discuss]
The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns
  about changes from RFC 3971; if these changes are intentional it
  would be very desirable to add a section on changes from RFC 3971.

  1. In Section 4, second paragraph, this document says, "SEND
    certificates MUST include the IP Resources extension for IPv6
    Address."  And, Section 6.3.1 of RFC 3971 says, "Router
    Authorization Certificates are X.509v3 certificates, as defined
    in RFC 3280, and SHOULD contain at least one instance of the
    X.509 extension for IP addresses, as defined in RFC 3779."
    Is the transition from "SHOULD" to "MUST" intended?

  2. In Section 4, second paragraph, this document says, "Certified IPv6
    address space SHOULD be expressed using either addressPrefix or
    addressesOrRange  elements."  And, Section 6.3.1 in RFC 3971 says,
    "The X.509 IP address extension MUST contain at least
    one addressesOrRanges element" as well as "The X.509 IP address
    extension MAY contain additional IPv6 subnet prefixes, expressed
    as either an addressPrefix or an addressRange."  I suspect these
    should be the same.

[Ballot comment]
I cleared my DISCUSS positions.  Because this profile relies on the res-cert profile we should make them address the two additional security considerations.  Also, Suresh has already asked for an OID from PKIX - so I'll trust him to put it in during AUTH48.

[Ballot discuss]
[Revised - I removed the DISCUSS positions addressed in -04.  Added some more information in #2 and #4]

#2) You also need to register the OID for the ASN.1 module.  I assume you're going to try to get them out of the PKIX arc?

Additional Info: If you tell me you'll do this during AUTH48 I'll clear this one too.


#4) Two additional security considerations are needed:
1) Why algorithm agility isn't needed
2) Why it's okay to use SHA-1

Additional Info: For this one if you copy the 1st paragraph from the draft-ietf-csi-send-name-type-registry I'd clear this one too.

[Ballot discuss]
[Revised - I removed the DISCUSS positions addressed in -04.  Added some more information in #2 and #4]

#2) You also need to register the OID for the ASN.1 module.  I assume you're going to try to get them out of the PKIX arc?

Additional Info: If you tell me you'll do this during AUTH48 I'll clear this one too.


#4) Two additional security considerations are needed:
1) Why algorithm agility isn't needed
2) Why it's okay to use SHA-1

Additional Info: For this one if you copy the 1st paragraph from the draft-ietf-csi-send-name-type-registry I'd clear this one too.

[Ballot discuss]
[Revised - I removed the DISCUSS positions addressed in -05.  Added some more information in #2 and #4]

#2) You also need to register the OID for the ASN.1 module.  I assume you're going to try to get them out of the PKIX arc?

Additional Info: If you tell me you'll do this during AUTH48 I'll clear this one too.


#4) Two additional security considerations are needed:
1) Why algorithm agility isn't needed
2) Why it's okay to use SHA-1

Additional Info: For this one if you copy the 1st paragraph from the draft-ietf-csi-send-name-type-registry I'd clear this one too.

[Ballot discuss]
This is an excellent document and I am planning to post a Yes vote
on it. However, there was one detail that I wanted to draw your
attention to:

  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]

The definition of "owns" is imprecise. What exactly are you allowing
nodes to do, if they have this flag on in the certificate? I *think*
you mean that a host can assign the address and send/receive traffic
on it, and be able to respond to NSes about that address. This is
to enable the SEND certificate-based host security.

But what would prefix ownership mean, and how would it be different
from the router advertisement key usage flag?

[Ballot comment]
(1) Please review the secdir review in its totality.  I realize this came in late, but I think there
are a number of comments that would improve the document.  The review is available at:

  http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html

(2) In section 4, last sentence:

                    Certified IPv6 address space
  SHOULD be expressed using either addressPrefix or addressesOrRange
  elements.

I re-read the syntax in 3779, and I don't quite understand what is intended here.  I don't
think there is another choice in the end.  Is the point that either a prefix or a range is
acceptable?

(3) Section 4 refers to an earlier version of sidr-res-certs, and the section numbering has
changed.  Specifically, the sections 3.9.10 and 3.9.11 are now 4.9.10 and 4.9.11.  (There may
be others.)  If you are making other edits, updating the version number and section
references might be a good idea.

[Ballot discuss]
Richard Barnes identified two issues that I consider particularly important, and would like to
see addressed before publication.  These issues are paraphrased below:


Section 5 identifies two deployment models.  The text implies (by omission) that deployments
must choose between these models.  In fact, a hybrid deployment is both possible and likely.
In the hybrid deployment model most resources would be certified under the global RPKI, while
some (e.g., ULAs) are certified under local TAs.


In Section 7, the paragraph beginning "The inclusion of ..."

It would be helpful for the document to specify how prefix matching should be done when validating these extensions. Which of the following should the RP use?
-- Exact matching,
-- Subset matching (RA within cert), or
-- The subset/intersection algorithm defined in RFC 3971.

What prefix should the RP be matching against from SEND, per EKU? E.g., for id-kp-sendRouter, the RFC 3779 extension in the cert should match against any RAs the router emits. It may be useful to refer to the ROA validation document [draft-ietf-sidr-roa-validation].

[Ballot comment]
(1) Please review the secdir review in its totality.  I realize this came in late, but I think there
are a number of comments that would improve the document.  The review is available at:

  http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html

(2) In section 4, last sentence:

                    Certified IPv6 address space
  SHOULD be expressed using either addressPrefix or addressesOrRange
  elements.

I re-read the syntax in 3779, and I don't quite understand what is intended here.  I don't
think there is another choice in the end.  Is the point that either a prefix or a range is
acceptable?

(3) Section 4 refers to an earlier version of sidr-res-certs, and the section numbering has
changed.  Specifically, the sections 3.9.10 and 3.9.11 are now 4.9.10 and 4.9.11.  (There may
be others.)  If you are making other edits, updating the version number and section
references might be a good idea.

[Ballot comment]
Please review the secdir review in its totality.  I realize this came in late, but I think there
are a number of comments that would improve the document.  The review is available at:

  http://www.ietf.org/mail-archive/web/secdir/current/msg01701.html

[Ballot discuss]
I sent these during IETF LC, and I believe the author is incorporating text to address them.  They have been renumbered and I added a new #4 and #5.  I will clear once a new version is posted or an RFC editor is included:

#1) I would like to see an ASN.1 module added to the document.  That way we can import the EKUs.  Here's what I'm looking for (something similar was done in draft-ietf-sip-eku):

-----
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-send-cert-extns(TBD) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- OID Arc

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

-- Extended Key Usage Values

id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }

END
-----

#2) You also need to register the OID for the ASN.1 module.  I assume you're going to try to get them out of the PKIX arc?

#3) In the last paragraph of Section 7 you describe what the certificate-using application might require.

3.a) It says that including the EKU extension is a MAY, but the first paragraph says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in the last paragraph.

3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then shouldn't value also be required?  That is, make the second MAY a MUST in the last paragraph.

3.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280?

3.d) You should look at draft-ietf-sip-eku for what they say about processing their EKU.  Those rules are helpful to implementers.

#4) Two additional security considerations are needed:
1) Why algorithm agility isn't needed
2) Why it's okay to use SHA-1

#5) draft-ietf-sidr-arch-09 is a normative reference.  It is expired and bound for informational.  Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC is necessary for this DOWNREF.

[Ballot discuss]
I sent these during IETF LC, and I believe the author is incorporating text to address them.  They have been renumbered and I added a new #4.  I will clear once a new version is posted or an RFC editor is included:

#1) I would like to see an ASN.1 module added to the document.  That way we can import the EKUs.  Here's what I'm looking for (something similar was done in draft-ietf-sip-eku):

-----
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-send-cert-extns(TBD) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- OID Arc

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

-- Extended Key Usage Values

id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }

END
-----

#2) You also need to register the OID for the ASN.1 module.  I assume you're going to try to get them out of the PKIX arc?

#3) In the last paragraph of Section 7 you describe what the certificate-using application might require.

3.a) It says that including the EKU extension is a MAY, but the first paragraph says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in the last paragraph.

3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then shouldn't value also be required?  That is, make the second MAY a MUST in the last paragraph.

3.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280?

3.d) You should look at draft-ietf-sip-eku for what they say about processing their EKU.  Those rules are helpful to implementers.

4) draft-ietf-sidr-arch-09 is a normative reference.  It is expired and bound for informational.  Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC is necessary for this DOWNREF.

[Ballot discuss]
I sent these during IETF LC, and I believe the author is incorporating text to address them.  They have been renumbered and I added a new #4.  I will clear once a new version is posted or an RFC editor is included:

#1) I would like to see an ASN.1 module added to the document.  That way we can import the EKUs.  Here's what I'm looking for (something similar was done in draft-ietf-sip-eku):

-----
SENDCertExtns { iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0)
  id-mod-send-cert-extns(TBD) }

DEFINITIONS IMPLICIT TAGS ::=

BEGIN

-- OID Arc

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

-- Extended Key Usage Values

id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp 23 }
id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp 24 }
id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp 25 }

END
-----

#2) You also need to register the OID for the ASN.1 module.  I assume you're going to try to get them out of the PKIX arc?

#3) In the last paragraph of Section 7 you describe what the certificate-using application might require.

3.a) It says that including the EKU extension is a MAY, but the first paragraph says it MUST be present in EE certificates for SEND. Assuming the 1st paragraph is correct the 1st MAY needs to be a MUST in the last paragraph.

3.b) Assuming the 1st paragraph in is correct and EKU MUST be present then shouldn't value also be required?  That is, make the second MAY a MUST in the last paragraph.

3.c) Was there discussion about support for the anyExtendedKeyUsage OID from 4.2.1.12 of RFC 5280?

3.d) You should look at draft-ietf-sip-eku for what they say about processing their EKU.  Those rules are helpful to implementers.

4) draft-ietf-sidr-arch-09 is expired and informational.  Assuming draft-ietf-sidr-arch-09 is revised, a new IETF LC is necessary for this DOWNREF.

[Ballot comment]
In Section 7, there are several to-be-assigned values.  They have
  been assigned:

    id-kp-sendRouter  OBJECT IDENTIFIER ::= { id-kp 23 }
    id-kp-sendProxy    OBJECT IDENTIFIER ::= { id-kp 24 }
    id-kp-sendOwner    OBJECT IDENTIFIER ::= { id-kp 25 }

[Ballot discuss]
The Gen-ART Review by Roni Even on 2-May-2010 raises two concerns
  about changes from RFC 3971; if these changes are intentional it
  would be very desirable to add a section on changes from RFC 3971.

  1. In Section 4, second paragraph, this document says, "SEND
    certificates MUST include the IP Resources extension for IPv6
    Address."  And, Section 6.3.1 of RFC 3971 says, "Router
    Authorization Certificates are X.509v3 certificates, as defined
    in RFC 3280, and SHOULD contain at least one instance of the
    X.509 extension for IP addresses, as defined in RFC 3779."
    Is the transition from "SHOULD" to "MUST" intended?

  2. In Section 4, second paragraph, this document says, "Certified IPv6
    address space SHOULD be expressed using either addressPrefix or
    addressesOrRange  elements."  And, Section 6.3.1 in RFC 3971 says,
    "The X.509 IP address extension MUST contain at least
    one addressesOrRanges element" as well as "The X.509 IP address
    extension MAY contain additional IPv6 subnet prefixes, expressed
    as either an addressPrefix or an addressRange."  I suspect these
    should be the same.

[Ballot comment]
5.  Deployment Models

  In this
  scenario, the deployment of SEND MAY be done independently of the
  existence of deployment in the upper RPKI hierarchy (i.e. an end user
  could local SEND deployment without the need of RPKI deployment in

Missing verb after "could".

  its ISP).

  This model MAY include ULA addresses.

Please expand the ULA acronym on first use.


It looks like the document needs an Informative reference to RFC 5781
(due to use of rsync URIs in the example).

[Ballot discuss]
7.  Extended Key Usage Values

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

Who owns this OID arc and who is going to assign the three values below:

    id-kp-sendRouter OBJECT IDENTIFIER ::= { id-kp TBA1 }

    id-kp-sendProxy OBJECT IDENTIFIER ::= { id-kp TBA2 }

    id-kp-sendOwner OBJECT IDENTIFIER ::= { id-kp TBA3 }

?

Document Shepherd Write-up for draft-ietf-csi-send-cert-03

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          The document shepherd is Marcelo Bagnulo who has reviewed
          this version of the document and believes that us ready for
          forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

          The document was reviewed by both WG members and non-WG members.
          Notably, the document has been reviewed by SIDR WG members and
          it was produced in close collaboration with them. Other relevant
          WGs have been consulted during WGLC.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

          No.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

          No special concerns or issues.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

          The consensus behind the document is solid. the document adopts
          the RPKI defined in the SIDR WG, so it goes along the general
          consensus in the IETF.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

          No conflicts.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

          I have verified the ID nits.

          No MIB Doctor, media type nor UR type reviews are needed for
          this document.

          The document intended status is STD. It is intended to update
          RFC3971 if approved.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

          The references are split into normative and informative.
          There are five normative references that are in draft status.
          draft-ietf-csi-proxy-send will be submitted to the IESG briefly.
          The other 4 drafts are being done by the sidr WG,
          which we hope will be submitted to the IESG at some point in time.
          This dependence is due tot he fact that we have adopted the SIDR
          architecture in this draft.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

          There are no IANA actions in this draft.
          There is however the need to assign 3 values of extended key purpose
          identifiers. We have requested the values to the PKIX WG and cc the AD.
          We would need to obtain the allocation in order for this draft to proceed.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

          The document does no contain any section written in a formal
          language.
 
  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  SEcure Neighbor Discovery (SEND) Utilizes X.509v3 certificates for
  performing router authorization.  This document specifies a
  certificate profile for SEND based on Resource Certificates along
  with extended key usage values required for SEND.



          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

          Nothing special that worth noting. Not a controversial document.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          The document defines the cert profile for SEND certs.
          The work has benefited from the involvement of members of the SIDR WG,
          notably Stephen Kent as well as the SIDR WG chairs at the time the
          work was done, Geoff Huston and Sandy Murphy.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

        Document shepherd: Marcelo Bagnulo
        Area Director: Ralf Droms