moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

misc updates

Browse Source
This commit is contained in:
Kurt Zeilenga 2010-11-09 14:29:31 -08:00
parent d20e3d3336
commit 958bdd5bb4
1 changed files with 45 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

91
xep-0258.xml
View File

@ -36,6 +36,12 @@
<email>Kurt.Zeilenga@Isode.COM</email>
<jid>Kurt.Zeilenga@Isode.COM</jid>
</author>
<revision>
<version>0.7</version>
<date>2010-11-09</date>
<initials>kdz</initials>
<remark><p>Illustrate XEP 45 security label room configuration. Make clarifications and m inor editorial changes.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2010-07-30</date>
@ -86,11 +92,11 @@
label is used in conjunction with a clearance, a structured representation of what
information sensitivities a person (or other entity) is authorized to access, and a security
policy to control access to each piece of information. For instance, message could be
labeled as "SECRET", and hence requiring the sender and the receiver to have a
labeled as "SECRET", and hence requiring the sender and the receiver to each have a
clearance granting access to "SECRET" information. &X.841; provides a discussion of
security labels, clearances, and security policy.</p>
<p>Sensitivity-based authorization is used in networks which operate under a set of
information classification rules, such as in government military agency networks. The
information classification rules, such as in government agency networks. The
standardized formats for security labels, clearances, and security policy are
generalized and do have application in non-government networks.</p>
<p>This document describes the use of security labels in &xmpp;. The document specifies
@ -125,7 +131,7 @@
<p>The document details when security label metadata should or should not be provided, and how
this metadata is to be processed.</p>
<p>This document does <em>not</em> provide:
<p>This document does not provide:
<ul>
<li>any mechanism for a client might discover the security policy
enforce at its home server, or any other server;</li>
@ -136,17 +142,20 @@
</ul>
Such mechanisms may be introduced in subsequent documents.</p>
<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>
</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>An entity (client or server) which supports the XMPP Security Label protocol
MUST report that fact by including a service discovery feature of
"<tt>urn:xmpp:sec-label:0</tt>" in response to a &xep0030; information request.</p>
<p>Clients wishing to include a XMPP Security Label element in any stanza they
generate SHOULD determine if their server supports the XMPP Security Label protocol.
If their server does not support XMPP Security Label, the client SHOULD NOT generate
XMPP Security Labels as the server not supporting this protocol will generally
ignore XMPP Security Labels as they would any other unrecognized element.</p>
<p>As each service domain may have different support for security labels, servers
should advertise and clients should perform appropriate discovery lookups on a
per service basis.</p>
@ -170,10 +179,6 @@
</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'>
@ -234,12 +239,12 @@
JID.</p>
<p>It is RECOMMENDED the server publish catalogs of security label
for use by clients.</p>
<p>If catalog is restrictive, as indicated by the restrictive attribute
<p>If catalog is restrictive, as indicated by the restrict attribute
with value of true, the client SHOULD use one of the labels
(or no label) offered by the catalog.</p>
<p>One and only one of the items may have a default attribute with
value of true. The client should default to this item in cases
where the user has not selected an item.</p>
value of true. The client should default the label selection to
this item in cases where the user has not selected an item.</p>
<p>An item may have no label. Such an item offers a choice of
sending a stanza without a label.</p>
<p>Each catalog provided should only contain labels for which the client
@ -258,9 +263,10 @@
<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
<p>Items 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
hierarchical organization of the items. If one item has a selector
attribute, all items should have a selector item. The value of the selector
attribute conforms to the selector-value ABNF production:
<blockquote>
<![CDATA[
@ -277,6 +283,7 @@ selector-value = (<item>"|")*<item>
avoided.</blockquote>
<example caption="Label Catalog Feature Discovery request"><![CDATA[
<iq type='get'
to='example.com'
from='user@example.com/Work'
id='disco1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
@ -298,7 +305,7 @@ selector-value = (<item>"|")*<item>
<p>The following example pair illustrates catalog discovery. Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).</p>
<example caption="Label Catalog request"><![CDATA[
<iq type='get' id='cat1'>
<iq to='example.com' type='get' id='cat1'>
<catalog xmlns='urn:xmpp:sec-label:catalog:2' to='example.com'/>
</iq>
]]></example>
@ -308,7 +315,7 @@ selector-value = (<item>"|")*<item>
<catalog xmlns='urn:xmpp:sec-label:catalog:2'
to='example.com' name='Default'
desc='an example set of labels'
restrictive='false'>
restrict='false'>
<item selector="Classified|SECRET">
<securitylabel xmlns='urn:xmpp:sec-label:0'>
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
@ -327,7 +334,7 @@ selector-value = (<item>"|")*<item>
</label>
</securitylabel>
</item>
<item selector="Classified|RESTRICTED" default="true">
<item selector="Classified|RESTRICTED">
<securitylabel xmlns='urn:xmpp:sec-label:0'>
<displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking>
<label>
@ -336,10 +343,11 @@ selector-value = (<item>"|")*<item>
</label>
</securitylabel>
</item>
<item selector="Unclassified|UNCLASSIFIED"/>
<item selector="UNCLASSIFIED" default="true"/>
</catalog>
</iq>
]]></example>
</section1>
<section1 topic='Use in XMPP' anchor='xmpp-use'>
@ -455,12 +463,12 @@ selector-value = (<item>"|")*<item>
<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>
ad-hoc. Hence this section is intended to be illustrative of one
possible approach. Implementations are free to utilize other
approaches.</p>
<example caption="Room Configuration Form"><![CDATA[
<iq from='room@muc.example.com'
id='create1'
@ -479,6 +487,7 @@ selector-value = (<item>"|")*<item>
</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>
@ -488,13 +497,6 @@ selector-value = (<item>"|")*<item>
</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>
@ -502,13 +504,11 @@ selector-value = (<item>"|")*<item>
<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>
support, the server offers an single text box for entry of an appropriate
text string indicating the label to use. Likewise for the room clearance
and default room clearance.</p>
<p>Though offering choices from the label catalog is often desirable,
a server may only offer custom label and/or clearance support.</p>
a server could only offer custom label and/or clearance support.</p>
<example caption="Room Configuration Form"><![CDATA[
<iq from='room@muc.example.com'
id='create1'
@ -527,7 +527,6 @@ selector-value = (<item>"|")*<item>
</iq>
]]></example>
</section3>
-->
</section2>
<section2 topic='Use in Presence' anchor='presence-use'>
<p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server
@ -630,13 +629,14 @@ And by opposing end them?
<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>
<p>It is desirable to securely bind the security label to the object it labels.
This may be accomplished through use of digital signatures. Specification of such
is left to a future document.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
@ -803,7 +803,6 @@ And by opposing end them?
</xs:annotation>
</xs:attribute>
<xs:attribute name="selector" type="xs:string">
<xs:annotation>
<xs:documentation>User input selector</xs:documentation>
@ -812,7 +811,7 @@ And by opposing end them?
<xs:attribute name="default" type="xs:boolean">
<xs:annotation>
<xs:documentation>Default Item</xs:documentation>
<xs:documentation>default selection</xs:documentation>
</xs:annotation>
</xs:attribute>