%ents; <label/>"> <catalog/>"> <item/>"> <securitylabel/>"> <displaymarking/>"> <equivalentlabel/>"> <headline/>"> <identity/>"> <publish/>"> <item-not-found/>"> <not-authorized/>"> <not-acceptable/>"> <insufficient-clearance/>"> <items/>"> <associate/>"> ]>
Security Labels in PubSub 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 Standards Track Standards Council XMPP Core XEP-0060 XEP-0258 NOT_YET_ASSIGNED Ashley Ward ashley.ward@surevine.com ashward@jabber.org http://www.surevine.com/ 0.0.1 2012-06-08 asw

First draft.

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;.

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

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 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 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 ]]>

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.

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 ]]>

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).

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 ]]> 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.

]]> ]]>
  1. 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. Items MUST only be accessible by entities with the appropriate Clearance
  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

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

]]>

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 ... ]]>

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

This document requires no interaction with the &IANA;

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.
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.