mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-22 09:12:19 -05:00
64a830c57f
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2598 4b5297f7-1745-476d-ba37-a9c6900126ab
682 lines
33 KiB
XML
682 lines
33 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
<!ENTITY LABEL "<label/>">
|
|
<!ENTITY SECURITYLABEL "<securitylabel/>">
|
|
<!ENTITY DISPLAYMARKING "<displaymarking/>">
|
|
<!ENTITY EQUIVALENTLABEL "<equivalentlabel/>">
|
|
<!ENTITY HEADLINE "<headline/>">
|
|
<!ENTITY IDENTITY "<identity/>">
|
|
<!ENTITY rfc2634 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2634'>RFC 2634</link></span> <note>RFC 2634: Enhanced Security Services for S/MIME <<link url='http://tools.ietf.org/html/rfc2634'>http://tools.ietf.org/html/rfc2634</link>>.</note>" >
|
|
<!ENTITY ASN.1 "<span class='ref'><link url='http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf'>ASN.1</link></span> <note>X.680: Abstract Syntax Notation One (ASN.1): Specification of basic notation <<link url='http:://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf'>http:://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf</link>>.</note>" >
|
|
<!ENTITY BER "<span class='ref'><link url='http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf'>BER</link></span> <note>X.690: ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) <<link url='http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf'>http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf</link>>.</note>" >
|
|
<!ENTITY X.500 "<span class='ref'><link url='http://www.itu.int/rec/T-REC-X.500-200102-I/en'>X.500</link></span> <note>X.500: The Directory: Overview of concepts, models and service <<link url='http://www.itu.int/rec/T-REC-X.500-200102-I/en'>http://www.itu.int/rec/T-REC-X.500-200102-I/en</link>>.</note>" >
|
|
<!ENTITY X.841 "<span class='ref'><link url='http://www.itu.int/rec/T-REC-X.841-200010-I/en'>X.841</link></span> <note>X.841: Security techniques - Security information objects for access control <<link url='http://www.itu.int/rec/T-REC-X.841-200010-I/en'>http://www.itu.int/rec/T-REC-X.841-200010-I/en</link>>.</note>" >
|
|
<!ENTITY SDN.801c "<span class='ref'>SDN.801c</span> <note>SDN.801c: Access Control Concept and Mechanism, US National Security Agency, Revision C, 12 May 1999.</note>" >
|
|
<!ENTITY IC-ISM "<span class='ref'>IC-ISM</span> <note>Common Information Sharing Standard for Information Security Marking: XML Implementation, Office of the Director of National Intelligence,
|
|
Release 2.0.3, 15 February 2006.</note>" >
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Security Labels in XMPP</title>
|
|
<abstract>This document describes the use of security labels in XMPP. The document
|
|
specifies how security label metadata is carried in XMPP, when this metadata
|
|
should or should not be provided, and how the metadata is to be processed.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0258</number>
|
|
<status>Experimental</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0001</spec>
|
|
<spec>Etc.</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>sec-label</shortname>
|
|
<author>
|
|
<firstname>Kurt</firstname>
|
|
<surname>Zeilenga</surname>
|
|
<email>Kurt.Zeilenga@Isode.COM</email>
|
|
<jid>Kurt.Zeilenga@Isode.COM</jid>
|
|
</author>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2009-01-05</date>
|
|
<initials>psa</initials>
|
|
<remark><p>Initial published version.</p></remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.0.081203</version>
|
|
<date>2008-12-03</date>
|
|
<initials>kdz</initials>
|
|
<remark><p>Initial draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>A security label, sometimes referred to as a confidentiality label, is
|
|
a structured representation of the sensitivity of a piece of information. They are
|
|
used in conjunction with a clearance, a structured representation of what information
|
|
sensitivities a person (or other entity) is authorized to access, and a security
|
|
policy to control access to each piece of information. For instance, message could be
|
|
labeled as "SECRET", and hence requiring the sender and the receiver to have a
|
|
clearance granting access to "SECRET" information. &X.841; provides a discussion of
|
|
security labels, clearances, and security policy.</p>
|
|
<p>Sensitivity-based authorization is used in networks which operate under a set of
|
|
information classification rules, such as in government defense agency networks. The
|
|
standardized formats for security labels, clearances, and security policy are
|
|
generalized and do have application in non-government networks.</p>
|
|
<p>This document describes the use of security labels in &xmpp;. The document specifies
|
|
how security label metadata is carried in XMPP. It standardizes a mechanism for
|
|
carrying ESS Security Labels in XMPP, as well as provides for use of other label
|
|
formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are
|
|
commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
|
|
security policies.</p>
|
|
<example caption="Message with ESS Security Label"><![CDATA[
|
|
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
|
<body>This content is classified.</body>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
|
<label><esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
|
|
>MQYCAQIGASk=</esssecurityLabel></label>
|
|
</securityLabel>
|
|
</message>
|
|
]]></example>
|
|
<example caption="Message with IC-ISM Label"><![CDATA[
|
|
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
|
<body>This content is classified.</body>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
|
<label><icismlabel xmlns='http://example.gov/IC-ISM/0'
|
|
classification='S' ownerProducer='USA' disseminationControls='FOUO'/></label>
|
|
</securityLabel>
|
|
</message>
|
|
]]></example>
|
|
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
|
|
|
|
<p>The document details when security label metadata should or should not be provided, and how
|
|
this metadata is to be processed.</p>
|
|
<p>This document does <em>not</em> (yet?) provide:
|
|
<ul>
|
|
<li>any mechanism for a client might discover the security policy enforce at its home server,
|
|
or any other server;</li>
|
|
<li>any mechanism for a client to discover the user's clearance,
|
|
or the clearance of associated with any resource; nor</li>
|
|
<li>any administrative mechanism for a client to configure configure policy,
|
|
clearance, and labels of any resource.</li>
|
|
</ul>
|
|
Such mechanisms may be introduced in subsequent documents.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Discovering Feature Support' anchor='disco'>
|
|
<p>If an entity supports the XMPP Security Label protocol, it MUST report that fact
|
|
by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in
|
|
response to a &xep0030; information request. Clients wishing to include a XMPP
|
|
Security Label element in any stanza they generate SHOULD determine if their
|
|
server supports the XMPP Security Label protocol. If their server does not
|
|
support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels
|
|
as the server not supporting this protocol will generally ignore XMPP Security
|
|
Labels as they would any other unrecognized element.</p>
|
|
<p>As each service domain may have different support for security labels, servers
|
|
should advertise and clients should perform appropriate discovery lookups on a
|
|
per service basis.</p>
|
|
<example caption="Service Discovery information request"><![CDATA[
|
|
<iq type='get'
|
|
from='user@example.com/Work'
|
|
to='example.com'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
</iq>
|
|
]]></example>
|
|
<example caption="Service Discovery information response"><![CDATA[
|
|
<iq type='result'
|
|
from='example.com'
|
|
to='user@example.com/Work'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
...
|
|
<feature var='urn:xmpp:sec-label:0'/>
|
|
...
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
<!--
|
|
<p>A server should only include &IDENTITY; elements in the response for services
|
|
the user is cleared to use.</p>
|
|
-->
|
|
</section1>
|
|
|
|
<section1 topic='Protocol' anchor='protocol'>
|
|
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
|
|
includes a security label, zero or more equivalent security labels, and optionally display
|
|
marking data.</p>
|
|
<example caption="Labeled Message"><![CDATA[
|
|
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
|
<body>This content is classified.</body>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
|
>MQYCAQIGASk=</esssecuritylabel>
|
|
</label>
|
|
<equivalentlabel>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
|
>MRACAgEABgIpARMGT3Jhbmdl</esssecuritylabel>
|
|
</equivalentlabel>
|
|
</securityLabel>
|
|
</message>
|
|
]]></example>
|
|
<p>The security label metadata is carried in an &SECURITYLABEL; element.
|
|
The &SECURITYLABEL; element which contains one and only one &LABEL; element,
|
|
zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
|
|
<p>The &LABEL; contains the primary security label. It is commonly issued by the
|
|
sender under the security policy of that they and their home server operating under.
|
|
Each &EQUIVALENTLABEL; holds equivalent security labels under other policies.
|
|
This element might be used when a recepient is known to hold a clearance under a
|
|
different policy than the sender.</p>
|
|
<p>The &LABEL; and &EQUIVALENTLABEL; elements each require a <tt>type=</tt> attribute.
|
|
The <tt>type=</tt> attribute indicates the type and encoding of the element's value.
|
|
The attribute <tt>type=</tt> value '<tt>ESS</tt>' indicates the label is the
|
|
base64, as specified in &rfc4648;, encoding of the &BER; encoding of the &ASN.1;
|
|
<tt>eSSSecurityLabel</tt> type as specified in &rfc2634;.
|
|
Additional types may be registered (see 'XMPP Registrar Considerations').</p>
|
|
<p>The &DISPLAYMARKING; element contains a display string for use by
|
|
implementations which are unable to utilize the applicable security policy
|
|
to generate display markings. The element may optionally contain two
|
|
attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML
|
|
color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for use in
|
|
colorizing the display marking.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Label Information Discovery' anchor='label-disco'>
|
|
<p>It is RECOMMENDED the server publish security label information, including a
|
|
catalog of labels, for use by clients.</p>
|
|
<p>The catalog provided should only contain labels for which the client is allowed to use
|
|
(based upon the user's authorization). The catalog may not be include the complete
|
|
set of labels available for the use by the client.</p>
|
|
<p>As each service domain may have different support for security labels, servers
|
|
should advertise and clients should perform appropriate discovery lookups on a
|
|
per service basis.</p>
|
|
<p>To indicate the support for label information discovery, a server advertises the
|
|
<tt>urn:xmpp:sec-label:info:0</tt> feature.</p>
|
|
<example caption="Label Information Feature Discovery request"><![CDATA[
|
|
<iq type='get'
|
|
from='user@example.com/Work'
|
|
to='example.com'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
|
</iq>
|
|
]]></example>
|
|
<example caption="Label Information Feature Discovery response"><![CDATA[
|
|
<iq type='result'
|
|
from='example.com'
|
|
to='user@example.com/Work'
|
|
id='disco1'>
|
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
|
...
|
|
<feature var='urn:xmpp:sec-label:0'/>
|
|
<feature var='urn:xmpp:sec-label:info:0'/>
|
|
...
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
|
|
<p>The following example illustrates catalog discovery.</p>
|
|
|
|
<!-- Hierarchy of labels? -->
|
|
<example caption="Label Information request"><![CDATA[
|
|
<iq type='get'
|
|
from='user@example.com/Work'
|
|
to='example.com'
|
|
id='catalog1'>
|
|
<query xmlns='urn:xmpp:sec-label:info:0'/>
|
|
</iq>
|
|
]]></example>
|
|
|
|
<example caption="Label Information response"><![CDATA[
|
|
<iq type='result'
|
|
from='example.com'
|
|
to='user@example.com/Work'
|
|
id='catalog1'>
|
|
<query xmlns='urn:xmpp:sec-label:info:0'>
|
|
<labelcatalog>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
|
>MQYCAQQGASk=</esssecuritylabel>
|
|
</label>
|
|
</securityLabel>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='navy'>CONFIDENTIAL</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
|
>MQYCAQMGASk=</esssecuritylabel>
|
|
</label>
|
|
</securityLabel>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
|
>MQYCAQIGASk=</esssecuritylabel>
|
|
</label>
|
|
</securityLabel>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
|
>MQMGASk=</esssecuritylabel>
|
|
</label>
|
|
</securityLabel>
|
|
</labelcatalog>
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
<p>The label information may contain other elements.</p>
|
|
</section1>
|
|
|
|
<section1 topic='Use in XMPP' anchor='xmpp-use'>
|
|
<p>The sensitivity-based access control decisions discussed herein are to be
|
|
made independently of other access control decisions or other facilities.
|
|
That is, the sensitivity-based access control decisions are not conditional
|
|
on other factors.</p>
|
|
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by
|
|
this document, or other formal specifications. Any other use of
|
|
&SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD
|
|
be discarded with, if approrpriate, an error response. Such error responses
|
|
SHOULD NOT include content from the violating stanza, excepting that
|
|
necessary to well-formed error responses.</p>
|
|
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED.
|
|
Absence of a &SECURITYLABEL; element implies the stanza has the default label
|
|
as specified in the governing security policy. Given that the governing
|
|
policy may not specify a default label, hence denying access to the stanza,
|
|
supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p>
|
|
<p>Typically, a client would allow the user to choose populate the
|
|
&SECURITYLABEL; from one of from a small set of security labels selections
|
|
known to it (through configuration and/or discovery and/or other means),
|
|
such as from a pull-down menu. That selection would include appropriate
|
|
values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p>
|
|
<p>A policy-aware client may provide the user with an interface allowing the
|
|
user to produce custom labeling data for inclusion in this set. A
|
|
policy-aware client SHOULD preclude the user from producing &LABEL; values
|
|
which the user's own clearance does not grant access to, and SHOULD preclude
|
|
sending any label which the user's own clearance does not grant access to.
|
|
Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent
|
|
policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the
|
|
display marking prescribed for the &LABEL; under the governing policy, or,
|
|
if the governing policy prescribes no display marking for the &LABEL;,
|
|
absent.</p>
|
|
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
|
|
display the &DISPLAYMARKING; value. A policy-aware may alternatively
|
|
promiently display the marking for the &LABEL; prescribed by the governing
|
|
policy.</p>
|
|
<p>Each server is expected to make a number of sensitivity-based authorization
|
|
decisions. Each decision is made by evaluating an Access Control Decision
|
|
Function (ACDF) with a governing policy, a clearance, and a security label.
|
|
The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p>
|
|
<p>If the user holds a valid clearance (known to the server) under the
|
|
governing policy, the clearance input is the user's clearance. Otherwise,
|
|
if the governing policy provides a default clearance, the clearance input
|
|
is the default clearance. Otherwise, the clearance input is the nil clearance.
|
|
The nil clearance is a clearance for which the ACDF always returns Deny when
|
|
given as the clearance input.</p>
|
|
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL;
|
|
element or one of the &EQUIVALENTLABEL; elements contain an appropriate label,
|
|
that label input is that label. Otherwise, the label input is the default
|
|
label provided the governing policy or, if no default label is provided,
|
|
the nil label. The nil label is a label for which the ACDF always returns
|
|
Deny when given as the label input.</p>
|
|
<p>The term "effective clearance" and "effective label" refer, respectively,
|
|
to the clearance and label provided as input to the ACDF.</p>
|
|
<p>Not all sensitivity-based authorization decisions an XMPP server might make
|
|
involve a user clearance and/or stanza label. A server may only provide
|
|
service to users which hold an appropriate clearance as determined by calling
|
|
the ACDF with the user's clearance and a label associated with the service.
|
|
A clearance might also be associated with the service to restrict the set
|
|
of labels may be used in labeling stanzas. Labels and clearances can also
|
|
be associated with network interfaces, remote servers, chatrooms, pubsub
|
|
notes.</p>
|
|
<section2 topic='Use in Instant Messaging' anchor='im-use'>
|
|
<p>A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.</p>
|
|
<!--
|
|
<p>The server will make, at a minimum, the following accessing control decisions:
|
|
<ul>
|
|
<li>TBD</li>
|
|
</ul>
|
|
</p>
|
|
-->
|
|
</section2>
|
|
<section2 topic='Use in Group Chat and Multi-User Chat' anchor='muc-use'>
|
|
<p>A client may provide a &SECURITYLABEL; element in &MESSAGE; stanzas.</p>
|
|
|
|
<section3 topic='Discovery' anchor='muc-disco'>
|
|
<p>A server SHOULD provide a label feature and information discovery for the room.</p>
|
|
<p>Clients SHOULD discover label feature and information on a per room basis.</p>
|
|
</section3>
|
|
<section3 topic='Sending Messages' anchor='muc-send'>
|
|
<p>Sending groupchat messages is similiar to sending normal messages, however
|
|
their are a few differences.</p>
|
|
<p>Groupchat messages are addressed to the room. The room clearance must
|
|
be suitable for the message label, else it should be rejected.</p>
|
|
<p>The room's clearance may allow a variety of labels to be used. Not all
|
|
partipants may be cleared for all labels allowed in the room. The server
|
|
MUST only deliver messages to partipants for which they are cleared to
|
|
receive.</p>
|
|
</section3>
|
|
<section3 topic='Private Messages' anchor='muc-private'>
|
|
<p>Private messages are treated as discussed in the "Use in Instant Messaging"
|
|
section. (Should private messages be restricted by room's configuration?)</p>
|
|
</section3>
|
|
<section3 topic='Invitations' anchor='muc-invite'>
|
|
<p>Invitations may be labeled.</p>
|
|
</section3>
|
|
<section3 topic='Changing Subject' anchor='muc-subject'>
|
|
<p>This section discusses semantics of &SECURITYLABEL; elements contained
|
|
in &MESSAGE; stanzas containing a &SUBJECT; element.</p>
|
|
<p>The presence of a &SECURITYLABEL; element indicates a request to change
|
|
the room's label, either to the provided label or, if the element is empty,
|
|
to unset the room's label. The server is to refuse the request if the
|
|
requestor is not authorized to change the subject, not cleared for the
|
|
requested label, or if the server is otherwise unwilling or unable to make
|
|
the change. If the label change is refused, so must the accompanied
|
|
subject change. Likewise, if the subject change is refused, so must the
|
|
accompanied label change.</p>
|
|
<p>Upon change of the room's label, the server MUST immediately remove from
|
|
the room all members whom are not cleared for that label.</p>
|
|
<p>In absence of a &SECURITYLABEL; element, the label associated with the
|
|
room is unchanged.</p>
|
|
<p>The room's label can also be changed through room configuration (to be
|
|
discussed in later revision of this document).</p>
|
|
</section3>
|
|
<!--
|
|
<section3 topic='Room Configuration' anchor='muc-config'>
|
|
<p>The server may allow for configuration of security label parameters
|
|
via room configuration mechanisms. The approach is intended to be
|
|
ad-hoc. Hence this section is intended to be illustrative, not
|
|
prescriptive.</p>
|
|
<example caption="Room Configuration Form"><![CDATA[
|
|
<iq from='room@muc.example.com'
|
|
id='create1'
|
|
to='user@example.com/Work'
|
|
type='result'>
|
|
<query xmlns='http://jabber.org/protocol/muc#owner'>
|
|
<x xmlns='jabber:x:data' type='form'>
|
|
<title>"darkcave" room configuration</title>
|
|
...
|
|
<field label='Room Label' type='list-single' var='sec-label#label'>
|
|
<value>Catalog:UNCLASSIFIED</value>
|
|
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
|
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
|
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
|
|
<option label='Custom'><value>Custom</value></option>
|
|
</field>
|
|
<field label='Custom Room Label' type='text-single'
|
|
var='sec-label#custom-label'/>
|
|
<field label='Room Allowed Markings' type='list-multi' var='sec-label#clearance'>
|
|
<value>Catalog:UNCLASSIFIED</value>
|
|
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
|
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
|
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
|
|
<option label='Custom'><value>Custom</value></option>
|
|
</field>
|
|
<field label='Custom Room Clearance' type='text-single'
|
|
var='sec-label#custom-clearance'/>
|
|
<field label='Default Label' type='list-single' var='sec-label#default-label'>
|
|
<value>Catalog:UNCLASSIFIED</value>
|
|
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
|
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
|
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
|
|
<option label='Custom'><value>Custom</value></option>
|
|
</field>
|
|
</x>
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
<p>In the above example, the server allows the room label to be set to one of
|
|
to a subset of labels from the label catalog (see below), using the display
|
|
name for selection, as well as custom label support. For custom label choice
|
|
support, the server offers an appropriate choice (the label= string should
|
|
be selected to avoid confusion with display markings used in label=
|
|
attributes). as well as a field for providing the custom label. Likewise
|
|
for the room clearance. The server also allows configuration of a default
|
|
label for use in handling of unlabeled messages.</p>
|
|
<p>Though offering choices from the label catalog is often desirable,
|
|
a server may only offer custom label and/or clearance support.</p>
|
|
<example caption="Room Configuration Form"><![CDATA[
|
|
<iq from='room@muc.example.com'
|
|
id='create1'
|
|
to='user@example.com/Work'
|
|
type='result'>
|
|
<query xmlns='http://jabber.org/protocol/muc#owner'>
|
|
<x xmlns='jabber:x:data' type='form'>
|
|
<title>"darkcave" room configuration</title>
|
|
...
|
|
<field label='Room Label' type='text-single'
|
|
var='sec-label#custom-label'/>
|
|
<field label='Room Clearance' type='text-single'
|
|
var='sec-label#custom-clearance'/>
|
|
</x>
|
|
</query>
|
|
</iq>
|
|
]]></example>
|
|
</section3>
|
|
-->
|
|
</section2>
|
|
<section2 topic='Use in Presence' anchor='presence-use'>
|
|
<p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server
|
|
SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a
|
|
protocol violation.</p>
|
|
<p>Presence information is subject to sensitivity-base authorization decisions,
|
|
however these decisions are made are made using a label associated with the
|
|
presence resource, such as a chatroom's label.</p>
|
|
</section2>
|
|
<section2 topic='Use in PubSub' anchor='pubsub-use'>
|
|
<section3 topic='Discovery' anchor='pubsub-disco'>
|
|
<p>A server SHOULD provide a label feature and information discovery for each node.</p>
|
|
<p>Clients SHOULD discover label feature and information on a per node basis.</p>
|
|
</section3>
|
|
<section3 topic='Publishing items with Security Labels' anchor='muc-send'>
|
|
<p>Each item may be individually labeled.</p>
|
|
<example caption="Publishing with a Security Label"><![CDATA[
|
|
<iq type='set'
|
|
from='hamlet@denmark.lit/blogbot'
|
|
to='pubsub.shakespeare.lit'
|
|
id='pub1'>
|
|
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
|
<publish node='princely_musings'>
|
|
<item>
|
|
<entry xmlns='http://www.w3.org/2005/Atom'>
|
|
<title>Soliloquy</title>
|
|
<summary>
|
|
To be, or not to be: that is the question:
|
|
Whether 'tis nobler in the mind to suffer
|
|
The slings and arrows of outrageous fortune,
|
|
Or to take arms against a sea of troubles,
|
|
And by opposing end them?
|
|
</summary>
|
|
<link rel='alternate' type='text/html'
|
|
href='http://denmark.lit/2003/12/13/atom03'/>
|
|
<id>tag:denmark.lit,2003:entry-32397</id>
|
|
<published>2003-12-13T18:30:02Z</published>
|
|
<updated>2003-12-13T18:30:02Z</updated>
|
|
</entry>
|
|
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
|
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
|
<label>
|
|
<esssecuritylabel xmlns='urn:xmpp:sec-label: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:0'>MQMGASk=</esssecuritylabel>
|
|
</label>
|
|
</securityLabel>
|
|
</item>
|
|
</items>
|
|
</event>
|
|
</iq>
|
|
]]></example>
|
|
</section3>
|
|
</section2>
|
|
</section1>
|
|
|
|
<!--
|
|
<section1 topic='Implementation Notes' anchor='impl'>
|
|
<p>OPTIONAL.</p>
|
|
</section1>
|
|
-->
|
|
<section1 topic='Security Considerations' anchor='security'>
|
|
<p>This document is all about authorization, a key aspect of security. Hence,
|
|
security considerations are discussed through this document.</p>
|
|
<p>Security labels generally should be securely bound to the object. This may be
|
|
accomplished through use of &xmppe2e; signing, or possibly other signing
|
|
mechanisms.</p>
|
|
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
|
|
to any sensitity-based authorization decisions, and may be forwarded throughout
|
|
the XMPP network. The content of these stanzas should not contain information
|
|
requiring sensitivity-based dissemination controls.</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>This document requires no interaction with &IANA;.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>It is requested the ®ISTRAR; add the extension's namespace and schema to
|
|
appropriate XMPP registries.</p>
|
|
<p>It is requested the Registrar maintain a registry of label types. The
|
|
type string "<tt>ESS</tt>" is reserved for use as described in this document.</p>
|
|
</section1>
|
|
<section1 topic='XML Schemas' anchor='schema'>
|
|
<section2 topic='<securitylabel/> schema' anchor='schema-sl'>
|
|
<p>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='urn:xmpp:sec-label:0'
|
|
xmlns='urn:xmpp:sec-label:0'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:annotation>
|
|
<xs:documentation>
|
|
The protocol documented by this schema is defined in XEP-XXXX:
|
|
http://www.xmpp.org/extensions/xep-XXXX.html
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
|
|
<xs:element name='securitylabel'>
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref='displaymarking' name='displaymarking'/>
|
|
<xs:element ref='label' type='label'/>
|
|
<xs:element ref='equivalentlabel' type='label'
|
|
minOccurs='0' maxOccurs='unbounded'/>
|
|
</xs:sequence>
|
|
<xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:element name='displaymarking' type='xs:string'>
|
|
<xs:attribute name='bgcolor' type='xs:string' use='optional'/>
|
|
<xs:attribute name='fgcolor' type='xs:string' use='optional'/>
|
|
</xs:element>
|
|
|
|
<xs:complexType name='label'/>
|
|
</xs:schema>
|
|
]]></code>
|
|
</p>
|
|
</section2>
|
|
<section2 topic='<esssecuritylabel/> schema' anchor='schema-ess'>
|
|
<p>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='urn:xmpp:sec-label:ess:0'
|
|
xmlns='urn:xmpp:sec-label:ess:0'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:annotation>
|
|
<xs:documentation>
|
|
The protocol documented by this schema is defined in XEP-XXXX:
|
|
http://www.xmpp.org/extensions/xep-XXXX.html
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
|
|
<xs:element name='esssecuritylabel' type=xs:string'/>
|
|
</xs:schema>
|
|
]]></code>
|
|
</p>
|
|
</section2>
|
|
<section2 topic='Label Information schema' anchor='schema-info'>
|
|
<p>
|
|
<code><![CDATA[
|
|
<?xml version='1.0' encoding='UTF-8'?>
|
|
<xs:schema
|
|
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
|
targetNamespace='urn:xmpp:sec-label:info:0'
|
|
xmlns='urn:xmpp:sec-label:info:0'
|
|
elementFormDefault='qualified'>
|
|
|
|
<xs:annotation>
|
|
<xs:documentation>
|
|
The protocol documented by this schema is defined in XEP-XXXX:
|
|
http://www.xmpp.org/extensions/xep-XXXX.html
|
|
</xs:documentation>
|
|
</xs:annotation>
|
|
|
|
<xs:element name='query'>
|
|
<xs:complexType>
|
|
<xs:sequence>
|
|
<xs:element ref='labelcatalog' name='labelcatalog'
|
|
minOccurs='0' maxOccurs='1'/>
|
|
<!-- additional elements here -->
|
|
<xs:sequence>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:element name='labelcatalog'>
|
|
<xs:complexType>
|
|
<xs:element ref='securitylabel' type='securitylabel'
|
|
minOccurs='1' maxOccurs='unbounded'/>
|
|
</xs:complexType>
|
|
</xs:element>
|
|
|
|
<xs:complexType name='securitylabel'/>
|
|
</xs:schema>
|
|
]]></code>
|
|
</p>
|
|
</section2>
|
|
</section1>
|
|
</xep>
|