%ents; ]>
Security Labels in XMPP This document describes the use of security labels in XMPP. The document specifies how security label metadata is carried in XMPP, when this metadata should or should not be provided, and how the metadata is to be processed. &LEGALNOTICE; 0258 Experimental Standards Track Standards Council XMPP Core XEP-0001 sec-label Kurt Zeilenga Kurt.Zeilenga@Isode.COM Kurt.Zeilenga@Isode.COM 0.6 2010-07-30 kdz

Extend catalog handling. Minor editorial changes.

0.5 2009-07-27 kdz

Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.

0.4 2009-07-23 kdz

Update label catalogs to include user input selector.

0.3 2009-03-20 kdz

Add text regarding default bg/fg colors. Correct examples.

0.2 2009-03-10 kdz

Reworked discovery and various updates.

0.1 2009-01-05 psa

Initial published version.

0.0.081203 2008-12-03 kdz

Initial draft.

A security label, sometimes referred to as a confidentiality label, is a structured representation of the sensitivity of a piece of information. A security label is used in conjunction with a clearance, a structured representation of what information sensitivities a person (or other entity) is authorized to access, and a security policy to control access to each piece of information. For instance, message could be labeled as "SECRET", and hence requiring the sender and the receiver to have a clearance granting access to "SECRET" information. &X.841; provides a discussion of security labels, clearances, and security policy.

Sensitivity-based authorization is used in networks which operate under a set of information classification rules, such as in government military agency networks. The standardized formats for security labels, clearances, and security policy are generalized and do have application in non-government networks.

This document describes the use of security labels in &xmpp;. The document specifies how security label metadata is carried in XMPP. It standardizes a mechanism for carrying ESS Security Labels in XMPP, as well as provides for use of other label formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c; security policies.

This content is classified. SECRET ]]> This content is classified. SECRET ]]>

Note: The &IC-ISM; label example is for illustrative purposes only.

The document details when security label metadata should or should not be provided, and how this metadata is to be processed.

This document does not provide:

Such mechanisms may be introduced in subsequent documents.

If an entity supports the XMPP Security Label protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:sec-label:0" in response to a &xep0030; information request. Clients wishing to include a XMPP Security Label element in any stanza they generate SHOULD determine if their server supports the XMPP Security Label protocol. If their server does not support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels as the server not supporting this protocol will generally ignore XMPP Security Labels as they would any other unrecognized element.

As each service domain may have different support for security labels, servers should advertise and clients should perform appropriate discovery lookups on a per service basis.

]]> ... ... ]]>

An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata includes a security label, zero or more equivalent security labels, and optionally display marking data.

This content is classified. SECRET MRUCAgD9DA9BcXVhIChvYnNvbGV0ZSk= ]]>

The security label metadata is carried in an &SECURITYLABEL; element. The &SECURITYLABEL; element which contains one and only one &LABEL; element, zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.

The &LABEL; provides the primary security label. It is commonly issued by the sender under the security policy of that they and their home server operating under. The &LABEL; contains either a single element representing the primary security label or is empty to indicate use of a default.

Each &EQUIVALENTLABEL; represents an equivalent security label under other policies. Each &EQUIVALENTLABEL; contains a single element representing the equivalent label. This element might be used when a recepient is known to hold a clearance under a different policy than the sender.

The &DISPLAYMARKING; element contains a display string for use by implementations which are unable to utilize the applicable security policy to generate display markings. The element may optionally contain two attributes, fgcolor= and bgcolor=, whose values are HTML color strings (e.g., 'red' or '#ff0000'), for use in colorizing the display marking. The fgcolor= default is black. The bgcolor= default is white.

A client can request a catalog for a particular JID by sending a catalog discovery request to the client's server. Where the JID is hosted by some other server, the client's server is expected to produce a suitable catalog (or fail the request). The client's server may, as needed, query catalogs from other servers in order to fulfill the client's request.

While this specification does not preclude a client from directing a catalog request elsewhere, it is noted that catalog returned by a party other than its server may not be directly useable by the client. For instance, the client's server might require a particular only-locally-known label be used in messages to a particular remote JID.

It is RECOMMENDED the server publish catalogs of security label for use by clients.

If catalog is restrictive, as indicated by the restrictive attribute with value of true, the client SHOULD use one of the labels (or no label) offered by the catalog.

One and only one of the items may have a default attribute with value of true. The client should default to this item in cases where the user has not selected an item.

An item may have no label. Such an item offers a choice of sending a stanza without a label.

Each catalog provided should only contain labels for which the client is allowed to use (based upon the user's authorization) in a particular context (such as in chatroom). A catalog may not be include the complete set of labels available for the use by the client in the context.

Note: the single catalog per context approach used here is likely inadequate in enviroments where there are a large number of labels in use. It is expected that a more sophisticated approach will be introduced in a subsequent revision of this specification.

As each service domain may have different support for security labels, servers should advertise and clients should perform appropriate discovery lookups on a per service basis.

To indicate the support for label catalog discovery, a server advertises the urn:xmpp:sec-label:catalog:2 feature. The following pair of examples illustrates this feature discovery.

Each item in the catalog may contain a selector attribute. The value of this attribute represents the item's placement in a hierarchical organization of the items. The value of the selector attribute conforms to the selector-value ABNF production:

"|")* ]]>

where <item> is a sequence of characters not including "|".

A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X" subset of items. This information may be used, for instance, in generating label selection menus in graphical user interfaces.

Note: use of unnecessarily deep hierarchies should be avoided.
]]> ... ... ]]>

The following example pair illustrates catalog discovery. Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).

]]> SECRET CONFIDENTIAL RESTRICTED ]]>

The sensitivity-based access control decisions discussed herein are to be made independently of other access control decisions or other facilities. That is, the sensitivity-based access control decisions are not conditional on other factors.

It is intended that &SECURITYLABEL; elements are only used as prescribed by this document, or other formal specifications. Any other use of &SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD be discarded with, if approrpriate, an error response. Such error responses SHOULD NOT include content from the violating stanza, excepting that necessary to well-formed error responses.

When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. Absence of a &SECURITYLABEL; element implies the stanza has the default label as specified in the governing security policy. Given that the governing policy may not specify a default label, hence denying access to the stanza, supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.

Typically, a client would allow the user to choose populate the &SECURITYLABEL; from one of from a small set of security labels selections known to it (through configuration and/or discovery and/or other means), such as from a pull-down menu. That selection would include appropriate values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.

A policy-aware client may provide the user with an interface allowing the user to produce custom labeling data for inclusion in this set. A policy-aware client SHOULD preclude the user from producing &LABEL; values which the user's own clearance does not grant access to, and SHOULD preclude sending any label which the user's own clearance does not grant access to. Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the display marking prescribed for the &LABEL; under the governing policy, or, if the governing policy prescribes no display marking for the &LABEL;, absent.

A client which receives a stanza with &SECURITYLABEL; element is to promiently display the &DISPLAYMARKING; value. A policy-aware may alternatively promiently display the marking for the &LABEL; prescribed by the governing policy.

Each server is expected to make a number of sensitivity-based authorization decisions. Each decision is made by evaluating an Access Control Decision Function (ACDF) with a governing policy, a clearance, and a security label. The ACDF yields either Grant or Deny.

If the user holds a valid clearance (known to the server) under the governing policy, the clearance input is the user's clearance. Otherwise, if the governing policy provides a default clearance, the clearance input is the default clearance. Otherwise, the clearance input is the nil clearance. The nil clearance is a clearance for which the ACDF always returns Deny when given as the clearance input.

If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; element or one of the &EQUIVALENTLABEL; elements contain an appropriate label, that label input is that label. Otherwise, the label input is the default label provided the governing policy or, if no default label is provided, the nil label. The nil label is a label for which the ACDF always returns Deny when given as the label input.

The term "effective clearance" and "effective label" refer, respectively, to the clearance and label provided as input to the ACDF.

Not all sensitivity-based authorization decisions an XMPP server might make involve a user clearance and/or stanza label. A server may only provide service to users which hold an appropriate clearance as determined by calling the ACDF with the user's clearance and a label associated with the service. A clearance might also be associated with the service to restrict the set of labels may be used in labeling stanzas. Labels and clearances can also be associated with network interfaces, remote servers, chatrooms, pubsub notes.

A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.

A client may provide a &SECURITYLABEL; element in &MESSAGE; stanzas.

A server SHOULD provide a label feature and information discovery for the room.

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

Sending groupchat messages is similiar to sending normal messages, however their are a few differences.

Groupchat messages are addressed to the room. The room clearance must be suitable for the message label, else it should be rejected.

The room's clearance may allow a variety of labels to be used. Not all partipants may be cleared for all labels allowed in the room. The server MUST only deliver messages to partipants for which they are cleared to receive.

Private messages are treated as discussed in the "Use in Instant Messaging" section. (Should private messages be restricted by room's configuration?)

Invitations may be labeled.

This section discusses semantics of &SECURITYLABEL; elements contained in &MESSAGE; stanzas containing a &SUBJECT; element.

The presence of a &SECURITYLABEL; element indicates a request to change the room's label, either to the provided label or, if the element is empty, to unset the room's label. The server is to refuse the request if the requestor is not authorized to change the subject, not cleared for the requested label, or if the server is otherwise unwilling or unable to make the change. If the label change is refused, so must the accompanied subject change. Likewise, if the subject change is refused, so must the accompanied label change.

Upon change of the room's label, the server MUST immediately remove from the room all members whom are not cleared for that label.

In absence of a &SECURITYLABEL; element, the label associated with the room is unchanged.

The room's label can also be changed through room configuration (to be discussed in later revision of this document).

&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a protocol violation.

Presence information is subject to sensitivity-base authorization decisions, however these decisions are made are made using a label associated with the presence resource, such as a chatroom's 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.

Each item may be individually labeled.

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.

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

This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL; elements are designed to hold a range of security labels formats. XML namespaces SHOULD be used to avoid name clashes.

This document is all about authorization, a key aspect of security. Hence, security considerations are discussed through this document.

Security labels generally should be securely bound to the object. This may be accomplished through use of &xmppe2e; signing, or possibly other signing mechanisms.

Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject to any sensitity-based authorization decisions, and may be forwarded throughout the XMPP network. The content of these stanzas should not contain information requiring sensitivity-based dissemination controls.

This document requires no interaction with &IANA;.

It is requested the ®ISTRAR; add the extension's namespaces and schemas to appropriate XMPP registries.

The protocol documented by this schema is defined in XEP-0258: http://www.xmpp.org/extensions/xep-0258.html CSS colors (W3C colors + "orange") Hex encoded RGB Color Display Marking String to be prominently displayed along with labeled object. A Security Label A Display Marking To be prominently displayed The Primary Label An Equivalent Label ]]> A copy of this schema is available at http://www.xmpp.org/schemas/sec-label.xsd.

The protocol documented by this schema is defined in XEP-0258: http://www.xmpp.org/extensions/xep-0258.html Target JabberId Name Description Identifer for current revision, commonly a hash Number of items Restrictive User input selector Default Item A Catalog of Labels ]]> A copy of this schema is available at http://www.xmpp.org/schemas/sec-label-catalog.xsd.

The protocol documented by this schema is defined in XEP-0258: http://www.xmpp.org/extensions/xep-0258.html An S/MIME ESS SecurityLabel [RFC2634] Value is the base64 encoding of the BER/DER encoding of an ASN.1 ESSSecurityLabel type as defined in RFC 2634. ]]> A copy of this schema is available at http://www.xmpp.org/schemas/sec-label-ess.xsd.