mirror of https://github.com/moparisthebest/xeps
894 lines
44 KiB
XML
894 lines
44 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
<!ENTITY LABEL "<label/>">
|
|
<!ENTITY CATALOG "<catalog/>">
|
|
<!ENTITY SECURITYLABEL "<securitylabel/>">
|
|
<!ENTITY DISPLAYMARKING "<displaymarking/>">
|
|
<!ENTITY EQUIVALENTLABEL "<equivalentlabel/>">
|
|
<!ENTITY HEADLINE "<headline/>">
|
|
<!ENTITY IDENTITY "<identity/>">
|
|
%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>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0001</spec>
|
|
<spec>XEP-0285</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>sec-label</shortname>
|
|
&kdz;
|
|
<revision>
|
|
<version>0.7</version>
|
|
<date>2010-09-29</date>
|
|
<initials>kdz</initials>
|
|
<remark>
|
|
<p>Add initial support for secure binding of labels (digital signatures).</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; type= attribute. Clarify label catalog
|
|
discovery. Clarify syntax of selector= 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, 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.</p>
|
|
<p>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.</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>To securely bind the security label to the message, &xep0285; can be used as detailed below.</p>
|
|
<example caption="Message with Securely bound ESS Security Label"><![CDATA[
|
|
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
|
<signed xmlns="urn:xmpp:signed:0">
|
|
<signature algorithm="RSA-SHA1">To-be-computed
|
|
</signature>
|
|
<data>
|
|
PG1lc3NhZ2UgdG89J3JvbWVvQGV4YW1wbGUubmV0JyBmcm9tPSdqdWxpZXRAZXhhbXBsZS5jb20v
|
|
YmFsY29ueSc+CiAgICA8Ym9keT5UaGlzIGNvbnRlbnQgaXMgY2xhc3NpZmllZC48L2JvZHk+CiAg
|
|
ICA8c2VjdXJpdHlsYWJlbCB4bWxucz0ndXJuOnhtcHA6c2VjLWxhYmVsOjAnPgogICAgICAgIDxk
|
|
aXNwbGF5bWFya2luZyBmZ2NvbG9yPSdibGFjaycgYmdjb2xvcj0ncmVkJz5TRUNSRVQ8L2Rpc3Bs
|
|
YXltYXJraW5nPgogICAgICAgIDxsYWJlbD48aWNpc21sYWJlbCB4bWxucz0naHR0cDovL2V4YW1w
|
|
bGUuZ292L0lDLUlTTS8wJyBjbGFzc2lmaWNhdGlvbj0nUycKICAgICAgICAgICAgb3duZXJQcm9k
|
|
dWNlcj0nVVNBJy8+PC9sYWJlbD4KICAgIDwvc2VjdXJpdHlsYWJlbD4KPC9tZXNzYWdlPgo=
|
|
</data>
|
|
</message>
|
|
]]>
|
|
</example>
|
|
|
|
<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 <em>not</em> provide:
|
|
<ul>
|
|
<li>any mechanism for a client might discover the security policy enforce 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>
|
|
Such mechanisms may be introduced in subsequent documents.</p>
|
|
</section1>
|
|
|
|
<section1 topic="Discovering Feature Support" anchor="disco">
|
|
<p>If an entity supports the XMPP Security Label protocol, it 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. 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>If an entity supports secure binding of the XMPP Security Label using &xmppdsig;, it MUST
|
|
report the fact by including a service discover feature of
|
|
"<tt>urn:xmpp:sec-label:dsig:0</tt>"" in response to a &xep0030; information request.
|
|
Clients wishing to include a securely bound 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 securely bound XMPP Security Label, the
|
|
client SHOULD NOT generate securely bound XMPP Security Labels as the server not
|
|
supporting this protocol will generally ignore securely bound XMPP Security Labels as
|
|
they would any other unrecognized element. Note that the client here is signing
|
|
the stanzas for the benifit of its server. Its server will determine what content,
|
|
if any, to forward to other entities. Hence, the sending client need determine whether
|
|
any of the intended receipents supports XMPP Digital Signatures.</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'/>
|
|
<feature var='urn:xmpp:sec-label:dsig:0'/>
|
|
...
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
<!--
|
|
<p>A server should only include &IDENTITY; elements in the response for services
|
|
the user is cleared to use.</p>
|
|
-->
|
|
</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 recepient 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 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.</p>
|
|
<p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p>
|
|
<p>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.</p>
|
|
<p>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.</p>
|
|
<p>An item may have no label. Such an item offers a choice of sending a stanza without a
|
|
label.</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 chatroom). A
|
|
catalog may not be include the complete set of labels available for the use by the
|
|
client in the context.</p>
|
|
<blockquote>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.</blockquote>
|
|
<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>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: <blockquote>
|
|
<![CDATA[
|
|
selector-value = (<item>"|")*<item>
|
|
]]>
|
|
</blockquote>
|
|
</p>
|
|
<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>
|
|
<blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
|
|
<example caption="Label Catalog Feature Discovery request"><![CDATA[
|
|
<iq type='get'
|
|
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. Note that client directs the
|
|
&IQ; to its server regardless of which catalog it requests (via the to= attribute of in
|
|
&CATALOG; element).</p>
|
|
|
|
<example caption="Label Catalog request"><![CDATA[
|
|
<iq 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'
|
|
restrictive='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" default="true">
|
|
<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|UNCLASSIFIED"/>
|
|
</catalog>
|
|
</iq>
|
|
]]></example>
|
|
</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, 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.</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 promiently display
|
|
the &DISPLAYMARKING; value. A policy-aware may alternatively promiently 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,
|
|
chatrooms, pubsub notes.</p>
|
|
<section2 topic="Use in Instant Messaging" anchor="im-use">
|
|
<p>A client may provide a &SECURITYLABEL; element in any &MESSAGE; 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 &MESSAGE; 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 similiar 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 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.</p>
|
|
</section3>
|
|
<section3 topic="Private Messages" anchor="muc-private">
|
|
<p>Private messages are treated as discussed in the "Use in Instant Messaging"
|
|
section. (Should private messages be restricted by room's configuration?)</p>
|
|
</section3>
|
|
<section3 topic="Invitations" anchor="muc-invite">
|
|
<p>Invitations may be labeled.</p>
|
|
</section3>
|
|
<section3 topic="Changing Subject" anchor="muc-subject">
|
|
<p>This section discusses semantics of &SECURITYLABEL; elements contained in
|
|
&MESSAGE; stanzas containing a &SUBJECT; element.</p>
|
|
<p>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.</p>
|
|
<p>Upon change of the room's label, the server MUST immediately remove from the room
|
|
all members whom are not cleared for that label.</p>
|
|
<p>In absence of a &SECURITYLABEL; element, the label associated with the room is
|
|
unchanged.</p>
|
|
<p>The room's label can also be changed through room configuration (to be discussed
|
|
in later revision of this document).</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, not
|
|
prescriptive.</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'/>
|
|
<field label='Default Label' type='list-single' var='sec-label#default-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>
|
|
</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 appropriate choice (the label= string should
|
|
be selected to avoid confusion with display markings used in label=
|
|
attributes). as well as a field for providing the custom label. Likewise
|
|
for the room clearance. The server also allows configuration of a default
|
|
label for use in handling of unlabeled messages.</p>
|
|
<p>Though offering choices from the label catalog is often desirable,
|
|
a server may 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 &PRESENCE; stanzas. Server SHALL treat
|
|
any &PRESENCE; 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 chatroom's label.</p>
|
|
</section2>
|
|
<section2 topic="Use in PubSub" anchor="pubsub-use">
|
|
<section3 topic="Discovery" anchor="pubsub-disco">
|
|
<p>A server SHOULD provide a label feature and information discovery for each
|
|
node.</p>
|
|
<p>Clients SHOULD discover label feature and information on a per node basis.</p>
|
|
</section3>
|
|
<section3 topic="Publishing items with Security Labels" anchor="muc-send">
|
|
<p>Each item may be individually labeled.</p>
|
|
<example caption="Publishing with a Security Label"><![CDATA[
|
|
<iq type='set'
|
|
from='hamlet@denmark.lit/blogbot'
|
|
to='pubsub.shakespeare.lit'
|
|
id='pub1'>
|
|
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
|
<publish node='princely_musings'>
|
|
<item>
|
|
<entry xmlns='http://www.w3.org/2005/Atom'>
|
|
<title>Soliloquy</title>
|
|
<summary>
|
|
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?
|
|
</summary>
|
|
<link rel='alternate' type='text/html'
|
|
href='http://denmark.lit/2003/12/13/atom03'/>
|
|
<id>tag:denmark.lit,2003:entry-32397</id>
|
|
<published>2003-12-13T18:30:02Z</published>
|
|
<updated>2003-12-13T18:30:02Z</updated>
|
|
</entry>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
|
</label>
|
|
</securitylabel>
|
|
</item>
|
|
</publish>
|
|
</pubsub>
|
|
</iq>
|
|
]]></example>
|
|
<p>The service then notifies appropriately cleared subscribers.</p>
|
|
<example caption="Publishing with a Security Label"><![CDATA[
|
|
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
|
|
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
|
<items node=princely_musings'>
|
|
<item id='ae890ac52d0df67ed7cfdf51b644e901'>
|
|
<entry xmlns='http://www.w3.org/2005/Atom'>
|
|
<title>Soliloquy</title>
|
|
<summary>
|
|
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?
|
|
</summary>
|
|
<link rel='alternate' type='text/html'
|
|
href='http://denmark.lit/2003/12/13/atom03'/>
|
|
<id>tag:denmark.lit,2003:entry-32397</id>
|
|
<published>2003-12-13T18:30:02Z</published>
|
|
<updated>2003-12-13T18:30:02Z</updated>
|
|
</entry>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'>MQMGASk=</esssecuritylabel>
|
|
</label>
|
|
</securitylabel>
|
|
</item>
|
|
</items>
|
|
</event>
|
|
</iq>
|
|
]]></example>
|
|
</section3>
|
|
</section2>
|
|
</section1>
|
|
|
|
<section1 topic="Extension Considerations" anchor="exts">
|
|
<p> 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. </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>Security labels generally should be securely bound to the object. This may be
|
|
accomplished through use of &xmppdsig; as discussed in Appendix A.</p>
|
|
<p>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.</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">
|
|
<p>It is requested the ®ISTRAR; add the extension's namespaces and schemas to appropriate
|
|
XMPP registries.</p>
|
|
</section1>
|
|
<section1 topic="XML Schemas" anchor="schema">
|
|
<section2 topic="Extension Schema" anchor="schema-sl">
|
|
<p>
|
|
<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://www.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> A copy of this schema is available at <link
|
|
url="http://www.xmpp.org/schemas/sec-label.xsd">
|
|
http://www.xmpp.org/schemas/sec-label.xsd</link>. </p>
|
|
</section2>
|
|
<section2 topic="<catalog/> schema" anchor="schema-catalog">
|
|
<p>
|
|
<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:1"
|
|
elementFormDefault="qualified">
|
|
|
|
<xs:annotation>
|
|
<xs:documentation>The protocol documented by this schema is defined in XEP-0258:
|
|
http://www.xmpp.org/extensions/xep-0258.html</xs:documentation>
|
|
</xs:annotation>
|
|
|
|
<xs:import schemaLocation="xep258.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="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 Item</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>
|
|
<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="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> A copy of this schema is available at <link
|
|
url="http://www.xmpp.org/schemas/sec-label-catalog.xsd">
|
|
http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
|
|
</section2>
|
|
<section2 topic="<esssecuritylabel/> schema" anchor="schema-ess">
|
|
<p>
|
|
<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://www.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> A copy of this schema is available at <link
|
|
url="http://www.xmpp.org/schemas/sec-label-ess.xsd">
|
|
http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
|
|
</section2>
|
|
</section1>
|
|
</xep>
|