moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-25 02:32:18 -05:00
Code Issues Releases Wiki Activity

Revert unpublished XEP 258 changes

Browse Source 
This patch reverts changes to XEP 258 originally committed with:
    c1173e8cf7a40a936e68a873069e191b846c7182

The previous two commits should be a no-op (I mistakenly hit
'push' instead of 'commit' when trying to construct this patch,
and then reverted that mistake.)
This commit is contained in:
Kurt Zeilenga 2010-10-17 13:02:58 -07:00
parent 560b05f8a9
commit c3cd0f554b
1 changed files with 396 additions and 411 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

799
xep-0258.xml
View File

@ -12,113 +12,94 @@
]> ]>
<?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 specifies <abstract>This document describes the use of security labels in XMPP. The document
how security label metadata is carried in XMPP, when this metadata should or should not specifies how security label metadata is carried in XMPP, when this metadata
be provided, and how the metadata is to be processed.</abstract> should or should not be provided, and how the metadata is to be processed.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0258</number> <number>0258</number>
<status>Experimental</status> <status>Experimental</status>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<approver>Council</approver> <approver>Council</approver>
<dependencies> <dependencies>
<spec>XMPP Core</spec> <spec>XMPP Core</spec>
<spec>XEP-0001</spec> <spec>XEP-0001</spec>
<spec>XEP-0285</spec> </dependencies>
</dependencies> <supersedes/>
<supersedes/> <supersededby/>
<supersededby/> <shortname>sec-label</shortname>
<shortname>sec-label</shortname> <author>
&kdz; <firstname>Kurt</firstname>
<revision> <surname>Zeilenga</surname>
<version>0.7</version> <email>Kurt.Zeilenga@Isode.COM</email>
<date>2010-09-29</date> <jid>Kurt.Zeilenga@Isode.COM</jid>
<initials>kdz</initials> </author>
<remark> <revision>
<p>Add initial support for secure binding of labels (digital signatures).</p> <version>0.6</version>
</remark> <date>2010-07-30</date>
</revision> <initials>kdz</initials>
<revision> <remark><p>Extend catalog handling. Minor editorial changes.</p></remark>
<version>0.6</version> </revision>
<date>2010-07-30</date> <revision>
<initials>kdz</initials> <version>0.5</version>
<remark> <date>2009-07-27</date>
<p>Extend catalog handling. Minor editorial changes.</p> <initials>kdz</initials>
</remark> <remark><p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.</p></remark>
</revision> </revision>
<revision> <revision>
<version>0.5</version> <version>0.4</version>
<date>2009-07-27</date> <date>2009-07-23</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark> <remark><p>Update label catalogs to include user input selector.</p></remark>
<p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog </revision>
discovery. Clarify syntax of selector= attribute.</p> <revision>
</remark> <version>0.3</version>
</revision> <date>2009-03-20</date>
<revision> <initials>kdz</initials>
<version>0.4</version> <remark><p>Add text regarding default bg/fg colors. Correct examples.</p></remark>
<date>2009-07-23</date> </revision>
<initials>kdz</initials> <revision>
<remark> <version>0.2</version>
<p>Update label catalogs to include user input selector.</p> <date>2009-03-10</date>
</remark> <initials>kdz</initials>
</revision> <remark><p>Reworked discovery and various updates.</p></remark>
<revision> </revision>
<version>0.3</version> <revision>
<date>2009-03-20</date> <version>0.1</version>
<initials>kdz</initials> <date>2009-01-05</date>
<remark> <initials>psa</initials>
<p>Add text regarding default bg/fg colors. Correct examples.</p> <remark><p>Initial published version.</p></remark>
</remark> </revision>
</revision> <revision>
<revision> <version>0.0.081203</version>
<version>0.2</version> <date>2008-12-03</date>
<date>2009-03-10</date> <initials>kdz</initials>
<initials>kdz</initials> <remark><p>Initial draft.</p></remark>
<remark> </revision>
<p>Reworked discovery and various updates.</p> </header>
</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"> <section1 topic='Introduction' anchor='intro'>
<p>A security label, sometimes referred to as a confidentiality label, is a structured <p>A security label, sometimes referred to as a confidentiality label, is
representation of the sensitivity of a piece of information. A security label is used in a structured representation of the sensitivity of a piece of information. A security
conjunction with a clearance, a structured representation of what information label is used in conjunction with a clearance, a structured representation of what
sensitivities a person (or other entity) is authorized to access, and a security policy information sensitivities a person (or other entity) is authorized to access, and a security
to control access to each piece of information. For instance, message could be labeled policy to control access to each piece of information. For instance, message could be
as "SECRET", and hence requiring the sender and the receiver to have a clearance labeled as "SECRET", and hence requiring the sender and the receiver to have a
granting access to "SECRET" information. &X.841; provides a discussion of security clearance granting access to "SECRET" information. &X.841; provides a discussion of
labels, clearances, and security policy.</p> security 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 military agency networks. The information classification rules, such as in government military 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 how <p>This document describes the use of security labels in &xmpp;. The document specifies
security label metadata is carried in XMPP. It standardizes a mechanism for carrying ESS how security label metadata is carried in XMPP. It standardizes a mechanism for
Security Labels in XMPP, as well as provides for use of other label formats. ESS carrying ESS Security Labels in XMPP, as well as provides for use of other label
Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are
conjunction with &X.500; clearances and either X.841 or &SDN.801c; security commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
policies.</p> security 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>
<securitylabel xmlns='urn:xmpp:sec-label:0'> <securitylabel xmlns='urn:xmpp:sec-label:0'>
@ -129,7 +110,7 @@
</securitylabel> </securitylabel>
</message> </message>
]]></example> ]]></example>
<example caption="Message with IC-ISM Label"><![CDATA[ <example caption="Message with IC-ISM 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>
<securitylabel xmlns='urn:xmpp:sec-label:0'> <securitylabel xmlns='urn:xmpp:sec-label:0'>
@ -139,67 +120,37 @@
</securitylabel> </securitylabel>
</message> </message>
]]></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>To securely bind the security label to the message, &xep0285; can be used as detailed below.</p> <p>The document details when security label metadata should or should not be provided, and how
<example caption="Message with Securely bound ESS Security Label"><![CDATA[ this metadata is to be processed.</p>
<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 <p>This document does <em>not</em> provide:
how this metadata is to be processed.</p> <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>
<p>This document does <em>not</em> provide: Such mechanisms may be introduced in subsequent documents.</p>
<ul> </section1>
<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"> <section1 topic='Discovering Feature Support' anchor='disco'>
<p>If an entity supports the XMPP Security Label protocol, it MUST report that fact by <p>If an entity supports the XMPP Security Label protocol, it MUST report that fact
including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in response to by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in
a &xep0030; information request. Clients wishing to include a XMPP Security Label response to a &xep0030; information request. Clients wishing to include a XMPP
element in any stanza they generate SHOULD determine if their server supports the XMPP Security Label element in any stanza they generate SHOULD determine if their
Security Label protocol. If their server does not support XMPP Security Label, the server supports the XMPP Security Label protocol. If their server does not
client SHOULD NOT generate XMPP Security Labels as the server not supporting this support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels
protocol will generally ignore XMPP Security Labels as they would any other unrecognized as the server not supporting this protocol will generally ignore XMPP Security
element.</p> 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 <p>As each service domain may have different support for security labels, servers
report the fact by including a service discover feature of should advertise and clients should perform appropriate discovery lookups on a
"<tt>urn:xmpp:sec-label:dsig:0</tt>"" in response to a &xep0030; information request. per service basis.</p>
Clients wishing to include a securely bound XMPP Security Label element in any stanza <example caption="Service Discovery information request"><![CDATA[
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' <iq type='get'
from='user@example.com/Work' from='user@example.com/Work'
to='example.com' to='example.com'
@ -207,7 +158,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Service Discovery information response"><![CDATA[ <example caption="Service Discovery information response"><![CDATA[
<iq type='result' <iq type='result'
from='example.com' from='example.com'
to='user@example.com/Work' to='user@example.com/Work'
@ -215,22 +166,21 @@
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
... ...
<feature var='urn:xmpp:sec-label:0'/> <feature var='urn:xmpp:sec-label:0'/>
<feature var='urn:xmpp:sec-label:dsig:0'/>
... ...
</query> </query>
</iq> </iq>
]]></example> ]]></example>
<!-- <!--
<p>A server should only include &IDENTITY; elements in the response for services <p>A server should only include &IDENTITY; elements in the response for services
the user is cleared to use.</p> the user is cleared to use.</p>
--> -->
</section1> </section1>
<section1 topic="Protocol" anchor="protocol"> <section1 topic='Protocol' anchor='protocol'>
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata <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 includes a security label, zero or more equivalent security labels, and optionally display
display marking data.</p> 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>
<securitylabel xmlns='urn:xmpp:sec-label:0'> <securitylabel xmlns='urn:xmpp:sec-label:0'>
@ -246,77 +196,93 @@
</securitylabel> </securitylabel>
</message> </message>
]]></example> ]]></example>
<p>The security label metadata is carried in an &SECURITYLABEL; element. The &SECURITYLABEL; <p>The security label metadata is carried in an &SECURITYLABEL; element.
element which contains one and only one &LABEL; element, zero or more &EQUIVALENTLABEL; The &SECURITYLABEL; element which contains one and only one &LABEL; element,
elements, and an optional &DISPLAYMARKING; element.</p> 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 <p>The &LABEL; provides the primary security label. It is commonly issued
under the security policy of that they and their home server operating under. The by the sender under the security policy of that they and their home
&LABEL; contains either a single element representing the primary security label or is server operating under. The &LABEL; contains either a single element
empty to indicate use of a default.</p> representing the primary security label or is empty to indicate use of
<p>Each &EQUIVALENTLABEL; represents an equivalent security label under other policies. Each a default.</p>
&EQUIVALENTLABEL; contains a single element representing the equivalent label. This <p>Each &EQUIVALENTLABEL; represents an equivalent security label under
element might be used when a recepient is known to hold a clearance under a different other policies. Each &EQUIVALENTLABEL; contains a single element
policy than the sender.</p> representing the equivalent label. This element might be used when
<p>The &DISPLAYMARKING; element contains a display string for use by implementations which a recepient is known to hold a clearance under a different policy
are unable to utilize the applicable security policy to generate display markings. The than the sender.</p>
element may optionally contain two attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, <p>The &DISPLAYMARKING; element contains a display string for use by
whose values are HTML color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for implementations which are unable to utilize the applicable security policy
use in colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>. to generate display markings. The element may optionally contain two
The <tt>bgcolor=</tt> default is <tt>white</tt>. </p> attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML
</section1> 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"> <section1 topic='Label Catalog Discovery' anchor='label-catalog'>
<p>A client can request a catalog for a particular JID by sending a catalog discovery <p>A client can request a catalog for a particular JID by sending
request to the client's server. Where the JID is hosted by some other server, the a catalog discovery request to the client's server. Where the JID
client's server is expected to produce a suitable catalog (or fail the request). The is hosted by some other server, the client's server is expected to
client's server may, as needed, query catalogs from other servers in order to fulfill produce a suitable catalog (or fail the request). The client's server
the client's request.</p> may, as needed, query catalogs from other servers in order to
<p>While this specification does not preclude a client from directing a catalog request fulfill the client's request.</p>
elsewhere, it is noted that catalog returned by a party other than its server may not be <p>While this specification does not preclude a client from directing
directly useable by the client. For instance, the client's server might require a a catalog request elsewhere, it is noted that catalog returned by
particular only-locally-known label be used in messages to a particular remote JID.</p> a party other than its server may not be directly useable by the
<p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p> client. For instance, the client's server might require a particular
<p>If catalog is restrictive, as indicated by the restrictive attribute with value of true, only-locally-known label be used in messages to a particular remote
the client SHOULD use one of the labels (or no label) offered by the catalog.</p> JID.</p>
<p>One and only one of the items may have a default attribute with value of true. The client <p>It is RECOMMENDED the server publish catalogs of security label
should default to this item in cases where the user has not selected an item.</p> for use by clients.</p>
<p>An item may have no label. Such an item offers a choice of sending a stanza without a <p>If catalog is restrictive, as indicated by the restrictive attribute
label.</p> with value of true, the client SHOULD use one of the labels
<p>Each catalog provided should only contain labels for which the client is allowed to use (or no label) offered by the catalog.</p>
(based upon the user's authorization) in a particular context (such as in chatroom). A <p>One and only one of the items may have a default attribute with
catalog may not be include the complete set of labels available for the use by the value of true. The client should default to this item in cases
client in the context.</p> where the user has not selected an item.</p>
<blockquote>Note: the single catalog per context approach used here is likely inadequate in <p>An item may have no label. Such an item offers a choice of
enviroments where there are a large number of labels in use. It is expected that a more sending a stanza without a label.</p>
sophisticated approach will be introduced in a subsequent revision of this <p>Each catalog provided should only contain labels for which the client
specification.</blockquote> is allowed to use (based upon the user's authorization) in a particular
<p>As each service domain may have different support for security labels, servers should context (such as in chatroom). A catalog may not be include the
advertise and clients should perform appropriate discovery lookups on a per service complete set of labels available for the use by the client in the
basis.</p> context.</p>
<p>To indicate the support for label catalog discovery, a server advertises the <blockquote>Note: the single catalog per context approach used here
<tt>urn:xmpp:sec-label:catalog:2</tt> feature. The following pair of examples is likely inadequate in enviroments where there are a large number
illustrates this feature discovery.</p> of labels in use. It is expected that a more sophisticated approach
<p>Each item in the catalog may contain a selector attribute. The value of this attribute will be introduced in a subsequent revision of this
represents the item's placement in a hierarchical organization of the items. The value specification.</blockquote>
of the selector attribute conforms to the selector-value ABNF production: <blockquote> <p>As each service domain may have different support for security labels,
<![CDATA[ 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> selector-value = (<item>"|")*<item>
]]> ]]>
</blockquote> </blockquote>
</p> </p>
<p>where &lt;item&gt; is a sequence of characters not including "|".</p> <p>where &lt;item&gt; 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" <p>A value of "X|Y|Z" indicates that this item is "Z" in the
subset of items. This information may be used, for instance, in generating label the "Y" subset of the "X" subset of items. This information may
selection menus in graphical user interfaces.</p> be used, for instance, in generating label selection menus in
<blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote> graphical user interfaces.</p>
<example caption="Label Catalog Feature Discovery request"><![CDATA[ <blockquote>Note: use of unnecessarily deep hierarchies should be
avoided.</blockquote>
<example caption="Label Catalog Feature Discovery request"><![CDATA[
<iq type='get' <iq type='get'
from='user@example.com/Work' from='user@example.com/Work'
id='disco1'> id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Label Information Feature Discovery response"><![CDATA[ <example caption="Label Information Feature Discovery response"><![CDATA[
<iq type='result' <iq type='result'
from='example.com' from='example.com'
to='user@example.com/Work' to='user@example.com/Work'
@ -329,17 +295,15 @@ selector-value = (<item>"|")*<item>
</iq> </iq>
]]></example> ]]></example>
<p>The following example pair illustrates catalog discovery. Note that client directs the <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>
&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[ <example caption="Label Catalog request"><![CDATA[
<iq type='get' id='cat1'> <iq type='get' id='cat1'>
<catalog xmlns='urn:xmpp:sec-label:catalog:2' to='example.com'/> <catalog xmlns='urn:xmpp:sec-label:catalog:2' to='example.com'/>
</iq> </iq>
]]></example> ]]></example>
<example caption="Label Catalog Get response"><![CDATA[ <example caption="Label Catalog Get response"><![CDATA[
<iq type='result' to='user@example.com/Work' id='cat1'> <iq type='result' to='user@example.com/Work' id='cat1'>
<catalog xmlns='urn:xmpp:sec-label:catalog:2' <catalog xmlns='urn:xmpp:sec-label:catalog:2'
to='example.com' name='Default' to='example.com' name='Default'
@ -376,113 +340,122 @@ selector-value = (<item>"|")*<item>
</catalog> </catalog>
</iq> </iq>
]]></example> ]]></example>
</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 made <p>The sensitivity-based access control decisions discussed herein are to be
independently of other access control decisions or other facilities. That is, the made independently of other access control decisions or other facilities.
sensitivity-based access control decisions are not conditional on other factors.</p> That is, the sensitivity-based access control decisions are not conditional
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by this on other factors.</p>
document, or other formal specifications. Any other use of &SECURITYLABEL; SHOULD be <p>It is intended that &SECURITYLABEL; elements are only used as prescribed by
viewed as a protocol violation. The stanza SHOULD be discarded with, if approrpriate, an this document, or other formal specifications. Any other use of
error response. Such error responses SHOULD NOT include content from the violating &SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD
stanza, excepting that necessary to well-formed error responses.</p> be discarded with, if approrpriate, an error response. Such error responses
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. Absence of SHOULD NOT include content from the violating stanza, excepting that
a &SECURITYLABEL; element implies the stanza has the default label as specified in the necessary to well-formed error responses.</p>
governing security policy. Given that the governing policy may not specify a default <p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED.
label, hence denying access to the stanza, supporting clients SHOULD provide a Absence of a &SECURITYLABEL; element implies the stanza has the default label
&SECURITYLABEL; element where prescribed.</p> as specified in the governing security policy. Given that the governing
<p>Typically, a client would allow the user to choose populate the &SECURITYLABEL; from one policy may not specify a default label, hence denying access to the stanza,
of from a small set of security labels selections known to it (through configuration supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p>
and/or discovery and/or other means), such as from a pull-down menu. That selection <p>Typically, a client would allow the user to choose populate the
would include appropriate values for the &LABEL;, &DISPLAYMARKING;, and &SECURITYLABEL; from one of from a small set of security labels selections
&EQUIVALENTLABEL; elements.</p> known to it (through configuration and/or discovery and/or other means),
<p>A policy-aware client may provide the user with an interface allowing the user to produce such as from a pull-down menu. That selection would include appropriate
custom labeling data for inclusion in this set. A policy-aware client SHOULD preclude values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p>
the user from producing &LABEL; values which the user's own clearance does not grant <p>A policy-aware client may provide the user with an interface allowing the
access to, and SHOULD preclude sending any label which the user's own clearance does not user to produce custom labeling data for inclusion in this set. A
grant access to. Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an policy-aware client SHOULD preclude the user from producing &LABEL; values
equivalent policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the display which the user's own clearance does not grant access to, and SHOULD preclude
marking prescribed for the &LABEL; under the governing policy, or, if the governing sending any label which the user's own clearance does not grant access to.
policy prescribes no display marking for the &LABEL;, absent.</p> Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently display policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the
the &DISPLAYMARKING; value. A policy-aware may alternatively promiently display the display marking prescribed for the &LABEL; under the governing policy, or,
marking for the &LABEL; prescribed by the governing policy.</p> if the governing policy prescribes no display marking for the &LABEL;,
<p>Each server is expected to make a number of sensitivity-based authorization decisions. absent.</p>
Each decision is made by evaluating an Access Control Decision Function (ACDF) with a <p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
governing policy, a clearance, and a security label. The ACDF yields either display the &DISPLAYMARKING; value. A policy-aware may alternatively
<em>Grant</em> or <em>Deny</em>.</p> promiently display the marking for the &LABEL; prescribed by the governing
<p>If the user holds a valid clearance (known to the server) under the governing policy, the policy.</p>
clearance input is the user's clearance. Otherwise, if the governing policy provides a <p>Each server is expected to make a number of sensitivity-based authorization
default clearance, the clearance input is the default clearance. Otherwise, the decisions. Each decision is made by evaluating an Access Control Decision
clearance input is the nil clearance. The nil clearance is a clearance for which the Function (ACDF) with a governing policy, a clearance, and a security label.
ACDF always returns Deny when given as the clearance input.</p> The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p>
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; element or <p>If the user holds a valid clearance (known to the server) under the
one of the &EQUIVALENTLABEL; elements contain an appropriate label, that label input is governing policy, the clearance input is the user's clearance. Otherwise,
that label. Otherwise, the label input is the default label provided the governing if the governing policy provides a default clearance, the clearance input
policy or, if no default label is provided, the nil label. The nil label is a label for is the default clearance. Otherwise, the clearance input is the nil clearance.
which the ACDF always returns Deny when given as the label input.</p> The nil clearance is a clearance for which the ACDF always returns Deny when
<p>The term "effective clearance" and "effective label" refer, respectively, to the given as the clearance input.</p>
clearance and label provided as input to the ACDF.</p> <p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL;
<p>Not all sensitivity-based authorization decisions an XMPP server might make involve a element or one of the &EQUIVALENTLABEL; elements contain an appropriate label,
user clearance and/or stanza label. A server may only provide service to users which that label input is that label. Otherwise, the label input is the default
hold an appropriate clearance as determined by calling the ACDF with the user's label provided the governing policy or, if no default label is provided,
clearance and a label associated with the service. A clearance might also be associated the nil label. The nil label is a label for which the ACDF always returns
with the service to restrict the set of labels may be used in labeling stanzas. Labels Deny when given as the label input.</p>
and clearances can also be associated with network interfaces, remote servers, <p>The term "effective clearance" and "effective label" refer, respectively,
chatrooms, pubsub notes.</p> to the clearance and label provided as input to the ACDF.</p>
<section2 topic="Use in Instant Messaging" anchor="im-use"> <p>Not all sensitivity-based authorization decisions an XMPP server might make
<p>A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.</p> 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: <p>The server will make, at a minimum, the following accessing control decisions:
<ul> <ul>
<li>TBD</li> <li>TBD</li>
</ul> </ul>
</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 &MESSAGE; 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 <p>A server SHOULD provide a label feature and information discovery for the room.</p>
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'>
<section3 topic="Sending Messages" anchor="muc-send"> <p>Sending groupchat messages is similiar to sending normal messages, however
<p>Sending groupchat messages is similiar to sending normal messages, however their their are a few differences.</p>
are a few differences.</p> <p>Groupchat messages are addressed to the room. The room clearance must
<p>Groupchat messages are addressed to the room. The room clearance must be suitable be suitable for the message label, else it should be rejected.</p>
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 partipants partipants may be cleared for all labels allowed in the room. The server
may be cleared for all labels allowed in the room. The server MUST only deliver MUST only deliver messages to partipants for which they are cleared to
messages to partipants for which they are cleared to receive.</p> receive.</p>
</section3> </section3>
<section3 topic="Private Messages" anchor="muc-private"> <section3 topic='Private Messages' anchor='muc-private'>
<p>Private messages are treated as discussed in the "Use in Instant Messaging" <p>Private messages are treated as discussed in the "Use in Instant Messaging"
section. (Should private messages be restricted by room's configuration?)</p> section. (Should private messages be restricted by room's configuration?)</p>
</section3> </section3>
<section3 topic="Invitations" anchor="muc-invite"> <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='Changing Subject' anchor='muc-subject'>
<p>This section discusses semantics of &SECURITYLABEL; elements contained in <p>This section discusses semantics of &SECURITYLABEL; elements contained
&MESSAGE; stanzas containing a &SUBJECT; element.</p> in &MESSAGE; stanzas containing a &SUBJECT; element.</p>
<p>The presence of a &SECURITYLABEL; element indicates a request to change the <p>The presence of a &SECURITYLABEL; element indicates a request to change
room's label, either to the provided label or, if the element is empty, to unset the room's label, either to the provided label or, if the element is empty,
the room's label. The server is to refuse the request if the requestor is not to unset the room's label. The server is to refuse the request if the
authorized to change the subject, not cleared for the requested label, or if the requestor is not authorized to change the subject, not cleared for the
server is otherwise unwilling or unable to make the change. If the label change requested label, or if the server is otherwise unwilling or unable to make
is refused, so must the accompanied subject change. Likewise, if the subject the change. If the label change is refused, so must the accompanied
change is refused, so must the accompanied label change.</p> subject change. Likewise, if the subject change is refused, so must the
<p>Upon change of the room's label, the server MUST immediately remove from the room accompanied label change.</p>
all members whom are not cleared for that label.</p> <p>Upon change of the room's label, the server MUST immediately remove from
<p>In absence of a &SECURITYLABEL; element, the label associated with the room is the room all members whom are not cleared for that label.</p>
unchanged.</p> <p>In absence of a &SECURITYLABEL; element, the label associated with the
<p>The room's label can also be changed through room configuration (to be discussed room is unchanged.</p>
in later revision of this document).</p> <p>The room's label can also be changed through room configuration (to be
</section3> discussed in later revision of this document).</p>
<!-- </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 configuration mechanisms. The approach is intended to be via room configuration mechanisms. The approach is intended to be
@ -555,23 +528,23 @@ selector-value = (<item>"|")*<item>
]]></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 SHALL treat <p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server
any &PRESENCE; stanza that contains a &SECURITYLABEL; as a protocol violation.</p> SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a
<p>Presence information is subject to sensitivity-base authorization decisions, however protocol violation.</p>
these decisions are made are made using a label associated with the presence <p>Presence information is subject to sensitivity-base authorization decisions,
resource, such as a chatroom's label.</p> however these decisions are made are made using a label associated with the
</section2> presence resource, such as a chatroom's label.</p>
<section2 topic="Use in PubSub" anchor="pubsub-use"> </section2>
<section3 topic="Discovery" anchor="pubsub-disco"> <section2 topic='Use in PubSub' anchor='pubsub-use'>
<p>A server SHOULD provide a label feature and information discovery for each <section3 topic='Discovery' anchor='pubsub-disco'>
node.</p> <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> <p>Clients SHOULD discover label feature and information on a per node basis.</p>
</section3> </section3>
<section3 topic="Publishing items with Security Labels" anchor="muc-send"> <section3 topic='Publishing items with Security Labels' anchor='muc-send'>
<p>Each item may be individually labeled.</p> <p>Each item may be individually labeled.</p>
<example caption="Publishing with a Security Label"><![CDATA[ <example caption="Publishing with a Security Label"><![CDATA[
<iq type='set' <iq type='set'
from='hamlet@denmark.lit/blogbot' from='hamlet@denmark.lit/blogbot'
to='pubsub.shakespeare.lit' to='pubsub.shakespeare.lit'
@ -605,8 +578,8 @@ And by opposing end them?
</pubsub> </pubsub>
</iq> </iq>
]]></example> ]]></example>
<p>The service then notifies appropriately cleared subscribers.</p> <p>The service then notifies appropriately cleared subscribers.</p>
<example caption="Publishing with a Security Label"><![CDATA[ <example caption="Publishing with a Security Label"><![CDATA[
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'> <message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
<event xmlns='http://jabber.org/protocol/pubsub#event'> <event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node=princely_musings'> <items node=princely_musings'>
@ -637,42 +610,45 @@ And by opposing end them?
</event> </event>
</iq> </iq>
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
<section1 topic="Extension Considerations" anchor="exts"> <section1 topic='Extension Considerations' anchor='exts'>
<p> This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL; <p>
elements are designed to hold a range of security labels formats. XML namespaces SHOULD This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
be used to avoid name clashes. </p> elements are designed to hold a range of security labels formats. XML namespaces SHOULD
</section1> be used to avoid name clashes.
</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, security <p>This document is all about authorization, a key aspect of security. Hence,
considerations are discussed through this document.</p> security considerations are discussed through this document.</p>
<p>Security labels generally should be securely bound to the object. This may be <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> accomplished through use of &xmppe2e; signing, or possibly other signing
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject to any mechanisms.</p>
sensitity-based authorization decisions, and may be forwarded throughout the XMPP <p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
network. The content of these stanzas should not contain information requiring to any sensitity-based authorization decisions, and may be forwarded throughout
sensitivity-based dissemination controls.</p> the XMPP network. The content of these stanzas should not contain information
</section1> requiring sensitivity-based dissemination controls.</p>
<section1 topic="IANA Considerations" anchor="iana"> </section1>
<p>This document requires no interaction with &IANA;.</p> <section1 topic='IANA Considerations' anchor='iana'>
</section1> <p>This document requires no interaction with &IANA;.</p>
<section1 topic="XMPP Registrar Considerations" anchor="registrar"> </section1>
<p>It is requested the &REGISTRAR; add the extension's namespaces and schemas to appropriate <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
XMPP registries.</p> <p>It is requested the &REGISTRAR; add the extension's namespaces
</section1> and schemas to appropriate XMPP registries.</p>
<section1 topic="XML Schemas" anchor="schema"> </section1>
<section2 topic="Extension Schema" anchor="schema-sl"> <section1 topic='XML Schemas' anchor='schema'>
<p> <section2 topic='Extension Schema' anchor='schema-sl'>
<code><![CDATA[ <p>
<code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0" <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:0"
xmlns="urn:xmpp:sec-label:0" elementFormDefault="qualified"> xmlns="urn:xmpp:sec-label:0" elementFormDefault="qualified">
@ -769,13 +745,16 @@ And by opposing end them?
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> A copy of this schema is available at <link ]]></code>
url="http://www.xmpp.org/schemas/sec-label.xsd">
http://www.xmpp.org/schemas/sec-label.xsd</link>. </p> A copy of this schema is available at
</section2> <link url='http://www.xmpp.org/schemas/sec-label.xsd'>
<section2 topic="&lt;catalog/&gt; schema" anchor="schema-catalog"> http://www.xmpp.org/schemas/sec-label.xsd</link>.
<p> </p>
<code><![CDATA[ </section2>
<section2 topic='&lt;catalog/&gt; schema' anchor='schema-catalog'>
<p>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:sl="urn:xmpp:sec-label:0" <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" xmlns="urn:xmpp:sec-label:catalog:2" targetNamespace="urn:xmpp:sec-label:catalog:1"
@ -863,13 +842,16 @@ And by opposing end them?
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> A copy of this schema is available at <link ]]></code>
url="http://www.xmpp.org/schemas/sec-label-catalog.xsd">
http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. </p> A copy of this schema is available at
</section2> <link url='http://www.xmpp.org/schemas/sec-label-catalog.xsd'>
<section2 topic="&lt;esssecuritylabel/&gt; schema" anchor="schema-ess"> http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>.
<p> </p>
<code><![CDATA[ </section2>
<section2 topic='&lt;esssecuritylabel/&gt; schema' anchor='schema-ess'>
<p>
<code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:xmpp:sec-label:ess:0" <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"> xmlns="urn:xmpp:sec-label:ess:0" elementFormDefault="qualified">
@ -885,9 +867,12 @@ And by opposing end them?
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> A copy of this schema is available at <link ]]></code>
url="http://www.xmpp.org/schemas/sec-label-ess.xsd">
http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </p> A copy of this schema is available at
</section2> <link url='http://www.xmpp.org/schemas/sec-label-ess.xsd'>
</section1> http://www.xmpp.org/schemas/sec-label-ess.xsd</link>.
</p>
</section2>
</section1>
</xep> </xep>