From f54258e364ba92cf8feb52725bdcf558b447d5fd Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Tue, 19 Jun 2012 10:30:09 -0600 Subject: [PATCH] revised version from authors --- inbox/pubsub-labels.xml | 819 ++++++++++++++++++++++++++++++++++++---- 1 file changed, 736 insertions(+), 83 deletions(-) diff --git a/inbox/pubsub-labels.xml b/inbox/pubsub-labels.xml index 924b82d9..d7045fea 100644 --- a/inbox/pubsub-labels.xml +++ b/inbox/pubsub-labels.xml @@ -11,13 +11,24 @@ <headline/>"> <identity/>"> <publish/>"> + <item-not-found/>"> + <not-authorized/>"> + <not-acceptable/>"> + <insufficient-clearance/>"> + <items/>"> + <associate/>"> + + ]>
Security Labels in PubSub - This document describes an extension to XEP-0258 (Security Labels in XMPP) to allow for the use of security labels in PubSub. This document describes - how security label metadata can be applied to the various elements within PubSub, including nodes and items. + This specification defines an extension to XEP-0258 (Security Labels) to allow for the + use of security labels in XEP-0060 (Publish-Subscribe). This document describes how security + label metadata can be applied to the various elements within Publish-Subscribe, including nodes + and items. + &LEGALNOTICE; xxxx ProtoXEP @@ -36,69 +47,406 @@ Ashley Ward ashley.ward@surevine.com - ashley.ward@surevine.com - - - Lloyd - Watkin - lloyd.watkin@surevine.com - lloyd.watkin@surevine.com + ashward@jabber.org + http://www.surevine.com/ 0.0.1 - 2012-05-16 + 2012-06-08 asw

First draft.
-

This XEP defines a method to include Security Labels (as defined in &xep0258;) into PubSub (as - defined in &xep0060;). Security labels (sometimes referred to as confidentiality labels) blah - blah blah

+

The use of security labels within XMPP is currently defined in &xep0258;. This, however, does + not cover the use of security labels within &xep0060;. This XEP defines a method to include + security labels into publish-subscribe.

+

This allows content publishers to limit visibility of any sensitive published items to only + those users with appropriate clearance to view them.

+

This document does not deal with the semantics of a Security Label or how the security policy + is applied to decisions regarding Security Labels and Clearances.

+

This document should be read in conjunction with &xep0060; and &xep0258;.

 -

STRONGLY RECOMMENDED.

+
    +
  • A publisher MUST be able to apply a Security Label to items within a node.
    • +
  • A node creator SHOULD be able to apply a Security Label to a node (this controls which + entities can access the node).
    • +
  • A node creator SHOULD be able to apply a Clearance to a node (this controls which Security + Labels can be applied to items within the node).
    • +
  • A node creator MAY be able to apply a default Security Label to a node (this applies to + items published to the node without a Security Label).
    • +
  • Node lists returned by the server SHOULD NOT contain nodes that the requesting entity is + not Cleared to view.
    • +
  • Item lists returned by the server MUST NOT contain items that the requesting entity is not + Cleared to view.
    • +
  • A client SHOULD only publish items to a node that are compatible with the Clearance of the + node (if the node has a Clearance), and a server MUST NOT store such items against the node + or send any notifications of any such items to subscribers.
    • +
  • Server responses from a request involving a node that the entity is not Cleared to view + SHOULD be identical to a response as if that node did not exist.
    • +
  • Server responses from a request involving an item that the entity is not Cleared to view + MUST be identical to a response as if that item did not exist.
    • +
  • A server MUST NOT notify or deliver items to an entity that the entity does not have + appropriate Clearance to view.
    • +
-

OPTIONAL.

+

In addition to the Glossary defined for &xep0060; the following terms are used:

-
Security Label
-
The schema defined in &xep0258; with the XML namespace "urn:xmpp:sec-label:0"
+ +
Security Label
+
+

A label that can be applied to content to restrict the visibility of the content to + entities with appropriate Clearance.

+

The schema is defined in &xep0258; with the XML namespace "urn:xmpp:sec-label:0".

+
+ + +
Clearance
+
A collection of Security Labels that an entity is authorized to access.
+ + +
Cleared
+
An entity is Cleared to access content if the Access Control Decision Function (ACDF) of + the server yields a Grant given the entity's Clearance, the Security Label of the + content and the governing security policy.
+
-

This section defines the use cases for and protocols to be used by any entity wishing to - publish or subscribe to content with a Security Label

- -

A server SHOULD provide a label feature and information discovery for each node

-

Clients SHOULD discover label feature and information on a per-node basis

+

This section defines the additions and caveats for the use cases and protocols defined in + &xep0060;.

+ +

A Security Label aware client SHOULD discover support for Security Labels within the + &xep0060; service domain. If the service domain does not report support for Security Labels + then the client SHOULD NOT publish with Security Labels.

+ + + + ]]> + + + ... + + ... + + + ]]> +

A server SHOULD provide label feature and information discovery for each node.

+

Clients SHOULD discover label feature and information on a per-node basis.

+ + + + ]]> + + + ... + + ... + + + ]]> +

A server SHOULD provide Security Label catalog discovery for each node.

+

Clients SHOULD discover the Security Label catalog on a per-node basis.

+

The server SHOULD limit the catalog for a node to those labels that are compatible with any + Clearance associated with the node.

+ + + + ]]> + + + + + SECRET + + + + + + CONFIDENTIAL + + + + + + RESTRICTED + + + + + + + ]]> -

The protocol for node discovery is as defined in &xep0060;, but with the caveat that the - server SHOULD NOT return any nodes that have a security marking that the entity is not - authorised to view.

-

If a service implements a hierarchy of nodes (via - Collection Nodes) - then the server MUST also prevent access to any child nodes of any nodes which the entity - is not authorised to view, even if the node's individual security label would otherwise - allow this

+

The server SHOULD NOT return any nodes that have a Security Label that the entity is not + Cleared to view.

+ + + + ]]> + + + + + + UNCLASSIFIED + + + + SECRET + + + + + ]]> - +

The item list MUST NOT contain items that the entity is not Cleared to view.

+

The server SHOULD return an &ITEMNOTFOUND; error if the entity is not Cleared to view + the node.

+

See Subscriber Use Cases: Retrieve Items from a + Node for more details of how Security Labels are respresented in the server response. +

+ + + + ]]> + + + + + + + + + UNCLASSIFIED + + + + SECRET + + + + + ]]> + +

The server SHOULD return an &ITEMNOTFOUND; error if the subscriber is not Cleared to view + the node.

+ + +

The server SHOULD return an &ITEMNOTFOUND; error if the subscriber is not Cleared to view the + node.

+

The item list MUST NOT contain items that the subscriber is not Cleared to view.

+

The server MUST attach relevant &SECURITYLABEL; child elements to the &ITEMS; element.

+

Each of these &SECURITYLABEL; elements MUST posess an 'id' attribute (from the &NSMAIN; + namespace) which is unique within the stanza.

+

The server SHOULD normalise the elements so that multiple &ITEM; elements with the same + Security Label reference the same &SECURITYLABEL; element; However, the server might + instead include a &SECURITYLABEL; element for each &ITEM; element regardless of whether there + are duplicates.

+

Each &ITEM; that has a Security Label MUST posess a 'label' attribute (from the &NSMAIN; + namespace) that references the id of the relevant &SECURITYLABEL;.

+

The server SHOULD NOT include &SECURITYLABEL; elements which are not referenced within the + stanza.

+ + + + + + The Uses of This World + +O, that this too too solid flesh would melt +Thaw and resolve itself into a dew! + + + tag:denmark.lit,2003:entry-32396 + 2003-12-12T17:47:23Z + 2003-12-12T17:47:23Z + + + + + Ghostly Encounters + +O all you host of heaven! O earth! what else? +And shall I couple hell? O, fie! Hold, hold, my heart; +And you, my sinews, grow not instant old, +But bear me stiffly up. Remember thee! + + + tag:denmark.lit,2003:entry-32396 + 2003-12-12T23:21:34Z + 2003-12-12T23:21:34Z + + + + + Alone + +Now I am alone. +O, what a rogue and peasant slave am I! + + + tag:denmark.lit,2003:entry-32396 + 2003-12-13T11:09:53Z + 2003-12-13T11:09:53Z + + + + + Soliloquy + +To be, or not to be: that is the question: +Whether 'tis nobler in the mind to suffer +The slings and arrows of outrageous fortune, +Or to take arms against a sea of troubles, +And by opposing end them? + + + tag:denmark.lit,2003:entry-32397 + 2003-12-13T18:30:02Z + 2003-12-13T18:30:02Z + + + + UNCLASSIFIED + + + + SECRET + + + + + +]]> + - -

Each Item within a &PUBLISH; element may be individually labelled with a &SECURITYLABEL;

-

The server SHOULD apply the default label for the node to any items which do not contain a - &SECURITYLABEL;

- +

A &PUBLISH; element MAY contain a &SECURITYLABEL; which the service must apply to all the + items within the &PUBLISH;.

+

If a publisher wishes to publish multiple items with different Security Labels, they MUST + send multiple &iq; stanzas - one for each Security Label.

+

The server SHOULD apply the default label for the node to any items within a &PUBLISH; which + does not contain a &SECURITYLABEL;.

+

Any &SECURITYLABEL; within a &PUBLISH; should be compatible with any Clearance associated + with the node, else the service MUST return an &INSUFFICIENTCLEARANCE; error.

+

If a publisher attempts to publish to a node which the publisher is not Cleared to view, the + service SHOULD return an &ITEMNOTFOUND; error.

+

A publisher SHOULD not attempt to publish an item with a Security Label which is not suitable + to the Clearance of the node.

+

Any &PUBLISH; with a &SECURITYLABEL; should be compatible with the Clearance of the + publishing entity, else the server MUST return an &INSUFFICIENTCLEARANCE; error.

+ + type='set'> @@ -117,21 +465,25 @@ And by opposing end them? 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z - - UNCLASSIFIED - - + + UNCLASSIFIED + + - ]]> - -

The service then notifies appropriately cleared subscribers

- + ]]> +

The service then notifies appropriately Cleared subscribers. The server MUST NOT notify + subscribers that do not have appropriate Clearance to view the item.

+

The server MUST include the &SECURITYLABEL; element as a child of the &MESSAGE; stanza. The + server MUST NOT include the &SECURITYLABEL; element within the &ITEMS; element.

+

The Security Label applies to the entire message (including all the items within the &ITEMS; + element and any &BODY; if the entity's subscription is so configured).

+ @@ -150,60 +502,361 @@ And by opposing end them? 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z - - UNCLASSIFIED - - + + UNCLASSIFIED + + + + ]]> + + + + + + + + UNCLASSIFIED + + + + ]]> + + +

If a publisher attempts to publish to a node with a Security Label that is incompatible + with the Clearance of the node then the server MUST return an &INSUFFICIENTCLEARANCE; + error.

+ + + + + + + ]]> + + +

If a publisher attempts to publish to a node with a Security Label that is incompatible + with the Clearance of the publisher then the server MUST return an &INSUFFICIENTCLEARANCE; + error.

+ + + + + + ]]> + + + + +

The server SHOULD return an &ITEMNOTFOUND; error if the subscriber is not Cleared to view + the node or item.

+

The server MUST NOT send retract requests to subscribers who are not Cleared to view the + item.

+ + + + +

The server SHOULD allow for configuration of Security Label parameters for a node via node + configuration mechanisms. This approach is intended to be ad-hoc and so this section is + intended to be illustrative of one possible approach. Implementations are free to utilize + other approaches.

+

The server MUST disallow a node being created that has a default Security Label that is not + within the clearance of the node.

+ + + + + ... + + Catalog:UNCLASSIFIED + + + + + + + + + Catalog:UNCLASSIFIED + + + + + + + + + + + ]]> + +

Changing the Security Label or Clearance of an existing node is problematic for a number of + reasons:

+
    +
  • Subscribers may no longer be Cleared to view a node to which they are already subscribed +
    • +
  • Existing items persisted within a node may be of a higher Security Label than the new + node clearance allows
    • +
+

For these reasons an implementation MAY wish to disallow changes to the Security Label of + an existing node with subscribers, disallow changes to the Clearance of a node with items, + or limit the options within the node configuration to those which do not cause a conflict. +

+

If an implementation chooses to allow a change to the clearance of a node that conflicts + with the Security Label of existing items within the node then the server MUST purge the + node of all items which are no longer within the updated clearance of the node, with or + without notifying subscribers.

+

If an implementation chooses to allow a change to the Security Label of the node that + causes conflicts with existing subscribers to the node then the server MUST remove all + subscriptions from subscribers that are no longer Cleared to view the node. The server MUST + notify these subscribers. The server SHOULD send a Node Deletion notification, but might + instead send a Subscription Cancellation notification if entities are to be aware of the + existence of nodes they do not have Clearance to view.

+

The server MUST prevent a change to the Security Label of the node which would prevent a + node owner from accessing the node.

+ + + + ]]> - - -

If the node is configured not to include payloads

- + + + + + + ]]> + -

OPTIONAL.

    -
  1. Server responses from a request for a node which the entity is not authorised to view MUST - be identical to a response as if that node did not exist. - An entity SHOULD NOT be aware of the existance of nodes or items that they do + not have appropriate Clearance to view (But see Implementation Notes: + Access to items for which the entity is not Cleared)
    2. +
  2. Items MUST only be accessible by entities with the appropriate Clearance
    3. +
  3. If a node has an associated Clearance then the node MUST only deal with (i.e. + persist or notify) items which are compatible with the Clearance
    4. +
+ + + +

The protocol defined has the intention that, as far as possible, an entity should be unaware of + the existence of any nodes or items which they are not Cleared to view. Therefore server + responses to a request for a node which the entity is not Cleared to view SHOULD be identical to + a response as if that node did not exist (See BR1), i.e. an + &ITEMNOTFOUND; error is returned

+ + type='error'> - ]]> - - - - -

OPTIONAL.

- - -

OPTIONAL.

- - -

OPTIONAL.

+ ]]> +

It is worth noting that there are certain situations where this is impossible, for example if + an entity wishes to create a node with the same NodeID as an existing node that they are not + Cleared to view.

+

Alternatively, an implementation might wish to relax this rule and allow entities to become + aware of nodes they do not have Clearance to view. In this case an &INSUFFICIENTCLEARANCE; + error MAY be returned instead.

+ + +

If a service implements &xep0248; then there will need to be some consideration of node + and item visibility within the node hierarchy.

+

Due to the complexity of the access control policies involved, an implementation MAY choose + to do one or more of the following to simplify the implementation:

+
    +
  • Prevent the use of Security Labels and/or Clearances on collection nodes.
    • +
  • Prevent publishing items with Security Labels to non-orphan leaf nodes (i.e. leaf nodes + with an association to a collection node).
    • +
  • Prevent the association of leaf nodes containing Security Labelled items with collection + nodes.
    • +
  • Prevent the association of Security Labelled nodes with collection nodes.
    • +
+

The rules and protocols defined elsewhere in this document are generally applicable to + collection nodes with the following additions:

+ +

A collection node MUST NOT forward a publish notification with a Security Label that is + incompatible with the Clearance of the collection node.

+

A collection node SHOULD NOT forward a node change notification + (create/update/delete/associate) where the Security Label of the affected node is + incompatible with the Clearance of the collection node.

+

The server SHOULD NOT send node change notifications to any entity where the Security Label + of the affected node is incompatible with the Clearance of the entity.

+ + +

The server MUST NOT return any items from leaf nodes where the individual Security Label of + the item is incompatible with the Clearance of the requesting entity.

+

The server SHOULD NOT return any items from any associated nodes where the Security Label + of the leaf node, or any intermediate collection node on the node graph, is incompatible + with the Clearance of the requesting entity.

+ + +

A server SHOULD NOT allow an entity to associate, either through configuration or through + an &ASSOCIATE; statement, a child node to a collection node if the Security Label of the + child node is incompatible with the Clearance of the collection node.

+ + + +

An implementation might choose to impose some kind of structure on items within a node. For + example: items may include a list of blog posts, but may also include comments relating to + specific blog posts from other users.

+

An implementation MAY apply different logic to the visibility of items in this case, + perhaps by disallowing access to comment items if the requester is not Cleared to view the + associated blog post item, even if the individual Security Label on the comment item would not + normally prevent access.

+

However, the server MUST NOT allow access to an item if the requester is not Cleared to view + the Security Label for the item (i.e. this mechanism must only be used to further restrict + access to items and must not be used to widen access).

+ + +

An implementation may wish to allow a subscriber to limit the sensitivity of items which are + delivered for a certain subscription. For example: a subscriber may wish to only receive + notifications of items which are unclassified, even if the node has a higher clearance.

+

One way this could be implemented is by expanding the Data Form for the subscription options. +

+ + + + + ... + + Catalog:UNCLASSIFIED + + + + + + ... + + + + + ]]> + -

REQUIRED.

+

This document is an extension to &xep0258; and therefore any security considerations noted in + that document will also apply to this document.

 -

REQUIRED.

+

This document requires no interaction with the &IANA;

 -

REQUIRED.

+ +

This specification defines the following XML namespaces:

+
    +
  • &NSMAIN;
    • +
  • &NSERRORS;
    • +
+ + + If the protocol defined in this specification undergoes a revision that is not fully + backwards-compatible with an older version, the XMPP Registrar shall increment the protocol + version number found at the end of the XML namespaces defined herein, as described in Section 4 + of XEP-0053. + -

REQUIRED for protocol specifications.

+ + + + + + + + The protocol documented by this schema is defined in + XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html + + + + + + + References an "id" value in a <securitylabel> element. The referenced + Security Label MUST then be applied to the element content. + + + + + + + + Defines a unique (across the document) id for a <securitylabel> element that can be + referenced from a "label" attribute. + + + + + + ]]> + + + + + + + + This namespace is used for error reporting only, as + defined in XEP-xxxx: + + http://xmpp.org/extensions/xep-xxxx.html + + + + + + + ]]> + + + + +

Thanks to Dave Cridland, John Atherton, Kurt Zeilenga, Lloyd Watkin, Ralph Meijer and Stephen + Welch for their contributions.