moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

Changes based on LC comments

This commit is contained in:
Kurt Zeilenga 2011-11-02 12:06:24 -07:00
parent d8cc52a1bc
commit 52b77f5bc4
1 changed files with 435 additions and 514 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

725
xep-0258.xml
View File

@ -1,23 +1,23 @@
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [ <!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'> <!ENTITY % ents SYSTEM 'xep.ent'>
<!ENTITY LABEL "&lt;label/&gt;"> <!ENTITY LABEL "<tt>&lt;label/&gt;</tt>">
<!ENTITY CATALOG "&lt;catalog/&gt;"> <!ENTITY CATALOG "<tt>&lt;catalog/&gt;</tt>">
<!ENTITY SECURITYLABEL "&lt;securitylabel/&gt;"> <!ENTITY ITEM "<tt>&lt;item/&gt;</tt>">
<!ENTITY DISPLAYMARKING "&lt;displaymarking/&gt;"> <!ENTITY SECURITYLABEL "<tt>&lt;securitylabel/&gt;</tt>">
<!ENTITY EQUIVALENTLABEL "&lt;equivalentlabel/&gt;"> <!ENTITY DISPLAYMARKING "<tt>&lt;displaymarking/&gt;</tt>">
<!ENTITY HEADLINE "&lt;headline/&gt;"> <!ENTITY EQUIVALENTLABEL "<tt>&lt;equivalentlabel/&gt;</tt>">
<!ENTITY IDENTITY "&lt;identity/&gt;"> <!ENTITY HEADLINE "<tt>&lt;headline/&gt;</tt>">
<!ENTITY IDENTITY "<tt>&lt;identity/&gt;</tt>">
%ents; %ents;
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
<header> <header>
<title>Security Labels in XMPP</title> <title>Security Labels in XMPP</title>
<abstract>This document describes the use of security labels in XMPP. The document <abstract>This document describes the use of security labels in XMPP. The document specifies
specifies how security label meta-data is carried in XMPP, when this meta-data how security label meta-data is carried in XMPP, when this meta-data should or should
should or should not be provided, and how the meta-data is to be processed.</abstract> not be provided, and how the meta-data is to be processed.</abstract> &LEGALNOTICE;
&LEGALNOTICE;
<number>0258</number> <number>0258</number>
<status>Experimental</status> <status>Experimental</status>
<lastcall>2011-10-21</lastcall> <lastcall>2011-10-21</lastcall>
@ -37,87 +37,118 @@
<email>Kurt.Zeilenga@Isode.COM</email> <email>Kurt.Zeilenga@Isode.COM</email>
<jid>Kurt.Zeilenga@Isode.COM</jid> <jid>Kurt.Zeilenga@Isode.COM</jid>
</author> </author>
<revision>
<version>0.10</version>
<date>2011-11-03</date>
<initials>kdz</initials>
<remark>
<p>Address last call comments.</p>
</remark>
</revision>
<revision> <revision>
<version>0.9</version> <version>0.9</version>
<date>2011-09-21</date> <date>2011-09-21</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Add optional from attribute to catalog element for S2S requests. Make editorial changes.</p></remark> <remark>
<p>Add optional <tt>from=</tt> attribute to catalog element for S2S requests. Make
editorial changes.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.8</version> <version>0.8</version>
<date>2011-08-11</date> <date>2011-08-11</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Correct catalog schema.</p></remark> <remark>
<p>Correct catalog schema.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.7</version> <version>0.7</version>
<date>2011-03-08</date> <date>2011-03-08</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Illustrate XEP Multi-User Chat room security label configuration. Make clarifications and minor editorial changes.</p></remark> <remark>
<p>Illustrate XEP Multi-User Chat room security label configuration. Make
clarifications and minor editorial changes.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.6</version> <version>0.6</version>
<date>2010-07-30</date> <date>2010-07-30</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Extend catalog handling. Minor editorial changes.</p></remark> <remark>
<p>Extend catalog handling. Minor editorial changes.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.5</version> <version>0.5</version>
<date>2009-07-27</date> <date>2009-07-27</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.</p></remark> <remark>
<p>Remove &LABEL;/&EQUIVALENTLABEL; <tt>type=</tt> attribute. Clarify label catalog
discovery. Clarify syntax of <tt>selector=</tt> attribute.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.4</version> <version>0.4</version>
<date>2009-07-23</date> <date>2009-07-23</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Update label catalogs to include user input selector.</p></remark> <remark>
<p>Update label catalogs to include user input selector.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.3</version> <version>0.3</version>
<date>2009-03-20</date> <date>2009-03-20</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Add text regarding default bg/fg colors. Correct examples.</p></remark> <remark>
<p>Add text regarding default bg/fg colors. Correct examples.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
<date>2009-03-10</date> <date>2009-03-10</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Reworked discovery and various updates.</p></remark> <remark>
<p>Reworked discovery and various updates.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2009-01-05</date> <date>2009-01-05</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Initial published version.</p></remark> <remark>
<p>Initial published version.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.0.081203</version> <version>0.0.081203</version>
<date>2008-12-03</date> <date>2008-12-03</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Initial draft.</p></remark> <remark>
<p>Initial draft.</p>
</remark>
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic="Introduction" anchor="intro">
<p>A security label, sometimes referred to as a confidentiality label, is <p>A security label, sometimes referred to as a confidentiality label, is a structured
a structured representation of the sensitivity of a piece of information. A security representation of the sensitivity of a piece of information. A security label is used in
label is used in conjunction with a clearance, a structured representation of what conjunction with a clearance, a structured representation of what information
information sensitivities a person (or other entity) is authorized to access, and a security sensitivities a person (or other entity) is authorized to access, and a security policy
policy to control access to each piece of information. For instance, message could be to control access to each piece of information. For instance, a message could be labeled
labeled as "SECRET", and hence requiring the sender and the receiver to each have a as "SECRET", and hence requiring the sender and the receiver to each have a clearance
clearance granting access to "SECRET" information. &X.841; provides a discussion of granting access to "SECRET" information. &X.841; provides a discussion of security
security labels, clearances, and security policy.</p> labels, clearances, and security policy.</p>
<p>Sensitivity-based authorization is used in networks which operate under a set of <p>Sensitivity-based authorization is used in networks which operate under a set of
information classification rules, such as in government agency networks. The information classification rules, such as in government agency networks. The
standardized formats for security labels, clearances, and security policy are standardized formats for security labels, clearances, and security policy are
generalized and do have application in non-government networks.</p> generalized and do have application in non-government networks.</p>
<p>This document describes the use of security labels in &xmpp;. The document specifies <p>This document describes the use of security labels in &xmpp;. The document specifies how
how security label meta-data is carried in XMPP. It standardizes a mechanism for security label meta-data is carried in XMPP. It standardizes a mechanism for carrying
carrying ESS Security Labels in XMPP, as well as provides for use of other label ESS Security Labels in XMPP, as well as provides for use of other label formats. ESS
formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in
commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c; conjunction with &X.500; clearances and either X.841 or &SDN.801c; security
security policies.</p> policies.</p>
<example caption="Message with ESS Security Label"><![CDATA[ <example caption="Message with ESS Security Label"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'> <message to='romeo@example.net' from='juliet@example.com/balcony'>
<body>This content is classified.</body> <body>This content is classified.</body>
@ -141,37 +172,34 @@
]]></example> ]]></example>
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p> <p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
<p>The document details when security label meta-data should or should not be provided, and how <p>The document details when security label meta-data should or should not be provided, and
this meta-data is to be processed.</p> how this meta-data is to be processed.</p>
<p>This document does not provide: <p>This document does not provide: <ul>
<ul> <li>any mechanism for a client to discover the security policy in force at its home
<li>any mechanism for a client might discover the security policy server, or any other server;</li>
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
<li>any mechanism for a client to discover the user's clearance, associated with any resource; nor</li>
or the clearance of associated with any resource; nor</li> <li>any administrative mechanism for a client to configure configure policy,
<li>any administrative mechanism for a client to configure clearance, and labels of any resource.</li>
configure policy, clearance, and labels of any resource.</li> </ul> Such mechanisms may be introduced in subsequent documents.</p>
</ul>
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.
<p>This document does discuss how one might securely bind a security label to a stanza.
It is expected a subsequent document will tackle this topic.</p> It is expected a subsequent document will tackle this topic.</p>
</section1> </section1>
<section1 topic='Discovering Feature Support' anchor='disco'> <section1 topic="Discovering Feature Support" anchor="disco">
<p>An entity (client or server) which supports the XMPP Security Label protocol <p>An entity (client or server) which supports the XMPP Security Label protocol MUST report
MUST report that fact by including a service discovery feature of that fact by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in
"<tt>urn:xmpp:sec-label:0</tt>" in response to a &xep0030; information request.</p> response to a &xep0030; information request.</p>
<p>Clients wishing to include a XMPP Security Label element in any stanza they <p>Clients wishing to include a XMPP Security Label element in any stanza they generate
generate SHOULD determine if their server supports the XMPP Security Label protocol. SHOULD determine if their server supports the XMPP Security Label protocol. If their
If their server does not support XMPP Security Label, the client SHOULD NOT generate server does not support XMPP Security Label, the client SHOULD NOT generate XMPP
XMPP Security Labels as the server not supporting this protocol will generally Security Labels as the server not supporting this protocol will generally ignore XMPP
ignore XMPP Security Labels as they would any other unrecognized element.</p> Security Labels as they would any other unrecognized element.</p>
<p>As each service domain may have different support for security labels, servers <p>As each service domain may have different support for security labels, servers should
should advertise and clients should perform appropriate discovery lookups on a advertise and clients should perform appropriate discovery lookups on a per service
per service basis.</p> basis.</p>
<example caption="Service Discovery information request"><![CDATA[ <example caption="Service Discovery information request"><![CDATA[
<iq type='get' <iq type='get'
from='user@example.com/Work' from='user@example.com/Work'
@ -192,12 +220,12 @@
</query> </query>
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Protocol' anchor='protocol'> <section1 topic="Protocol" anchor="protocol">
<p>An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data <p>An element, &SECURITYLABEL;, is defined to carry security label meta-data. This meta-data
includes a security label, zero or more equivalent security labels, and optionally display includes a security label, zero or more equivalent security labels, and optionally
marking data.</p> display marking data.</p>
<example caption="Labeled Message"><![CDATA[ <example caption="Labeled Message"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'> <message to='romeo@example.net' from='juliet@example.com/balcony'>
<body>This content is classified.</body> <body>This content is classified.</body>
@ -214,86 +242,74 @@
</securitylabel> </securitylabel>
</message> </message>
]]></example> ]]></example>
<p>The security label metadata is carried in an &SECURITYLABEL; element. <p>The security label meta-data is carried in an &SECURITYLABEL; element. The
The &SECURITYLABEL; element which contains one and only one &LABEL; element, &SECURITYLABEL; element which contains one and only one &LABEL; element, zero or more
zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p> &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
<p>The &LABEL; provides the primary security label. It is commonly issued <p>The &LABEL; provides the primary security label. It is commonly issued by the sender
by the sender under the security policy of that they and their home under the security policy of that they and their home server operating under. The
server operating under. The &LABEL; contains either a single element &LABEL; contains either a single element representing the primary security label or is
representing the primary security label or is empty to indicate use of empty to indicate use of a default.</p>
a default.</p> <p>Each &EQUIVALENTLABEL; represents an equivalent security label under other policies. Each
<p>Each &EQUIVALENTLABEL; represents an equivalent security label under &EQUIVALENTLABEL; contains a single element representing the equivalent label. This
other policies. Each &EQUIVALENTLABEL; contains a single element element might be used when a recipient is known to hold a clearance under a different
representing the equivalent label. This element might be used when policy than the sender.</p>
a recepient is known to hold a clearance under a different policy <p>The &DISPLAYMARKING; element contains a display string for use by implementations which
than the sender.</p> are unable to utilize the applicable security policy to generate display markings. The
<p>The &DISPLAYMARKING; element contains a display string for use by element may optionally contain two attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>,
implementations which are unable to utilize the applicable security policy whose values are HTML color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for
to generate display markings. The element may optionally contain two use in colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>.
attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML The <tt>bgcolor=</tt> default is <tt>white</tt>. </p>
color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for use in </section1>
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'> <section1 topic="Label Catalog Discovery" anchor="label-catalog">
<p>A client can request a catalog for a particular JID by sending <p>A client can request a catalog for a particular JID by sending a catalog discovery
a catalog discovery request to the client's server. Where the JID request to the client's server. Where the JID is hosted by some other server, the
is hosted by some other server, the client's server is expected to client's server is expected to produce a suitable catalog (or fail the request). The
produce a suitable catalog (or fail the request). The client's server client's server may, as needed, query catalogs from other servers in order to fulfill
may, as needed, query catalogs from other servers in order to the client's request.</p>
fulfill the client's request.</p> <p>While this specification does not preclude a client from directing a catalog request
<p>While this specification does not preclude a client from directing elsewhere, it is noted that catalog returned by a party other than its server may not be
a catalog request elsewhere, it is noted that catalog returned by directly usable by the client. For instance, the client's server might require a
a party other than its server may not be directly usable by the particular only-locally-known label be used in messages to a particular remote JID.</p>
client. For instance, the client's server might require a particular <p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p>
only-locally-known label be used in messages to a particular remote <p>If catalog is restrictive, as indicated by the <tt>restrict=</tt> attribute with value of
JID.</p> true, the client SHOULD restrict the user to choosing one of the items from the catalog
<p>It is RECOMMENDED the server publish catalogs of security label and use the label of that item (or no label if the selected item is empty).</p>
for use by clients.</p> <p>One and only one of the items may have a <tt>default=</tt> attribute with value of true.
<p>If catalog is restrictive, as indicated by the restrict attribute The client should default the label selection to this item in cases where the user has
with value of true, the client SHOULD use one of the labels not selected an item.</p>
(or no label) offered by the catalog.</p> <p>An item may have no security label. Such an item explicitly offers a choice of sending a
<p>One and only one of the items may have a default attribute with stanza without a label. A non-restrictive catalog implicitly offers this choice when it
value of true. The client should default the label selection to does not contain an empty item.</p>
this item in cases where the user has not selected an item.</p> <p>Each catalog provided should only contain labels for which the client is allowed to use
<p>An item may have no security label. Such an item offers a choice of (based upon the user's authorization) in a particular context (such as in chat room). A
sending a stanza without a label.</p> catalog may not include the complete set of labels available for the use by the client
<p>Each catalog provided should only contain labels for which the client in the context.</p>
is allowed to use (based upon the user's authorization) in a particular <blockquote>Note: the single catalog per context approach used here is likely inadequate in
context (such as in chat room). A catalog may not be include the environments where there are a large number of labels in use. It is expected that a more
complete set of labels available for the use by the client in the sophisticated approach will be introduced in a subsequent revision of this
context.</p>
<blockquote>Note: 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.</blockquote> specification.</blockquote>
<p>As each service domain may have different support for security labels, <p>As each service domain may have different support for security labels, servers should
servers should advertise and clients should perform appropriate advertise and clients should perform appropriate discovery lookups on a per service
discovery lookups on a per service basis.</p> basis.</p>
<p>To indicate the support for label catalog discovery, a server <p>To indicate the support for label catalog discovery, a server advertises the
advertises the <tt>urn:xmpp:sec-label:catalog:2</tt> feature. <tt>urn:xmpp:sec-label:catalog:2</tt> feature. The following pair of examples
The following pair of examples illustrates this feature discovery.</p> illustrates this feature discovery.</p>
<p>Items in the catalog may contain a selector attribute. The <p>Items in the catalog may contain a <tt>selector=</tt> attribute. The value of this
value of this attribute represents the item's placement in a attribute represents the item's placement in a hierarchical organization of the items.
hierarchical organization of the items. If one item has a selector If one item has a <tt>selector=</tt> attribute, all items should have a
attribute, all items should have a selector item. The value of the selector <tt>selector=</tt> attribute. The value of the <tt>selector=</tt> attribute conforms
attribute conforms to the selector-value ABNF production: to the <tt>selector-value</tt> ABNF production: <blockquote><tt>
<blockquote> <![CDATA[
<![CDATA[
selector-value = (<item>"|")*<item> selector-value = (<item>"|")*<item>
]]> ]]>
</blockquote> </tt></blockquote>
</p> </p>
<p>where &lt;item&gt; is a sequence of characters not including "|".</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 <p>A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X"
the "Y" subset of the "X" subset of items. This information may subset of items. This information may be used, for instance, in generating label
be used, for instance, in generating label selection menus in selection menus in graphical user interfaces.</p>
graphical user interfaces.</p> <blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
<blockquote>Note: use of unnecessarily deep hierarchies should be
avoided.</blockquote>
<example caption="Label Catalog Feature Discovery request"><![CDATA[ <example caption="Label Catalog Feature Discovery request"><![CDATA[
<iq type='get' <iq type='get'
to='example.com' to='example.com'
@ -316,10 +332,10 @@ selector-value = (<item>"|")*<item>
]]></example> ]]></example>
<p>The following example pair illustrates catalog discovery. The <p>The following example pair illustrates catalog discovery. The client directs the <tt>&IQ;</tt> to
client directs the &IQ; to its server regardless of which catalog its server regardless of which catalog it requests via the <tt>to=</tt> attribute of in
it requests via the to= attribute of in &CATALOG; element. The &CATALOG; element. The client SHOULD NOT provide a <tt>from=</tt> attribute in the
client SHOULD NOT provide a from= attribute in the &CATALOG; element.</p> &CATALOG; element.</p>
<example caption="Label Catalog request"><![CDATA[ <example caption="Label Catalog request"><![CDATA[
<iq to='example.com' type='get' id='cat1'> <iq to='example.com' type='get' id='cat1'>
@ -365,81 +381,76 @@ client SHOULD NOT provide a from= attribute in the &CATALOG; element.</p>
</iq> </iq>
]]></example> ]]></example>
<p> <p> Where the server needs to obtain a catalog from another server in order to respond to
Where the server needs to obtain a catalog from another server in order its client, it can send an &IQ; to that server requesting that catalog. The requesting
to respond to its client, it can send an &IQ; to that server requesting server provides the bare JID of the requesting user in the <tt>from=</tt> attribute in
that catalog. The requesting server provides the bare JID of the the &CATALOG; element when it desires a catalog to be prepared specifically for the
requesting user in the from= attribute in the &CATALOG; element when user. Otherwise the <tt>from=</tt> attribute in the &CATALOG; element is absent. </p>
it desires a catalog to be prepared specifically for the user.
Otherwise the from= attribute in the &CATALOG; element is absent.
</p>
</section1> </section1>
<section1 topic='Use in XMPP' anchor='xmpp-use'> <section1 topic="Use in XMPP" anchor="xmpp-use">
<p>The sensitivity-based access control decisions discussed herein are to be <p>The sensitivity-based access control decisions discussed herein are to be made
made independently of other access control decisions or other facilities. independently of other access control decisions or other facilities. That is, the
That is, the sensitivity-based access control decisions are not conditional sensitivity-based access control decisions are not conditional on other factors.</p>
on other factors.</p> <p>It is intended that &SECURITYLABEL; elements are only used as prescribed by this
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by document, documents extending this document, or other formal specifications. Any other
this document, or other formal specifications. Any other use of use of &SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD be
&SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD discarded with, if appropriate, an error response. Such error responses SHOULD NOT
be discarded with, if approrpriate, an error response. Such error responses include content from the violating stanza, excepting that necessary to well-formed error
SHOULD NOT include content from the violating stanza, excepting that responses. Error responses MUST NOT contain a &SECURITYLABEL; element. Any such error
necessary to well-formed error responses.</p> response violates this protocol and MUST be discarded by servers implementing this
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. specification. Error responses MUST NOT be subjected to security label authorization
Absence of a &SECURITYLABEL; element implies the stanza has the default label checks. However, this prohibition does not preclude a server from taking appropriate
as specified in the governing security policy. Given that the governing action to prevent the disclosure of sensitive information, such as closing the
policy may not specify a default label, hence denying access to the stanza, stream.</p>
supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p> <p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. Absence of
<p>Typically, a client would allow the user to choose populate the a &SECURITYLABEL; element implies the stanza has the default label as specified in the
&SECURITYLABEL; from one of from a small set of security labels selections governing security policy. Given that the governing policy may not specify a default
known to it (through configuration and/or discovery and/or other means), label, hence denying access to the stanza, supporting clients SHOULD provide a
such as from a pull-down menu. That selection would include appropriate &SECURITYLABEL; element where prescribed.</p>
values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p> <p>Typically, a client would allow the user to choose populate the &SECURITYLABEL; from one
<p>A policy-aware client may provide the user with an interface allowing the of from a small set of security labels selections known to it (through configuration
user to produce custom labeling data for inclusion in this set. A and/or discovery and/or other means), such as from a pull-down menu. That selection
policy-aware client SHOULD preclude the user from producing &LABEL; values would include appropriate values for the &LABEL;, &DISPLAYMARKING;, and
which the user's own clearance does not grant access to, and SHOULD preclude &EQUIVALENTLABEL; elements.</p>
sending any label which the user's own clearance does not grant access to. <p>A policy-aware client may provide the user with an interface allowing the user to produce
Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent custom labeling data for inclusion in this set. A policy-aware client SHOULD preclude
policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the the user from producing &LABEL; values which the user's own clearance does not grant
display marking prescribed for the &LABEL; under the governing policy, or, access to, and SHOULD preclude sending any label which the user's own clearance does not
if the governing policy prescribes no display marking for the &LABEL;, grant access to. Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an
absent.</p> equivalent policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the display
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently marking prescribed for the &LABEL; under the governing policy, or, if the governing
display the &DISPLAYMARKING; value. A policy-aware may alternatively policy prescribes no display marking for the &LABEL;, absent.</p>
prominently display the marking for the &LABEL; prescribed by the governing <p>A client which receives a stanza with &SECURITYLABEL; element is to prominently display
policy.</p> the &DISPLAYMARKING; value. A policy-aware client may alternatively prominently display
<p>Each server is expected to make a number of sensitivity-based authorization the marking for the &LABEL; prescribed by the governing policy.</p>
decisions. Each decision is made by evaluating an Access Control Decision <p>Each server is expected to make a number of sensitivity-based authorization decisions.
Function (ACDF) with a governing policy, a clearance, and a security label. Each decision is made by evaluating an Access Control Decision Function (ACDF) with a
The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p> governing policy, a clearance, and a security label. The ACDF yields either
<p>If the user holds a valid clearance (known to the server) under the <em>Grant</em> or <em>Deny</em>.</p>
governing policy, the clearance input is the user's clearance. Otherwise, <p>If the user holds a valid clearance (known to the server) under the governing policy, the
if the governing policy provides a default clearance, the clearance input clearance input is the user's clearance. Otherwise, if the governing policy provides a
is the default clearance. Otherwise, the clearance input is the nil clearance. default clearance, the clearance input is the default clearance. Otherwise, the
The nil clearance is a clearance for which the ACDF always returns Deny when clearance input is the nil clearance. The nil clearance is a clearance for which the
given as the clearance input.</p> ACDF always returns Deny when given as the clearance input.</p>
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; <p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; element or
element or one of the &EQUIVALENTLABEL; elements contain an appropriate label, one of the &EQUIVALENTLABEL; elements contain an appropriate label, that label input is
that label input is that label. Otherwise, the label input is the default that label. Otherwise, the label input is the default label provided the governing
label provided the governing policy or, if no default label is provided, policy or, if no default label is provided, the nil label. The nil label is a label for
the nil label. The nil label is a label for which the ACDF always returns which the ACDF always returns Deny when given as the label input.</p>
Deny when given as the label input.</p> <p>The term "effective clearance" and "effective label" refer, respectively, to the
<p>The term "effective clearance" and "effective label" refer, respectively, clearance and label provided as input to the ACDF.</p>
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
<p>Not all sensitivity-based authorization decisions an XMPP server might make user clearance and/or stanza label. A server may only provide service to users which
involve a user clearance and/or stanza label. A server may only provide hold an appropriate clearance as determined by calling the ACDF with the user's
service to users which hold an appropriate clearance as determined by calling clearance and a label associated with the service. A clearance might also be associated
the ACDF with the user's clearance and a label associated with the service. with the service to restrict the set of labels may be used in labeling stanzas. Labels
A clearance might also be associated with the service to restrict the set and clearances can also be associated with network interfaces, remote servers, and chat
of labels may be used in labeling stanzas. Labels and clearances can also rooms.</p>
be associated with network interfaces, remote servers, chat rooms, pubsub <section2 topic="Use in Instant Messaging" anchor="im-use">
nodes.</p> <p>A client may provide a &SECURITYLABEL; element in any <tt>&MESSAGE;</tt> it sends.</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: <p>The server will make, at a minimum, the following accessing control decisions:
<ul> <ul>
<li>TBD</li> <li>TBD</li>
@ -447,54 +458,47 @@ Otherwise the from= attribute in the &CATALOG; element is absent.
</p> </p>
--> -->
</section2> </section2>
<section2 topic='Use in Group Chat and Multi-User Chat' anchor='muc-use'> <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> <p>A client may provide a &SECURITYLABEL; element in <tt>&MESSAGE;</tt> stanzas.</p>
<section3 topic='Discovery' anchor='muc-disco'> <section3 topic="Discovery" anchor="muc-disco">
<p>A server SHOULD provide a label feature and information discovery for the room.</p> <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> <p>Clients SHOULD discover label feature and information on a per room basis.</p>
</section3> </section3>
<section3 topic='Sending Messages' anchor='muc-send'>
<p>Sending groupchat messages is similar to sending normal messages, however <section3 topic="Sending Messages" anchor="muc-send">
their are a few differences.</p> <p>Sending groupchat messages is similar to sending normal messages, however their
<p>Groupchat messages are addressed to the room. The room clearance must are a few differences.</p>
be suitable for the message label, else it should be rejected.</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 <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 participants may be cleared for all labels allowed in the room. The server MUST
MUST only deliver messages to participants for which they are cleared to only deliver messages to participants for which they are cleared to receive.</p>
receive.</p>
</section3> </section3>
<section3 topic='Private Messages' anchor='muc-private'> <section3 topic="Room History" anchor="muc-history">
<p>Private messages are treated as discussed in the "Use in Instant Messaging" <p>The server MUST only deliver messages to participants for which they are cleared
section. (Should private messages be restricted by room's configuration?)</p> to receive.</p>
</section3> </section3>
<section3 topic='Invitations' anchor='muc-invite'> <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> <p>Invitations may be labeled.</p>
</section3> </section3>
<section3 topic='Changing Subject' anchor='muc-subject'> <section3 topic="Room Subject" anchor="muc-subject">
<p>This section discusses semantics of &SECURITYLABEL; elements contained <p>A stanza intended to change the room subject SHOULD not carry a security label
in &MESSAGE; stanzas containing a &SUBJECT; element.</p> and SHOULD NOT be subject to security-label authorization checks. Such a stanza
<p>The presence of a &SECURITYLABEL; element indicates a request to change does not have any impact on the security-label parameters associated with the
the room's label, either to the provided label or, if the element is empty, room.</p>
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 kick
all members whom are not cleared for that label out of the room.</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>
<section3 topic='Room Configuration' anchor='muc-config'> <section3 topic="Room Configuration" anchor="muc-config">
<p>The server may allow for configuration of security label parameters <p>The server may allow for configuration of security label parameters via room
via room configuration mechanisms. The approach is intended to be configuration mechanisms. The approach is intended to be ad-hoc. Hence this
ad-hoc. Hence this section is intended to be illustrative of one section is intended to be illustrative of one possible approach. Implementations
possible approach. Implementations are free to utilize other are free to utilize other approaches.</p>
approaches.</p>
<example caption="Room Configuration Form"><![CDATA[ <example caption="Room Configuration Form"><![CDATA[
<iq from='room@muc.example.com' <iq from='room@muc.example.com'
id='create1' id='create1'
@ -527,14 +531,14 @@ Otherwise the from= attribute in the &CATALOG; element is absent.
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<p>In the above example, the server allows the room label to be set to one of <p>In the above example, the server allows the room label to be set to one of to a
to a subset of labels from the label catalog (see below), using the display subset of labels from the label catalog (see below), using the display name for
name for selection, as well as custom label support. For custom label choice selection, as well as custom label support. For custom label choice support, the
support, the server offers an single text box for entry of an appropriate server offers an single text box for entry of an appropriate text string
text string indicating the label to use. Likewise for the room clearance indicating the label to use. Likewise for the room clearance and default room
and default room clearance.</p> clearance.</p>
<p>Though offering choices from the label catalog is often desirable, <p>Though offering choices from the label catalog is often desirable, a server could
a server could only offer custom label and/or clearance support.</p> only offer custom label and/or clearance support.</p>
<example caption="Room Configuration Form"><![CDATA[ <example caption="Room Configuration Form"><![CDATA[
<iq from='room@muc.example.com' <iq from='room@muc.example.com'
id='create1' id='create1'
@ -554,125 +558,51 @@ Otherwise the from= attribute in the &CATALOG; element is absent.
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
<section2 topic='Use in Presence' anchor='presence-use'> <section2 topic="Use in Presence" anchor="presence-use">
<p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server <p>&SECURITYLABEL; elements are not to appear in <tt>&PRESENCE;</tt> stanzas. Server SHALL treat
SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a any <tt>&PRESENCE;</tt> stanza that contains a &SECURITYLABEL; as a protocol violation.</p>
protocol violation.</p> <p>Presence information is subject to sensitivity-base authorization decisions, however
<p>Presence information is subject to sensitivity-base authorization decisions, these decisions are made are made using a label associated with the presence
however these decisions are made are made using a label associated with the resource, such as a chat room's label.</p>
presence resource, such as a chat room's label.</p>
</section2> </section2>
<section2 topic='Use in PubSub' anchor='pubsub-use'> </section1>
<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'> <section1 topic="Extension Considerations" anchor="exts">
<p> <p> This extension is itself extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
elements are designed to hold a range of security labels formats. XML name spaces SHOULD elements are designed to hold a range of security labels formats. XML name spaces SHOULD
be used to avoid name clashes. be used to avoid name clashes. </p>
</p> <p> Future documents may specify how security-labels are used in other areas of XMPP, such
</section1> as PubSub.</p>
</section1>
<!-- <!--
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<p>OPTIONAL.</p> <p>OPTIONAL.</p>
</section1> </section1>
--> -->
<section1 topic='Security Considerations' anchor='security'> <section1 topic="Security Considerations" anchor="security">
<p>This document is all about authorization, a key aspect of security. Hence, <p>This document is all about authorization, a key aspect of security. Hence, security
security considerations are discussed through this document.</p> considerations are discussed through this document.</p>
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject <p>Nothing in this document ensures appropriate labeling the sensitivity of a piece of
to any sensitivity-based authorization decisions, and may be forwarded throughout information. Addressing inappropriate labeling of information is beyond the scope of
the XMPP network. The content of these stanzas should not contain information this document.</p>
requiring sensitivity-based dissemination controls.</p> <p>Certain XMPP stanzas, such as <tt>&PRESENCE;</tt> stanzas, are not themselves subject to any
<p>It is desirable to securely bind the security label to the object it labels. sensitivity-based authorization decisions, and may be forwarded throughout the XMPP
This may be accomplished through use of digital signatures. Specification of such network. The content of these stanzas should not contain information requiring
is left to a future document. sensitivity-based dissemination controls.</p>
</p> <p>It is desirable to securely bind the security label to the object it labels. This may be
</section1> accomplished through use of digital signatures. Specification of such is left to a
<section1 topic='IANA Considerations' anchor='iana'> future document. </p>
</section1>
<section1 topic="IANA Considerations" anchor="iana">
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic="XMPP Registrar Considerations" anchor="registrar">
<p>It is requested the &REGISTRAR; add the extension's namespaces <p>It is requested the &REGISTRAR; add the extension's namespaces and schemas to appropriate
and schemas to appropriate XMPP registries.</p> XMPP registries.</p>
</section1> </section1>
<section1 topic='XML Schemas' anchor='schema'> <section1 topic="XML Schemas" anchor="schema">
<section2 topic='Extension Schema' anchor='schema-sl'> <section2 topic="Extension Schema" anchor="schema-sl">
<p> <p>
<code><![CDATA[ <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
@ -771,14 +701,11 @@ And by opposing end them?
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code> A copy of this schema is available at <link
url="http://www.xmpp.org/schemas/sec-label.xsd">
A copy of this schema is available at http://www.xmpp.org/schemas/sec-label.xsd</link>. </p>
<link url='http://www.xmpp.org/schemas/sec-label.xsd'> </section2>
http://www.xmpp.org/schemas/sec-label.xsd</link>. <section2 topic="&lt;catalog/&gt; schema" anchor="schema-catalog">
</p>
</section2>
<section2 topic='&lt;catalog/&gt; schema' anchor='schema-catalog'>
<p> <p>
<code><![CDATA[ <code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
@ -874,14 +801,11 @@ And by opposing end them?
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code> A copy of this schema is available at <link
url="http://www.xmpp.org/schemas/sec-label-catalog.xsd">
A copy of this schema is available at http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
<link url='http://www.xmpp.org/schemas/sec-label-catalog.xsd'> </section2>
http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. <section2 topic="&lt;esssecuritylabel/&gt; schema" anchor="schema-ess">
</p>
</section2>
<section2 topic='&lt;esssecuritylabel/&gt; schema' anchor='schema-ess'>
<p> <p>
<code><![CDATA[ <code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
@ -899,12 +823,9 @@ And by opposing end them?
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code> A copy of this schema is available at <link
url="http://www.xmpp.org/schemas/sec-label-ess.xsd">
A copy of this schema is available at http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
<link url='http://www.xmpp.org/schemas/sec-label-ess.xsd'> </section2>
http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </section1>
</p>
</section2>
</section1>
</xep> </xep>