RE: New security considerations for model

["Mark Day" <markday@cisco.com>]

I just sent the new model draft in to the secretariat shortly before
receiving this message, so I think I'm going to treat this as an early
comment in response to the last call (coming in the next day or so, after
that draft is available at the IETF site).

The most valuable part of your comment (to me, anyway) is pointing out that
the security considerations section is introducing terminology.  Given that
the model document is all about terminology, those terms should be defined
in the body of the document.

I am less comfortable with the proposed approach of "you can implement some
or all of this, but you only get to call it 'secure' if it's all
implemented." I think the IESG tends toward a philosophy more like "you have
to implement all of this, but users can choose not to use some or any of
it."

--Mark

> -----Original Message-----
> From: Jim Busse [mailto:jim.busse@necsam.com]
> Sent: Thursday, April 11, 2002 2:44 PM
> To: Mark Day; cdn@ops.ietf.org
> Subject: RE: New security considerations for model
>
>
> Mark:
>
> I have been thinking about our content network here, and I would like to
> propose a couple of changes to your model.
>
> I think the categories that you've raised are important, and should be
> considerations.  In addtion, in some other working groups, we've been
> discussing that in a fully secure implementation, a means must be provided
> to ensure that the content provided remains intact, and that only
> the owner
> could change or alter the content.  If the owner would choose to give up
> this right, then the content cannot be called "secure".
>
> To implement some of the model categories, I think we have draft and
> proposed standards that may be specified.  For example, we have secure
> physical, link-layer, application layer, etc protocols.  After
> the CDN group
> decides which of them are appropriate, it would be nice to bounce the
> requirements and suggestions for implemetations through the saag
> mail-list.
>
>
> So what I did was try to re-write what you did to separate out the
> implementation strategy from the terminology, and add sections on
> implementation, as well as secured content.  Here it is:
>
> 6. Security Considerations
>
>    This document defines terminology and concepts for content
>    internetworking.  The terminology itself is not intended to
>    introduce any security-related issues.  The implementation of content
>    internetworking concepts does raise some security-related issues,
>    which we identify in broad categories below.  Other CDI documents
>    will address their specific security-related issues in more detail.
>
> Terminology:
>    Secure relationship establishment:  content internetworking's provision
>    of means to ensure that content networks are internetworking only with
>    other authenticated and authorized content networks.
>
>    Secure content transfer:  content internetworking's provision
> of means to
>    ensure content is delivered in an unmodified, intact form, over a
>    pre-established fully secure route.
>
>    Secure Meta-content transfer:  content internetworking's provision of
>    means to ensure authorization, accounting, and authentication data be
>    delivered in an umodified, intact form, over a pre-established fully
>    secure route.
>
>    Secured Content:  content internetworking's provision of means to
>    ensure that Contentdelivered or available through the content
> internetwork
>    is secured from unauthorized and unauthenticated changes
>
>
>
> Implementations:
>    Content internetworking implementations may choose to implement any
>    or all of the broad categories listed in Terminology.  For a fully
>    secure content internetwork, the implementation MUST provide secure
>    relationship establishment, secure content transfer, secure
> meta-content
>    transfer, and secured content.
>
>    Less-secure implementations will substitute or eliminate categories.
>    For example, a fully-captive network, secured by physical connection
>    limitations, may choose to not implement the secure relationship
>    establishment.  However, the scalability of this implementation may
>    be limited  These kinds of implementations MUST NOT be called or
>    labeled "secure".
>
> Jim Busse
>
> -----Original Message-----
> From: Mark Day [mailto:markday@cisco.com]
> Sent: Friday, April 05, 2002 7:31 AM
> To: cdn@ops.ietf.org
> Subject: New security considerations for model
>
>
> I've been preparing the model document for its WG last call.  Most of the
> necessary changes are quite minor, but I realized that the security
> considerations section is broken.  The current text consists
> primarily of a
> reference to the architecture document.  This is the same architecture
> document that we want to revise since it's fallen out of sync
> with the other
> docs, so it doesn't seem great to have a normative reference to it as the
> answer for security considerations.
>
> I wrote the following as a replacement for the current security
> considerations section in draft-ietf-cdi-model-00. Comments are
> welcome.  In
> the absence of comments, I'll put in this text and start the last call on
> Tuesday next week.
>
> --Mark
>
> 6. Security Considerations
>
>    This document defines terminology and concepts for content
>    internetworking.  The terminology itself does not introduce any
>    security-related issues.  The implementation of content
>    internetworking concepts does raise some security-related issues,
>    which we identify in broad categories below.  Other CDI documents
>    will address their specific security-related issues in more detail.
>
>    Secure relationship establishment: content internetworking must
>    provide means to ensure that content networks are internetworking
>    only with other content networks as intended.  It must be possible to
>    prevent unauthorized internetworking or spoofing of another network's
>    identity.
>
>    Secure content transfer: content internetworking must support
>    content-network mechanisms that ensure content is delivered only as
>    appropriate, even when the delivering network is not the originating
>    network.  Content internetworking must allow for mechanisms to
>    prevent theft or corruption of content.
>
>    Secure meta-content transfer: content internetworking must support
>    the movement of accurate, reliable, auditable information about costs
>    and performance between content networks.  Content internetworking
>    must allow for mechanisms to prevent the diversion or corruption of
>    accounting data and similar meta-content.
>