Security Labels in PubSub

%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; 0314 Experimental 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.1 2012-07-27 psa

Initial published version.

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

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.

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 MQYCAQQGASk= CONFIDENTIAL MQYCAQMGASk RESTRICTED MQYCAQIGASk= ]]>

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

]]> UNCLASSIFIED MQMGASk= SECRET MQYCAQIGASk= ]]>

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 MQMGASk= SECRET MQYCAQIGASk= ]]>

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 MQMGASk= SECRET MQYCAQIGASk= ]]>

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

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 MQMGASk= ]]> UNCLASSIFIED MQMGASk= ]]>

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.

]]> ]]>

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