Subject: Re: Comments on rps-auth-02 draft

From: Curtis Villamizar <[email-masked]>
Date: Wed, 21 Apr 1999 18:27:08 -0400

Getting ready to send this draft to the internet-drafts editor again..

In message <[email-masked]>, David Woodgate 
writes:
> 
> Here are a few comments on the auth draft:
> 
> 1.	Trust Model
> 
> 	A.	I believe that (intentionally) the document does not deal
> 		with any issues concerning the security of queries to the
> 		database. This may be obvious, but it should probably be
> 		stated explicitly somewhere anyway.

After the section "Implicit Policy Assumptions" I added:

  \section{Scope of Security Coverage}

  This document is intended only to provide an authentication and
  authorization model to insure the integrety of the policy data in a
  registry.  Only authetication and authorization of additions,
  deletions, and changes to the database are within the scope of this
  document.  Authentication and authorization of database queries is
  explicitly out of scope.  Mutual authentication of queries, that is
  authenticating both the origin of the query and the repository from
  which query results are obtained, is also out of scope.

> 	B.	My understanding of the processes surrounding the submission
> 		of a new object to a registry is that it only relies
> 		on checks from the immediate (potential) parent objects.
> 		However, I don't believe that at any stage is the authenticatio
> n
> 		or the integrity of those parent objects rechecked. In other
> 		words, once the data is in the repository, it is assumed
> 		to be valid - there are no subsequent rechecks of validity.
> 
> 		(Please correct me if I'm wrong about this.)
> 
> 		This is a fine assumption to make, but it probably should
> 		be stated explicitly - at least in a comment in the security
> 		section, and possibly even in a separate, small (one sentence)
> 		section around the same area in the document, as the
> 		"Implicit Policy Assumptions" section.

This is covered in rps-dist by the "integrety" attribute used to allow
grandfathered data of questionable origin.  I can't reference rps-dist
because we plan to move forward with that later than rps-auth.

> 2.	mnt-routes vs. mnt-lower
> 
> 	After our discussion, I understand some of the historical and
> 	legacy issues involved in these attributes. Nevertheless, I'm
> 	still concerned that there is significant potential for confusion
> 	about which gets used where and why.
> 
> 	Would there be a possibility of either:
> 	(a)	Deprecating the use of one, and prefer the other;
> 	(b)	Merging the two attributes into one?
> 
> 	With respect to the definition of the mnt-routes attribute
> 	in section 9.1, it might be worth reusing the bulk of the last
> 	paragraph in section 8.1 to replace the second and third sentences
> 	of the section 9.1 definition, as I think the 8.1 paragraph
> 	was clearer about the functions of mnt-routes.

At the meeting we agreed to keep these but simplify these a bit.  In
the minutes Cengiz has:

   The working grouped is explicitly provided consensus on:
        - dont use mnt-routes to provide authorization to inetnum objects
        - any maintainer in mnt-routes, mnt-lower and mnt-by are
          authorized for route objects. any maintainer in mnt-lower
          and mnt-by for other objects.
        - to go to the last call after ietf on rps-auth and rps-dbsec-pgp

This is reflected in the following diffs:

  +Where ``mnt-routes'' or ``mnt-lower'' are applicable, any maintainer
  +referenced in the ``mnt-by'' still apply.  The set of applicable
  +maintainers for whatever check is being made is the union of the
  +``mnt-routes'' or ``mnt-lower'' and the ``mnt-by''.

  @@ -1052,16 +1057,11 @@
                        When used with a aut-num, inetnum, or route
                        object, this attribute references a maintainer object
                        which is used in determining authorization for
  -                     the addition of route objects.  When placed in
  -                     a less specific inetnum it is used in
  -                     determining authorization for the addition of 
  -                     more specific inetnum objects.
  +                     the addition of route objects.
                        After the reference to the
                        maintainer, an optional list of prefix ranges
                        (as defined in RPSL) inside of curly braces or
  -                     the keyword ``ANY'' may follow.  If a mnt-routes  
  -                     attribute is absent, the mnt-lower or mnt-by
  -                     mnt-by attribute is used for this purpose.
  +                     the keyword ``ANY'' may follow.
                        The mnt-routes attribute is optional and multiple.
   \item[mnt-lower]     The mnt-lower attribute may appear in an
                        inetnum, route, as-block or aut-num object.
  @@ -1076,9 +1076,7 @@
                        the mnt-lower attribute specifies a maintainer
                        that can be used to add objects with
                        hierarchical names as described in
  -                     Section~\ref{sec:hierarchical-names}.  If a
  -                     mnt-lower attribute is absent, the mnt-by
  -                     attribute is used.
  +                     Section~\ref{sec:hierarchical-names}.
   \item[reclaim]       The reclaim attribute may appear in as-block,
                        aut-num, inetnum, or route objects.  Any
                        object of the same type below in the hierarchy

This simplifies things and it is what we agreed to at the meeting.

> 3.	Section 8.8 "Query Processing"
> 
> 	Since the document doesn't really deal with queries, is there
> 	a real need for this section? Or could it be deleted? (Not
> 	that I'm particularly worried by it.)

The purpose is to describe the search order in querying and nothing
more.  The new section above providing the scope should make this
clear enough.

> 4.	Examples
> 
> 	I think some examples of object/attribute addition/deletion/modificatio
> n
> 	could be useful in making some concepts unambiguous.

Look for an appendix named "Examples".  I'll put in a few.  I can't
cover ever conceivable case.

> 5.	Editorial
> 	
> 	A.	Typo - section 9.1, definition of mnt-routes, second-last
> 		sentence - "the mnt-lower or mnt-by mnt-by attribute"
> 		Too many mnt-by's.

Thanks but this sentence is gone (see diffs above).

> 	B.	Section 8.5, second-last paragraph
> 
>   "Similarly a no-reclaim attribute cannot be deleted unless there are
>   no overlapped objects for which the submitter is not listed in the
>   maintainer pointed to be the mnt-by of the overlapped object."
> 
> 		I would suggest that it can be difficult to think through
> 		all the negatives. May I suggest something like the
> 		following instead?
> 
>   "Similarly, a submitter may delete a no-reclaim attribute from
>   an object only when that submitter is the only maintainer listed
>   in the mnt-by attributes of any overlapped objects. If the mnt-by
>   attributes of any overlapped objects point to maintainers other than
>   the submitter, then it is not permitted to delete the no-reclaim
>   attribute."

I see your point regarding the lack of clarity.  The substitute text
isn't quite right so I used the following:

  Similarly, a submitter may delete a no-reclaim attribute from an
  object only when that submitter is the only maintainer listed in the
  mnt-by attributes of any overlapped objects. If the submitter is not
  listed in any of the maintainers pointed to by the mnt-by attributes
  for one or more overlapped object, then the submitter is not permitted
  to delete the no-reclaim attribute.

> 								davidw

Thanks for the comments,

Curtis