[IETF-IDRM] Re: [IDRM] draft-irtf-idrm-handle-system-00.txt

[Mark Baugher]

Hi Sam,
   http://search.ietf.org/internet-drafts/draft-rescorla-sec-cons-03.txt
provides some suggestions on writing security sections and I'd
be happy to help.  Regarding point 3, below, we can discuss this
better in the context of the next two drafts.  I need to go back and
review some of the points you mentioned in your note.

Mark
At 01:36 AM 5/26/2001 -0400, Sam X. Sun (@S2000) wrote:
>Mark,
>
>These are very good points, and my comments are below...
>
>----- Original Message -----
>From: "Mark Baugher" <mbaugher@cisco.com>
>To: <ietf-idrm@lists.elistx.com>
>Cc: <ssun@cnri.reston.va.us>; <llannom@cnri.reston.va.us>
>Sent: Friday, May 25, 2001 12:36 AM
>Subject: Re: [IDRM] draft-irtf-idrm-handle-system-00.txt
>
>
> > Here are the remaining questions and comments from the
> > draft-irtf-idrm-handle-system-00.txt.  Regarding my previous comments,is
>it
> > accurate to say that the Handle System protocols could in principle be
>used
> > with a variety of different servers/resolvers including DDDS?
> >
> > I have five points.
> >
> > 1)  Section 1, under "Secured Named Service" describes specific
> > cryptographic mechanisms but "Distributed Administration Service" does
> > not.  By briefly mentioning specific security and cryptographic mechanisms
> > in this document, rather than in the later documents where they are
> > specified, I think you raise more questions than you can answer in an
> > Overview document.
>
>This is good. I will add that to the next version of the draft.
>
> >
> > 2)  Section 2, para 2, suggests that a persistent name can never be moved
> > between naming authorities.  If all rights to a content work were
> > completely transferred from a corporation operating naming authority x, to
> > one operating naming authority y, then the content work will still have x
> > in its name.  This seems like a problem to me.  The DOI Handbook makes a
> > point about handles being "dumb numbers," but these handles reveal
> > information that will persist even when no longer valid.
> >
>
>Larry has addressed this, and I will follow up on that thread in a separate
>message...
>
> > 3) Section 4, para 3, last sentence, defines an enormous PKI for a global
> > namespace and I have some doubts about providing a security service for
> > referencing potentially any content item in the world.  It is a
>scalability
> > issue if the handle system is not designed for smaller-scale and private
> > use or if the trust and security mechanisms cannot be tailored to the
>needs
> > of individual organizations and national considerations.  There are large
> > political issues here.  This is the main problem I have with the Handle
> > System.  We may have an opportunity to consider this at length when
> > discussing the next two drafts.
>
>Would you be more specific on those doubts so that we can discuss them here?
>Basically, the whole section is to outline the handle system security
>service, and the paragraph (para 3) outlines how service integrity and
>client authentication are carried out. It is stated in the protocol draft
>that each local handle service (hosted by individual organization) can add
>additional local policy regarding access control. However, how it is done is
>to be decided by each individual deployment. We expect that to be something
>conforming to KeyNote (also called PolicyMaker earlier). Are you suggesting
>that we should point that out here? Also, I'm not understanding the
>political issues here, could you elaborate?
>
>It might be worth noting that handle system security is only to address the
>transport security, i.e. the secure data transport between the handle system
>client and server. It does leave the hook for checking out content
>credentials, but that's for applications to take advantage of. The handle
>system is not a PKI framework by itself, but we think applications can be
>built on top of it to make PKI deployment easier.
>
>
> > 4) Section 4, para 5, should discuss the assets to be protected (e.g.
> > handle metadata), the risks to those assets (e.g. corruption of handle
> > metadata), and the sources of threats (e.g. hackers seeking fame or
> > criminals seeking fortune).  I believe the sentence "To trust a Local
> > Handle Service means to trust that it will correctly respond with data
>that
> > was entered by the administrator" is a too general to be useful.
> >
>
>What I will do is to make a separate section to address "security
>considerations" as you mentioned earlier, and add these into it. Could you
>help coming up with the words? I will rephrase the sentence "to trust a ..."
>to make it more specific.
>
>
> > 5) The document needs a security section and should follow the other
> > guidelines for formatting and mandatory sections of RFC 2223.
> >
>
>Section 4 was intended to cover this. I will make a separate section to
>address this specifically.
>
>
>Thanks,
>Sam