mirror of https://github.com/moparisthebest/xeps
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
889 lines
43 KiB
889 lines
43 KiB
<?xml version='1.0' encoding='UTF-8'?> |
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [ |
|
<!ENTITY % ents SYSTEM 'xep.ent'> |
|
<!ENTITY LABEL "<tt><label/></tt>"> |
|
<!ENTITY CATALOG "<tt><catalog/></tt>"> |
|
<!ENTITY ITEM "<tt><item/></tt>"> |
|
<!ENTITY SECURITYLABEL "<tt><securitylabel/></tt>"> |
|
<!ENTITY DISPLAYMARKING "<tt><displaymarking/></tt>"> |
|
<!ENTITY EQUIVALENTLABEL "<tt><equivalentlabel/></tt>"> |
|
<!ENTITY HEADLINE "<tt><headline/></tt>"> |
|
<!ENTITY IDENTITY "<tt><identity/></tt>"> |
|
%ents; |
|
]> |
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> |
|
<xep> |
|
<header> |
|
<title>Security Labels in XMPP</title> |
|
<abstract>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.</abstract> &LEGALNOTICE; |
|
<number>0258</number> |
|
<status>Draft</status> |
|
<type>Standards Track</type> |
|
<sig>Standards</sig> |
|
<approver>Council</approver> |
|
<dependencies> |
|
<spec>XMPP Core</spec> |
|
<spec>XEP-0001</spec> |
|
</dependencies> |
|
<supersedes/> |
|
<supersededby/> |
|
<shortname>sec-label</shortname> |
|
<schemaloc> |
|
<ns>extension</ns> |
|
<url>http://xmpp.org/schemas/sec-label.xsd</url> |
|
</schemaloc> |
|
<schemaloc> |
|
<ns>catalog</ns> |
|
<url>http://xmpp.org/schemas/sec-label-catalog.xsd</url> |
|
</schemaloc> |
|
<schemaloc> |
|
<ns>esssecuritylabel</ns> |
|
<url>http://xmpp.org/schemas/sec-label-ess.xsd</url> |
|
</schemaloc> |
|
<author> |
|
<firstname>Kurt</firstname> |
|
<surname>Zeilenga</surname> |
|
<email>Kurt.Zeilenga@Isode.COM</email> |
|
<jid>Kurt.Zeilenga@Isode.COM</jid> |
|
</author> |
|
<revision> |
|
<version>1.1.1</version> |
|
<date>2018-11-03</date> |
|
<initials>pep</initials> |
|
<remark>Fix a bunch of typos, batch-style.</remark> |
|
</revision> |
|
<revision> |
|
<version>1.1</version> |
|
<date>2013-04-08</date> |
|
<initials>kdz</initials> |
|
<remark><p>Clarify catalogs are temporal objects. Offer client handling suggestions.</p></remark> |
|
</revision> |
|
<revision> |
|
<version>1.0</version> |
|
<date>2011-11-10</date> |
|
<initials>psa</initials> |
|
<remark><p>Per a vote of the XMPP Council, advanced specification to Draft; corrected version of catalog namespace in schema.</p></remark> |
|
</revision> |
|
<revision> |
|
<version>0.10</version> |
|
<date>2011-11-03</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Address last call comments.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.9</version> |
|
<date>2011-09-21</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Add optional <tt>from=</tt> attribute to catalog element for S2S requests. Make |
|
editorial changes.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.8</version> |
|
<date>2011-08-11</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Correct catalog schema.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.7</version> |
|
<date>2011-03-08</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Illustrate XEP Multi-User Chat room security label configuration. Make |
|
clarifications and minor editorial changes.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.6</version> |
|
<date>2010-07-30</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Extend catalog handling. Minor editorial changes.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.5</version> |
|
<date>2009-07-27</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Remove &LABEL;/&EQUIVALENTLABEL; <tt>type=</tt> attribute. Clarify label catalog |
|
discovery. Clarify syntax of <tt>selector=</tt> attribute.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.4</version> |
|
<date>2009-07-23</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Update label catalogs to include user input selector.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.3</version> |
|
<date>2009-03-20</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Add text regarding default bg/fg colors. Correct examples.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.2</version> |
|
<date>2009-03-10</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Reworked discovery and various updates.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.1</version> |
|
<date>2009-01-05</date> |
|
<initials>psa</initials> |
|
<remark> |
|
<p>Initial published version.</p> |
|
</remark> |
|
</revision> |
|
<revision> |
|
<version>0.0.081203</version> |
|
<date>2008-12-03</date> |
|
<initials>kdz</initials> |
|
<remark> |
|
<p>Initial draft.</p> |
|
</remark> |
|
</revision> |
|
</header> |
|
|
|
<section1 topic="Introduction" anchor="intro"> |
|
<p>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, a message could be labeled |
|
as "SECRET", and hence requiring the sender and the receiver to each have a clearance |
|
granting access to "SECRET" information. &X.841; provides a discussion of security |
|
labels, clearances, and security policy.</p> |
|
<p>Sensitivity-based authorization is used in networks which operate under a set of |
|
information classification rules, such as in government agency networks. The |
|
standardized formats for security labels, clearances, and security policy are |
|
generalized and do have application in non-government networks.</p> |
|
<p>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.</p> |
|
<example caption="Message with ESS Security Label"><![CDATA[ |
|
<message to='romeo@example.net' from='juliet@example.com/balcony'> |
|
<body>This content is classified.</body> |
|
<securitylabel xmlns='urn:xmpp:sec-label:0'> |
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking> |
|
<label><esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'> |
|
MQYCAQQGASk= |
|
</esssecuritylabel></label> |
|
</securitylabel> |
|
</message> |
|
]]></example> |
|
<example caption="Message with IC-ISM Label"><![CDATA[ |
|
<message to='romeo@example.net' from='juliet@example.com/balcony'> |
|
<body>This content is classified.</body> |
|
<securitylabel xmlns='urn:xmpp:sec-label:0'> |
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking> |
|
<label><icismlabel xmlns='http://example.gov/IC-ISM/0' classification='S' |
|
ownerProducer='USA'/></label> |
|
</securitylabel> |
|
</message> |
|
]]></example> |
|
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p> |
|
|
|
<p>The document details when security label metadata should or should not be provided, and |
|
how this metadata is to be processed.</p> |
|
|
|
<p>This document does not provide:</p> |
|
<ul> |
|
<li>any mechanism for a client to discover the security policy in force at its home |
|
server, or any other server;</li> |
|
<li>any mechanism for a client to discover the user's clearance, or the clearance of |
|
associated with any resource; nor</li> |
|
<li>any administrative mechanism for a client to configure configure policy, |
|
clearance, and labels of any resource.</li> |
|
</ul> |
|
<p>Such mechanisms may be introduced in subsequent documents.</p> |
|
|
|
<p>This document does not discuss how one might securely bind a security label to a stanza. |
|
It is expected a subsequent document will tackle this topic.</p> |
|
</section1> |
|
|
|
<section1 topic="Discovering Feature Support" anchor="disco"> |
|
<p>An entity (client or server) which supports the XMPP Security Label protocol MUST report |
|
that fact by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in |
|
response to a &xep0030; information request.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<example caption="Service Discovery information request"><![CDATA[ |
|
<iq type='get' |
|
from='user@example.com/Work' |
|
to='example.com' |
|
id='disco1'> |
|
<query xmlns='http://jabber.org/protocol/disco#info'/> |
|
</iq> |
|
]]></example> |
|
<example caption="Service Discovery information response"><![CDATA[ |
|
<iq type='result' |
|
from='example.com' |
|
to='user@example.com/Work' |
|
id='disco1'> |
|
<query xmlns='http://jabber.org/protocol/disco#info'> |
|
... |
|
<feature var='urn:xmpp:sec-label:0'/> |
|
... |
|
</query> |
|
</iq> |
|
]]></example> |
|
</section1> |
|
|
|
<section1 topic="Protocol" anchor="protocol"> |
|
<p>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.</p> |
|
<example caption="Labeled Message"><![CDATA[ |
|
<message to='romeo@example.net' from='juliet@example.com/balcony'> |
|
<body>This content is classified.</body> |
|
<securitylabel xmlns='urn:xmpp:sec-label:0'> |
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking> |
|
<label> |
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0' |
|
>MQYCAQIGASk=</esssecuritylabel> |
|
</label> |
|
<equivalentlabel> |
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0' |
|
>MRUCAgD9DA9BcXVhIChvYnNvbGV0ZSk=</esssecuritylabel> |
|
</equivalentlabel> |
|
</securitylabel> |
|
</message> |
|
]]></example> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>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 recipient is known to hold a clearance under a different |
|
policy than the sender.</p> |
|
<p>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, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, |
|
whose values are HTML color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for |
|
use in colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>. |
|
The <tt>bgcolor=</tt> default is <tt>white</tt>. </p> |
|
</section1> |
|
|
|
<section1 topic="Label Catalog Discovery" anchor="label-catalog"> |
|
<p>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.</p> |
|
<p>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 usable 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.</p> |
|
<p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p> |
|
<p>Two identical catalog requests may return different results, even for the same |
|
requester, as the results may depend on numerous factors. It is suggested that clients |
|
request a catalog for use in a short-lived context, such as short-lived 1-to-1 chat |
|
session, for all use in stanzas of that session. For use in long-lived context, such |
|
as a long-lived Multi-User Chat session, it is suggested the client request the |
|
current catalog when the user becomes present after a period of extended absence. |
|
Alternatively, a client could simply cache catalog results for a configurable amount of |
|
time. With either approach, it is also suggested clients provide a means for the user |
|
to request an immediate refresh of all catalogs in all contexts. This is useful where |
|
the user made changes to a personal label catalog which the XMPP server uses as input |
|
in processing catalog requests. Note: there is no requirement that XMPP servers |
|
support 'personal label catalogs' (such details are beyond the scope of this document).</p> |
|
<p>If catalog is restrictive, as indicated by the <tt>restrict=</tt> attribute with value of |
|
true, the client SHOULD restrict the user to choosing one of the items from the catalog |
|
and use the label of that item (or no label if the selected item is empty).</p> |
|
<p>One and only one of the items may have a <tt>default=</tt> attribute with value of true. |
|
The client should default the label selection to this item in cases where the user has |
|
not selected an item.</p> |
|
<p>An item may have no security label. Such an item explicitly offers a choice of sending a |
|
stanza without a label. A non-restrictive catalog implicitly offers this choice when it |
|
does not contain an empty item.</p> |
|
<p>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 chat room). A |
|
catalog may not include the complete set of labels available for the use by the client |
|
in the context.</p> |
|
<p><em>Note:</em> the single catalog per context approach used here is likely inadequate in |
|
environments 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.</p> |
|
<p>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.</p> |
|
<p>To indicate the support for label catalog discovery, a server advertises the |
|
<tt>urn:xmpp:sec-label:catalog:2</tt> feature. The following pair of examples |
|
illustrates this feature discovery.</p> |
|
<p>Items in the catalog may contain a <tt>selector=</tt> attribute. The value of this |
|
attribute represents the item's placement in a hierarchical organization of the items. |
|
If one item has a <tt>selector=</tt> attribute, all items should have a |
|
<tt>selector=</tt> attribute. The value of the <tt>selector=</tt> attribute conforms |
|
to the <tt>selector-value</tt> ABNF production: |
|
</p> |
|
<code><![CDATA[selector-value = (<item>"|")*<item>]]></code> |
|
<p>where &ITEM; is a sequence of characters not including "|".</p> |
|
<p>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.</p> |
|
<p><em>Note:</em> use of unnecessarily deep hierarchies should be avoided.</p> |
|
<example caption="Label Catalog Feature Discovery request"><![CDATA[ |
|
<iq type='get' |
|
to='example.com' |
|
from='user@example.com/Work' |
|
id='disco1'> |
|
<query xmlns='http://jabber.org/protocol/disco#info'/> |
|
</iq> |
|
]]></example> |
|
<example caption="Label Information Feature Discovery response"><![CDATA[ |
|
<iq type='result' |
|
from='example.com' |
|
to='user@example.com/Work' |
|
id='disco1'> |
|
<query xmlns='http://jabber.org/protocol/disco#info'> |
|
... |
|
<feature var='urn:xmpp:sec-label:catalog:2'/> |
|
... |
|
</query> |
|
</iq> |
|
]]></example> |
|
|
|
|
|
<p>The following example pair illustrates catalog discovery. The client directs the <tt>&IQ;</tt> to |
|
its server regardless of which catalog it requests via the <tt>to=</tt> attribute of in |
|
&CATALOG; element. The client SHOULD NOT provide a <tt>from=</tt> attribute in the |
|
&CATALOG; element.</p> |
|
|
|
<example caption="Label Catalog request"><![CDATA[ |
|
<iq to='example.com' type='get' id='cat1'> |
|
<catalog xmlns='urn:xmpp:sec-label:catalog:2' to='example.com'/> |
|
</iq> |
|
]]></example> |
|
|
|
<example caption="Label Catalog Get response"><![CDATA[ |
|
<iq type='result' to='user@example.com/Work' id='cat1'> |
|
<catalog xmlns='urn:xmpp:sec-label:catalog:2' |
|
to='example.com' name='Default' |
|
desc='an example set of labels' |
|
restrict='false'> |
|
<item selector="Classified|SECRET"> |
|
<securitylabel xmlns='urn:xmpp:sec-label:0'> |
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking> |
|
<label> |
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0' |
|
>MQYCAQQGASk=</esssecuritylabel> |
|
</label> |
|
</securitylabel> |
|
</item> |
|
<item selector="Classified|CONFIDENTIAL"> |
|
<securitylabel xmlns='urn:xmpp:sec-label:0'> |
|
<displaymarking fgcolor='black' bgcolor='navy'>CONFIDENTIAL</displaymarking> |
|
<label> |
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0' |
|
>MQYCAQMGASk</esssecuritylabel> |
|
</label> |
|
</securitylabel> |
|
</item> |
|
<item selector="Classified|RESTRICTED"> |
|
<securitylabel xmlns='urn:xmpp:sec-label:0'> |
|
<displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking> |
|
<label> |
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0' |
|
>MQYCAQIGASk=</esssecuritylabel> |
|
</label> |
|
</securitylabel> |
|
</item> |
|
<item selector="UNCLASSIFIED" default="true"/> |
|
</catalog> |
|
</iq> |
|
]]></example> |
|
|
|
<p> Where the server needs to obtain a catalog from another server in order to respond to |
|
its client, it can send an &IQ; to that server requesting that catalog. The requesting |
|
server provides the bare JID of the requesting user in the <tt>from=</tt> attribute in |
|
the &CATALOG; element when it desires a catalog to be prepared specifically for the |
|
user. Otherwise the <tt>from=</tt> attribute in the &CATALOG; element is absent. </p> |
|
|
|
</section1> |
|
|
|
<section1 topic="Use in XMPP" anchor="xmpp-use"> |
|
<p>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.</p> |
|
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by this |
|
document, documents extending 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 appropriate, an error response. Such error responses SHOULD NOT |
|
include content from the violating stanza, excepting that necessary to well-formed error |
|
responses. Error responses MUST NOT contain a &SECURITYLABEL; element. Any such error |
|
response violates this protocol and MUST be discarded by servers implementing this |
|
specification. Error responses MUST NOT be subjected to security label authorization |
|
checks. However, this prohibition does not preclude a server from taking appropriate |
|
action to prevent the disclosure of sensitive information, such as closing the |
|
stream.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>A client which receives a stanza with &SECURITYLABEL; element is to prominently display |
|
the &DISPLAYMARKING; value. A policy-aware client may alternatively prominently display |
|
the marking for the &LABEL; prescribed by the governing policy.</p> |
|
<p>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 |
|
<em>Grant</em> or <em>Deny</em>.</p> |
|
<p>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.</p> |
|
<p>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.</p> |
|
<p>The term "effective clearance" and "effective label" refer, respectively, to the |
|
clearance and label provided as input to the ACDF.</p> |
|
<p>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, and chat |
|
rooms.</p> |
|
<section2 topic="Use in Instant Messaging" anchor="im-use"> |
|
<p>A client may provide a &SECURITYLABEL; element in any <tt>&MESSAGE;</tt> it sends.</p> |
|
<!-- |
|
<p>The server will make, at a minimum, the following accessing control decisions: |
|
<ul> |
|
<li>TBD</li> |
|
</ul> |
|
</p> |
|
--> |
|
</section2> |
|
<section2 topic="Use in Group Chat and Multi-User Chat" anchor="muc-use"> |
|
<p>A client may provide a &SECURITYLABEL; element in <tt>&MESSAGE;</tt> stanzas.</p> |
|
|
|
<section3 topic="Discovery" anchor="muc-disco"> |
|
<p>A server SHOULD provide a label feature and information discovery for the |
|
room.</p> |
|
<p>Clients SHOULD discover label feature and information on a per room basis.</p> |
|
</section3> |
|
|
|
<section3 topic="Sending Messages" anchor="muc-send"> |
|
<p>Sending groupchat messages is similar to sending normal messages, however their |
|
are a few differences.</p> |
|
<p>Groupchat messages are addressed to the room. The room clearance must be suitable |
|
for the message label, else it should be rejected.</p> |
|
<p>The room's clearance may allow a variety of labels to be used. Not all |
|
participants may be cleared for all labels allowed in the room. The server MUST |
|
only deliver messages to participants for which they are cleared to receive.</p> |
|
</section3> |
|
<section3 topic="Room History" anchor="muc-history"> |
|
<p>The server MUST only deliver messages to participants for which they are cleared |
|
to receive.</p> |
|
</section3> |
|
<section3 topic="Private Messages" anchor="muc-private"> |
|
<p>Private messages SHOULD be handled much like groupchat messages, including |
|
rejection of messages for a label not suitable for the room. The server MUST NOT |
|
deliver messages to participants for which they are cleared to receive.</p> |
|
</section3> |
|
<section3 topic="Invitations" anchor="muc-invite"> |
|
<p>Invitations may be labeled.</p> |
|
</section3> |
|
<section3 topic="Room Subject" anchor="muc-subject"> |
|
<p>A stanza intended to change the room subject SHOULD not carry a security label |
|
and SHOULD NOT be subject to security-label authorization checks. Such a stanza |
|
does not have any impact on the security-label parameters associated with the |
|
room.</p> |
|
</section3> |
|
<section3 topic="Room Configuration" anchor="muc-config"> |
|
<p>The server may allow for configuration of security label parameters via room |
|
configuration mechanisms. The approach is intended to be ad-hoc. Hence this |
|
section is intended to be illustrative of one possible approach. Implementations |
|
are free to utilize other approaches.</p> |
|
<example caption="Room Configuration Form"><![CDATA[ |
|
<iq from='room@muc.example.com' |
|
id='create1' |
|
to='user@example.com/Work' |
|
type='result'> |
|
<query xmlns='http://jabber.org/protocol/muc#owner'> |
|
<x xmlns='jabber:x:data' type='form'> |
|
<title>"darkcave" room configuration</title> |
|
... |
|
<field label='Room Label' type='list-single' var='sec-label#label'> |
|
<value>Catalog:UNCLASSIFIED</value> |
|
<option label='SECRET'><value>Catalog:SECRET</value></option> |
|
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option> |
|
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option> |
|
<option label='Custom'><value>Custom</value></option> |
|
</field> |
|
<field label='Custom Room Label' type='text-single' |
|
var='sec-label#custom-label'/> |
|
|
|
<field label='Room Allowed Markings' type='list-multi' var='sec-label#clearance'> |
|
<value>Catalog:UNCLASSIFIED</value> |
|
<option label='SECRET'><value>Catalog:SECRET</value></option> |
|
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option> |
|
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option> |
|
<option label='Custom'><value>Custom</value></option> |
|
</field> |
|
<field label='Custom Room Clearance' type='text-single' |
|
var='sec-label#custom-clearance'/> |
|
</x> |
|
</query> |
|
</iq> |
|
]]></example> |
|
<p>In the above example, the server allows the room label to be set to one of to a |
|
subset of labels from the label catalog (see below), using the display name for |
|
selection, as well as custom label support. For custom label choice support, the |
|
server offers an single text box for entry of an appropriate text string |
|
indicating the label to use. Likewise for the room clearance and default room |
|
clearance.</p> |
|
<p>Though offering choices from the label catalog is often desirable, a server could |
|
only offer custom label and/or clearance support.</p> |
|
<example caption="Room Configuration Form"><![CDATA[ |
|
<iq from='room@muc.example.com' |
|
id='create1' |
|
to='user@example.com/Work' |
|
type='result'> |
|
<query xmlns='http://jabber.org/protocol/muc#owner'> |
|
<x xmlns='jabber:x:data' type='form'> |
|
<title>"darkcave" room configuration</title> |
|
... |
|
<field label='Room Label' type='text-single' |
|
var='sec-label#custom-label'/> |
|
<field label='Room Clearance' type='text-single' |
|
var='sec-label#custom-clearance'/> |
|
</x> |
|
</query> |
|
</iq> |
|
]]></example> |
|
</section3> |
|
</section2> |
|
<section2 topic="Use in Presence" anchor="presence-use"> |
|
<p>&SECURITYLABEL; elements are not to appear in <tt>&PRESENCE;</tt> stanzas. Server SHALL treat |
|
any <tt>&PRESENCE;</tt> stanza that contains a &SECURITYLABEL; as a protocol violation.</p> |
|
<p>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 chat room's label.</p> |
|
</section2> |
|
</section1> |
|
|
|
<section1 topic="Extension Considerations" anchor="exts"> |
|
<p> This extension is itself extensible. In particular, the &LABEL; and &EQUIVALENTLABEL; |
|
elements are designed to hold a range of security labels formats. XML name spaces SHOULD |
|
be used to avoid name clashes. </p> |
|
<p> Future documents may specify how security-labels are used in other areas of XMPP, such |
|
as PubSub.</p> |
|
</section1> |
|
|
|
<!-- |
|
<section1 topic='Implementation Notes' anchor='impl'> |
|
<p>OPTIONAL.</p> |
|
</section1> |
|
--> |
|
<section1 topic="Security Considerations" anchor="security"> |
|
<p>This document is all about authorization, a key aspect of security. Hence, security |
|
considerations are discussed through this document.</p> |
|
<p>Nothing in this document ensures appropriate labeling the sensitivity of a piece of |
|
information. Addressing inappropriate labeling of information is beyond the scope of |
|
this document.</p> |
|
<p>Certain XMPP stanzas, such as <tt>&PRESENCE;</tt> stanzas, are not themselves subject to any |
|
sensitivity-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.</p> |
|
<p>It is desirable to securely bind the security label to the object it labels. This may be |
|
accomplished through use of digital signatures. Specification of such is left to a |
|
future document. </p> |
|
</section1> |
|
<section1 topic="IANA Considerations" anchor="iana"> |
|
<p>This document requires no interaction with &IANA;.</p> |
|
</section1> |
|
<section1 topic="XMPP Registrar Considerations" anchor="registrar"> |
|
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> |
|
<p>This specification defines the following XML namespaces:</p> |
|
<ul> |
|
<li>urn:xmpp:sec-label:0</li> |
|
<li>urn:xmpp:sec-label:catalog:2</li> |
|
<li>urn:xmpp:sec-label:ess:0</li> |
|
</ul> |
|
<p>The ®ISTRAR; includes the foregoing namespaces in the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p> |
|
</section2> |
|
<section2 topic='Protocol Versioning' anchor='registrar-versioning'> |
|
&NSVER; |
|
</section2> |
|
</section1> |
|
<section1 topic="XML Schemas" anchor="schema"> |
|
<section2 topic="Extension Schema" anchor="schema-sl"> |
|
<code><![CDATA[ |
|
<?xml version='1.0' encoding='UTF-8'?> |
|
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0" |
|
xmlns="urn:xmpp:sec-label:0" elementFormDefault="qualified"> |
|
|
|
<xs:annotation> |
|
<xs:documentation> |
|
The protocol documented by this schema is defined in |
|
XEP-0258: http://xmpp.org/extensions/xep-0258.html |
|
</xs:documentation> |
|
</xs:annotation> |
|
|
|
<xs:simpleType name="colorCSS"> |
|
<xs:annotation> |
|
<xs:documentation>CSS colors (W3C colors + "orange")</xs:documentation> |
|
</xs:annotation> |
|
<xs:restriction base="xs:string"> |
|
<xs:enumeration value="aqua"/> |
|
<xs:enumeration value="black"/> |
|
<xs:enumeration value="blue"/> |
|
<xs:enumeration value="fuschia"/> |
|
<xs:enumeration value="gray"/> |
|
<xs:enumeration value="green"/> |
|
<xs:enumeration value="lime"/> |
|
<xs:enumeration value="maroon"/> |
|
<xs:enumeration value="navy"/> |
|
<xs:enumeration value="olive"/> |
|
<xs:enumeration value="purple"/> |
|
<xs:enumeration value="red"/> |
|
<xs:enumeration value="silver"/> |
|
<xs:enumeration value="teal"/> |
|
<xs:enumeration value="white"/> |
|
<xs:enumeration value="yellow"/> |
|
<xs:enumeration value="orange"/> |
|
</xs:restriction> |
|
</xs:simpleType> |
|
|
|
<xs:simpleType name="colorRGB"> |
|
<xs:annotation> |
|
<xs:documentation>Hex encoded RGB</xs:documentation> |
|
</xs:annotation> |
|
<xs:restriction base="xs:string"> |
|
<xs:pattern value="#[0-9A-Fa-f]{6}"/> |
|
</xs:restriction> |
|
</xs:simpleType> |
|
|
|
<xs:simpleType name="color"> |
|
<xs:annotation> |
|
<xs:documentation>Color</xs:documentation> |
|
</xs:annotation> |
|
<xs:union memberTypes="colorCSS colorRGB"/> |
|
</xs:simpleType> |
|
|
|
<xs:complexType name="displaymarking"> |
|
<xs:annotation> |
|
<xs:documentation>Display Marking</xs:documentation> |
|
<xs:documentation>String to be prominently displayed along with labeled |
|
object.</xs:documentation> |
|
</xs:annotation> |
|
<xs:simpleContent> |
|
<xs:extension base="xs:string"> |
|
<xs:attribute name="bgcolor" type="color" use="optional" default="white"/> |
|
<xs:attribute name="fgcolor" type="color" use="optional" default="black"/> |
|
</xs:extension> |
|
</xs:simpleContent> |
|
</xs:complexType> |
|
|
|
<xs:complexType name="label"> |
|
<xs:choice minOccurs="0"> |
|
<xs:any namespace="##other" processContents="lax"/> |
|
</xs:choice> |
|
</xs:complexType> |
|
|
|
<xs:element name="securitylabel"> |
|
<xs:annotation> |
|
<xs:documentation>A Security Label</xs:documentation> |
|
</xs:annotation> |
|
<xs:complexType> |
|
<xs:sequence> |
|
<xs:element name="displaymarking" type="displaymarking"> |
|
<xs:annotation> |
|
<xs:documentation>A Display Marking</xs:documentation> |
|
<xs:documentation>To be prominently displayed</xs:documentation> |
|
</xs:annotation> |
|
</xs:element> |
|
<xs:element name="label" type="label"> |
|
<xs:annotation> |
|
<xs:documentation>The Primary Label</xs:documentation> |
|
</xs:annotation> |
|
</xs:element> |
|
<xs:element name="equivalentlabel" type="label" minOccurs="0" maxOccurs="unbounded"> |
|
<xs:annotation> |
|
<xs:documentation>An Equivalent Label</xs:documentation> |
|
</xs:annotation> |
|
</xs:element> |
|
</xs:sequence> |
|
</xs:complexType> |
|
</xs:element> |
|
</xs:schema> |
|
]]></code> |
|
<p>A copy of this schema is available at <link |
|
url="http://xmpp.org/schemas/sec-label.xsd"> |
|
http://xmpp.org/schemas/sec-label.xsd</link>.</p> |
|
</section2> |
|
<section2 topic="<catalog/> schema" anchor="schema-catalog"> |
|
<code><![CDATA[ |
|
<?xml version="1.0" encoding="UTF-8"?> |
|
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sl="urn:xmpp:sec-label:0" |
|
xmlns="urn:xmpp:sec-label:catalog:2" targetNamespace="urn:xmpp:sec-label:catalog:2" |
|
elementFormDefault="qualified"> |
|
|
|
<xs:annotation> |
|
<xs:documentation> |
|
The protocol documented by this schema is defined in |
|
XEP-0258: http://xmpp.org/extensions/xep-0258.html |
|
</xs:documentation> |
|
</xs:annotation> |
|
|
|
<xs:import schemaLocation="sec-label.xsd" namespace="urn:xmpp:sec-label:0"/> |
|
|
|
<xs:attribute name="to" type="xs:string"> |
|
<xs:annotation> |
|
<xs:documentation>Target JabberId</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="from" type="xs:string"> |
|
<xs:annotation> |
|
<xs:documentation>Target JabberId</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="name" type="xs:string"> |
|
<xs:annotation> |
|
<xs:documentation>Name</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="desc" type="xs:string"> |
|
<xs:annotation> |
|
<xs:documentation>Description</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="id" type="xs:string"> |
|
<xs:annotation> |
|
<xs:documentation>Identifer for current revision, commonly a hash</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="size" type="xs:integer"> |
|
<xs:annotation> |
|
<xs:documentation>Number of items</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="restrict" type="xs:boolean"> |
|
<xs:annotation> |
|
<xs:documentation>Restrictive</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="selector" type="xs:string"> |
|
<xs:annotation> |
|
<xs:documentation>User input selector</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:attribute name="default" type="xs:boolean"> |
|
<xs:annotation> |
|
<xs:documentation>default selection</xs:documentation> |
|
</xs:annotation> |
|
</xs:attribute> |
|
|
|
<xs:element name="catalog"> |
|
<xs:annotation> |
|
<xs:documentation>A Catalog of Labels</xs:documentation> |
|
</xs:annotation> |
|
|
|
<xs:complexType> |
|
<xs:sequence> |
|
<xs:element name="item" minOccurs="0" maxOccurs="unbounded"> |
|
<xs:complexType> |
|
<xs:sequence minOccurs="0"> |
|
<xs:element ref="sl:securitylabel"/> |
|
</xs:sequence> |
|
<xs:attribute ref="selector" use="optional"/> |
|
<xs:attribute ref="default" use="optional"/> |
|
</xs:complexType> |
|
</xs:element> |
|
</xs:sequence> |
|
<xs:attribute ref="to" use="optional"/> |
|
<xs:attribute ref="from" use="optional"/> |
|
<xs:attribute ref="name" use="optional"/> |
|
<xs:attribute ref="desc" use="optional"/> |
|
<xs:attribute ref="id" use="optional"/> |
|
<xs:attribute ref="size" use="optional"/> |
|
<xs:attribute ref="restrict" use="optional"/> |
|
</xs:complexType> |
|
</xs:element> |
|
</xs:schema> |
|
]]></code> |
|
<p>A copy of this schema is available at <link |
|
url="http://xmpp.org/schemas/sec-label-catalog.xsd"> |
|
http://xmpp.org/schemas/sec-label-catalog.xsd</link>.</p> |
|
</section2> |
|
<section2 topic="<esssecuritylabel/> schema" anchor="schema-ess"> |
|
<code><![CDATA[ |
|
<?xml version="1.0" encoding="UTF-8"?> |
|
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:ess:0" |
|
xmlns="urn:xmpp:sec-label:ess:0" elementFormDefault="qualified"> |
|
|
|
<xs:annotation> |
|
<xs:documentation> |
|
The protocol documented by this schema is defined in |
|
XEP-0258: http://xmpp.org/extensions/xep-0258.html |
|
</xs:documentation> |
|
</xs:annotation> |
|
|
|
<xs:element name="esssecuritylabel" type="xs:base64Binary"> |
|
<xs:annotation> |
|
<xs:documentation>An S/MIME ESS SecurityLabel [RFC2634]</xs:documentation> |
|
<xs:documentation>Value is the base64 encoding of the BER/DER encoding of an ASN.1 |
|
ESSSecurityLabel type as defined in RFC 2634. </xs:documentation> |
|
</xs:annotation> |
|
</xs:element> |
|
</xs:schema> |
|
]]></code> |
|
<p>A copy of this schema is available at <link |
|
url="http://xmpp.org/schemas/sec-label-ess.xsd"> |
|
http://xmpp.org/schemas/sec-label-ess.xsd</link>.</p> |
|
</section2> |
|
</section1> |
|
</xep>
|
|
|