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

Minor updates to XEP 274 (XMPP DSIG), namely fix up error examples and to note

Browse Source 
the approach doesn't support 'optimistic signing'.

Extend XEP 258 to use XMPP DSIG to securely bind labels.

Update XEP 274 based on introduction of XEP 258.
This commit is contained in:
Kurt Zeilenga 2010-09-29 08:10:04 -07:00
parent 17207ae196
commit 8b4bfd5723
3 changed files with 572 additions and 480 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

597
xep-0258.xml
View File

@ -12,11 +12,11 @@
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
<header> <header>
<title>Security Labels in XMPP</title> <title>Security Labels in XMPP</title>
<abstract>This document describes the use of security labels in XMPP. The document <abstract>This document describes the use of security labels in XMPP. The document specifies
specifies how security label metadata is carried in XMPP, when this metadata how security label metadata is carried in XMPP, when this metadata should or should not
should or should not be provided, and how the metadata is to be processed.</abstract> 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>
@ -26,79 +26,98 @@
<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>
<p>Add initial support for secure binding of labels (digital signatures).</p>
</remark>
</revision>
<revision> <revision>
<version>0.6</version> <version>0.6</version>
<date>2010-07-30</date> <date>2010-07-30</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Extend catalog handling. Minor editorial changes.</p></remark> <remark>
<p>Extend catalog handling. Minor editorial changes.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.5</version> <version>0.5</version>
<date>2009-07-27</date> <date>2009-07-27</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.</p></remark> <remark>
<p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog
discovery. Clarify syntax of selector= attribute.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.4</version> <version>0.4</version>
<date>2009-07-23</date> <date>2009-07-23</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Update label catalogs to include user input selector.</p></remark> <remark>
<p>Update label catalogs to include user input selector.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.3</version> <version>0.3</version>
<date>2009-03-20</date> <date>2009-03-20</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Add text regarding default bg/fg colors. Correct examples.</p></remark> <remark>
<p>Add text regarding default bg/fg colors. Correct examples.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
<date>2009-03-10</date> <date>2009-03-10</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Reworked discovery and various updates.</p></remark> <remark>
<p>Reworked discovery and various updates.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2009-01-05</date> <date>2009-01-05</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Initial published version.</p></remark> <remark>
<p>Initial published version.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.0.081203</version> <version>0.0.081203</version>
<date>2008-12-03</date> <date>2008-12-03</date>
<initials>kdz</initials> <initials>kdz</initials>
<remark><p>Initial draft.</p></remark> <remark>
<p>Initial draft.</p>
</remark>
</revision> </revision>
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic="Introduction" anchor="intro">
<p>A security label, sometimes referred to as a confidentiality label, is <p>A security label, sometimes referred to as a confidentiality label, is a structured
a structured representation of the sensitivity of a piece of information. A security representation of the sensitivity of a piece of information. A security label is used in
label is used in conjunction with a clearance, a structured representation of what conjunction with a clearance, a structured representation of what information
information sensitivities a person (or other entity) is authorized to access, and a security sensitivities a person (or other entity) is authorized to access, and a security policy
policy to control access to each piece of information. For instance, message could be to control access to each piece of information. For instance, message could be labeled
labeled as "SECRET", and hence requiring the sender and the receiver to have a as "SECRET", and hence requiring the sender and the receiver to have a clearance
clearance granting access to "SECRET" information. &X.841; provides a discussion of granting access to "SECRET" information. &X.841; provides a discussion of security
security labels, clearances, and security policy.</p> labels, clearances, and security policy.</p>
<p>Sensitivity-based authorization is used in networks which operate under a set of <p>Sensitivity-based authorization is used in networks which operate under a set of
information classification rules, such as in government 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 <p>This document describes the use of security labels in &xmpp;. The document specifies how
how security label metadata is carried in XMPP. It standardizes a mechanism for security label metadata is carried in XMPP. It standardizes a mechanism for carrying ESS
carrying ESS Security Labels in XMPP, as well as provides for use of other label Security Labels in XMPP, as well as provides for use of other label formats. ESS
formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in
commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c; conjunction with &X.500; clearances and either X.841 or &SDN.801c; security
security policies.</p> policies.</p>
<example caption="Message with ESS Security Label"><![CDATA[ <example caption="Message with ESS Security Label"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'> <message to='romeo@example.net' from='juliet@example.com/balcony'>
<body>This content is classified.</body> <body>This content is classified.</body>
@ -122,34 +141,64 @@
]]></example> ]]></example>
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p> <p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
<p>The document details when security label metadata should or should not be provided, and how <p>To securely bind the security label to the message, &xep0285; can be used as detailed below.</p>
this metadata is to be processed.</p> <example caption="Message with Securely bound ESS Security Label"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'>
<signed xmlns="urn:xmpp:signed:0">
<signature algorithm="RSA-SHA1">To-be-computed
</signature>
<data>
PG1lc3NhZ2UgdG89J3JvbWVvQGV4YW1wbGUubmV0JyBmcm9tPSdqdWxpZXRAZXhhbXBsZS5jb20v
YmFsY29ueSc+CiAgICA8Ym9keT5UaGlzIGNvbnRlbnQgaXMgY2xhc3NpZmllZC48L2JvZHk+CiAg
ICA8c2VjdXJpdHlsYWJlbCB4bWxucz0ndXJuOnhtcHA6c2VjLWxhYmVsOjAnPgogICAgICAgIDxk
aXNwbGF5bWFya2luZyBmZ2NvbG9yPSdibGFjaycgYmdjb2xvcj0ncmVkJz5TRUNSRVQ8L2Rpc3Bs
YXltYXJraW5nPgogICAgICAgIDxsYWJlbD48aWNpc21sYWJlbCB4bWxucz0naHR0cDovL2V4YW1w
bGUuZ292L0lDLUlTTS8wJyBjbGFzc2lmaWNhdGlvbj0nUycKICAgICAgICAgICAgb3duZXJQcm9k
dWNlcj0nVVNBJy8+PC9sYWJlbD4KICAgIDwvc2VjdXJpdHlsYWJlbD4KPC9tZXNzYWdlPgo=
</data>
</message>
]]>
</example>
<p>The document details when security label metadata should or should not be provided, and
how this metadata is to be processed.</p>
<p>This document does <em>not</em> provide: <p>This document does <em>not</em> provide:
<ul> <ul>
<li>any mechanism for a client might discover the security policy <li>any mechanism for a client might discover the security policy enforce at its
enforce at its home server, or any other server;</li> home server, or any other server;</li>
<li>any mechanism for a client to discover the user's clearance, <li>any mechanism for a client to discover the user's clearance, or the clearance of
or the clearance of associated with any resource; nor</li> associated with any resource; nor</li>
<li>any administrative mechanism for a client to configure <li>any administrative mechanism for a client to configure configure policy,
configure policy, clearance, and labels of any resource.</li> clearance, and labels of any resource.</li>
</ul> </ul>
Such mechanisms may be introduced in subsequent documents.</p> Such mechanisms may be introduced in subsequent documents.</p>
</section1> </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 <p>If an entity supports the XMPP Security Label protocol, it MUST report that fact by
by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in response to
response to a &xep0030; information request. Clients wishing to include a XMPP a &xep0030; information request. Clients wishing to include a XMPP Security Label
Security Label element in any stanza they generate SHOULD determine if their element in any stanza they generate SHOULD determine if their server supports the XMPP
server supports the XMPP Security Label protocol. If their server does not Security Label protocol. If their server does not support XMPP Security Label, the
support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels client SHOULD NOT generate XMPP Security Labels as the server not supporting this
as the server not supporting this protocol will generally ignore XMPP Security protocol will generally ignore XMPP Security Labels as they would any other unrecognized
Labels as they would any other unrecognized element.</p> element.</p>
<p>As each service domain may have different support for security labels, servers <p>If an entity supports secure binding of the XMPP Security Label using &xmppdsig;, it MUST
should advertise and clients should perform appropriate discovery lookups on a report the fact by including a service discover feature of
per service basis.</p> "<tt>urn:xmpp:sec-label:dsig:0</tt>"" in response to a &xep0030; information request.
Clients wishing to include a securely bound XMPP Security Label element in any stanza
they generate SHOULD determine if their server supports the XMPP Security Label
protocol. If their server does not support securely bound XMPP Security Label, the
client SHOULD NOT generate securely bound XMPP Security Labels as the server not
supporting this protocol will generally ignore securely bound XMPP Security Labels as
they would any other unrecognized element. Note that the client here is signing
the stanzas for the benifit of its server. Its server will determine what content,
if any, to forward to other entities. Hence, the sending client need determine whether
any of the intended receipents supports XMPP Digital Signatures.</p>
<p>As each service domain may have different support for security labels, servers should
advertise and clients should perform appropriate discovery lookups on a per service
basis.</p>
<example caption="Service Discovery information request"><![CDATA[ <example caption="Service Discovery information request"><![CDATA[
<iq type='get' <iq type='get'
from='user@example.com/Work' from='user@example.com/Work'
@ -166,20 +215,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 display includes a security label, zero or more equivalent security labels, and optionally
marking data.</p> display marking data.</p>
<example caption="Labeled Message"><![CDATA[ <example caption="Labeled Message"><![CDATA[
<message to='romeo@example.net' from='juliet@example.com/balcony'> <message to='romeo@example.net' from='juliet@example.com/balcony'>
<body>This content is classified.</body> <body>This content is classified.</body>
@ -196,85 +246,69 @@
</securitylabel> </securitylabel>
</message> </message>
]]></example> ]]></example>
<p>The security label metadata is carried in an &SECURITYLABEL; element. <p>The security label metadata is carried in an &SECURITYLABEL; element. The &SECURITYLABEL;
The &SECURITYLABEL; element which contains one and only one &LABEL; element, element which contains one and only one &LABEL; element, zero or more &EQUIVALENTLABEL;
zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p> elements, and an optional &DISPLAYMARKING; element.</p>
<p>The &LABEL; provides the primary security label. It is commonly issued <p>The &LABEL; provides the primary security label. It is commonly issued by the sender
by the sender under the security policy of that they and their home under the security policy of that they and their home server operating under. The
server operating under. The &LABEL; contains either a single element &LABEL; contains either a single element representing the primary security label or is
representing the primary security label or is empty to indicate use of empty to indicate use of a default.</p>
a default.</p> <p>Each &EQUIVALENTLABEL; represents an equivalent security label under other policies. Each
<p>Each &EQUIVALENTLABEL; represents an equivalent security label under &EQUIVALENTLABEL; contains a single element representing the equivalent label. This
other policies. Each &EQUIVALENTLABEL; contains a single element element might be used when a recepient is known to hold a clearance under a different
representing the equivalent label. This element might be used when policy than the sender.</p>
a recepient is known to hold a clearance under a different policy <p>The &DISPLAYMARKING; element contains a display string for use by implementations which
than the sender.</p> are unable to utilize the applicable security policy to generate display markings. The
<p>The &DISPLAYMARKING; element contains a display string for use by element may optionally contain two attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>,
implementations which are unable to utilize the applicable security policy whose values are HTML color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for
to generate display markings. The element may optionally contain two use in colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>.
attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML The <tt>bgcolor=</tt> default is <tt>white</tt>. </p>
color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for use in </section1>
colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>.
The <tt>bgcolor=</tt> default is <tt>white</tt>.
</p>
</section1>
<section1 topic='Label Catalog Discovery' anchor='label-catalog'> <section1 topic="Label Catalog Discovery" anchor="label-catalog">
<p>A client can request a catalog for a particular JID by sending <p>A client can request a catalog for a particular JID by sending a catalog discovery
a catalog discovery request to the client's server. Where the JID request to the client's server. Where the JID is hosted by some other server, the
is hosted by some other server, the client's server is expected to client's server is expected to produce a suitable catalog (or fail the request). The
produce a suitable catalog (or fail the request). The client's server client's server may, as needed, query catalogs from other servers in order to fulfill
may, as needed, query catalogs from other servers in order to the client's request.</p>
fulfill the client's request.</p> <p>While this specification does not preclude a client from directing a catalog request
<p>While this specification does not preclude a client from directing elsewhere, it is noted that catalog returned by a party other than its server may not be
a catalog request elsewhere, it is noted that catalog returned by directly useable by the client. For instance, the client's server might require a
a party other than its server may not be directly useable by the particular only-locally-known label be used in messages to a particular remote JID.</p>
client. For instance, the client's server might require a particular <p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p>
only-locally-known label be used in messages to a particular remote <p>If catalog is restrictive, as indicated by the restrictive attribute with value of true,
JID.</p> the client SHOULD use one of the labels (or no label) offered by the catalog.</p>
<p>It is RECOMMENDED the server publish catalogs of security label <p>One and only one of the items may have a default attribute with value of true. The client
for use by clients.</p> should default to this item in cases where the user has not selected an item.</p>
<p>If catalog is restrictive, as indicated by the restrictive attribute <p>An item may have no label. Such an item offers a choice of sending a stanza without a
with value of true, the client SHOULD use one of the labels label.</p>
(or no label) offered by the catalog.</p> <p>Each catalog provided should only contain labels for which the client is allowed to use
<p>One and only one of the items may have a default attribute with (based upon the user's authorization) in a particular context (such as in chatroom). A
value of true. The client should default to this item in cases catalog may not be include the complete set of labels available for the use by the
where the user has not selected an item.</p> client in the context.</p>
<p>An item may have no label. Such an item offers a choice of <blockquote>Note: the single catalog per context approach used here is likely inadequate in
sending a stanza without a label.</p> enviroments where there are a large number of labels in use. It is expected that a more
<p>Each catalog provided should only contain labels for which the client sophisticated approach will be introduced in a subsequent revision of this
is allowed to use (based upon the user's authorization) in a particular
context (such as in chatroom). A catalog may not be include the
complete set of labels available for the use by the client in the
context.</p>
<blockquote>Note: the single catalog per context approach used here
is likely inadequate in enviroments where there are a large number
of labels in use. It is expected that a more sophisticated approach
will be introduced in a subsequent revision of this
specification.</blockquote> specification.</blockquote>
<p>As each service domain may have different support for security labels, <p>As each service domain may have different support for security labels, servers should
servers should advertise and clients should perform appropriate advertise and clients should perform appropriate discovery lookups on a per service
discovery lookups on a per service basis.</p> basis.</p>
<p>To indicate the support for label catalog discovery, a server <p>To indicate the support for label catalog discovery, a server advertises the
advertises the <tt>urn:xmpp:sec-label:catalog:2</tt> feature. <tt>urn:xmpp:sec-label:catalog:2</tt> feature. The following pair of examples
The following pair of examples illustrates this feature discovery.</p> illustrates this feature discovery.</p>
<p>Each item in the catalog may contain a selector attribute. The <p>Each item in the catalog may contain a selector attribute. The value of this attribute
value of this attribute represents the item's placement in a represents the item's placement in a hierarchical organization of the items. The value
hierarchical organization of the items. The value of the selector of the selector attribute conforms to the selector-value ABNF production: <blockquote>
attribute conforms to the selector-value ABNF production: <![CDATA[
<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 <p>A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X"
the "Y" subset of the "X" subset of items. This information may subset of items. This information may be used, for instance, in generating label
be used, for instance, in generating label selection menus in selection menus in graphical user interfaces.</p>
graphical user interfaces.</p> <blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
<blockquote>Note: use of unnecessarily deep hierarchies should be
avoided.</blockquote>
<example caption="Label Catalog Feature Discovery request"><![CDATA[ <example caption="Label Catalog Feature Discovery request"><![CDATA[
<iq type='get' <iq type='get'
from='user@example.com/Work' from='user@example.com/Work'
@ -295,7 +329,9 @@ selector-value = (<item>"|")*<item>
</iq> </iq>
]]></example> ]]></example>
<p>The following example pair illustrates catalog discovery. Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).</p> <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[ <example caption="Label Catalog request"><![CDATA[
<iq type='get' id='cat1'> <iq type='get' id='cat1'>
@ -340,72 +376,64 @@ 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 <p>The sensitivity-based access control decisions discussed herein are to be made
made independently of other access control decisions or other facilities. independently of other access control decisions or other facilities. That is, the
That is, the sensitivity-based access control decisions are not conditional sensitivity-based access control decisions are not conditional on other factors.</p>
on other factors.</p> <p>It is intended that &SECURITYLABEL; elements are only used as prescribed by this
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by document, or other formal specifications. Any other use of &SECURITYLABEL; SHOULD be
this document, or other formal specifications. Any other use of viewed as a protocol violation. The stanza SHOULD be discarded with, if approrpriate, an
&SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD error response. Such error responses SHOULD NOT include content from the violating
be discarded with, if approrpriate, an error response. Such error responses stanza, excepting that necessary to well-formed error responses.</p>
SHOULD NOT include content from the violating stanza, excepting that <p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. Absence of
necessary to well-formed error responses.</p> a &SECURITYLABEL; element implies the stanza has the default label as specified in the
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. governing security policy. Given that the governing policy may not specify a default
Absence of a &SECURITYLABEL; element implies the stanza has the default label label, hence denying access to the stanza, supporting clients SHOULD provide a
as specified in the governing security policy. Given that the governing &SECURITYLABEL; element where prescribed.</p>
policy may not specify a default label, hence denying access to the stanza, <p>Typically, a client would allow the user to choose populate the &SECURITYLABEL; from one
supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p> of from a small set of security labels selections known to it (through configuration
<p>Typically, a client would allow the user to choose populate the and/or discovery and/or other means), such as from a pull-down menu. That selection
&SECURITYLABEL; from one of from a small set of security labels selections would include appropriate values for the &LABEL;, &DISPLAYMARKING;, and
known to it (through configuration and/or discovery and/or other means), &EQUIVALENTLABEL; elements.</p>
such as from a pull-down menu. That selection would include appropriate <p>A policy-aware client may provide the user with an interface allowing the user to produce
values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p> custom labeling data for inclusion in this set. A policy-aware client SHOULD preclude
<p>A policy-aware client may provide the user with an interface allowing the the user from producing &LABEL; values which the user's own clearance does not grant
user to produce custom labeling data for inclusion in this set. A access to, and SHOULD preclude sending any label which the user's own clearance does not
policy-aware client SHOULD preclude the user from producing &LABEL; values grant access to. Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an
which the user's own clearance does not grant access to, and SHOULD preclude equivalent policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the display
sending any label which the user's own clearance does not grant access to. marking prescribed for the &LABEL; under the governing policy, or, if the governing
Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent policy prescribes no display marking for the &LABEL;, absent.</p>
policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the <p>A client which receives a stanza with &SECURITYLABEL; element is to promiently display
display marking prescribed for the &LABEL; under the governing policy, or, the &DISPLAYMARKING; value. A policy-aware may alternatively promiently display the
if the governing policy prescribes no display marking for the &LABEL;, marking for the &LABEL; prescribed by the governing policy.</p>
absent.</p> <p>Each server is expected to make a number of sensitivity-based authorization decisions.
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently Each decision is made by evaluating an Access Control Decision Function (ACDF) with a
display the &DISPLAYMARKING; value. A policy-aware may alternatively governing policy, a clearance, and a security label. The ACDF yields either
promiently display the marking for the &LABEL; prescribed by the governing <em>Grant</em> or <em>Deny</em>.</p>
policy.</p> <p>If the user holds a valid clearance (known to the server) under the governing policy, the
<p>Each server is expected to make a number of sensitivity-based authorization clearance input is the user's clearance. Otherwise, if the governing policy provides a
decisions. Each decision is made by evaluating an Access Control Decision default clearance, the clearance input is the default clearance. Otherwise, the
Function (ACDF) with a governing policy, a clearance, and a security label. clearance input is the nil clearance. The nil clearance is a clearance for which the
The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p> ACDF always returns Deny when given as the clearance input.</p>
<p>If the user holds a valid clearance (known to the server) under the <p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; element or
governing policy, the clearance input is the user's clearance. Otherwise, one of the &EQUIVALENTLABEL; elements contain an appropriate label, that label input is
if the governing policy provides a default clearance, the clearance input that label. Otherwise, the label input is the default label provided the governing
is the default clearance. Otherwise, the clearance input is the nil clearance. policy or, if no default label is provided, the nil label. The nil label is a label for
The nil clearance is a clearance for which the ACDF always returns Deny when which the ACDF always returns Deny when given as the label input.</p>
given as the clearance input.</p> <p>The term "effective clearance" and "effective label" refer, respectively, to the
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; clearance and label provided as input to the ACDF.</p>
element or one of the &EQUIVALENTLABEL; elements contain an appropriate label, <p>Not all sensitivity-based authorization decisions an XMPP server might make involve a
that label input is that label. Otherwise, the label input is the default user clearance and/or stanza label. A server may only provide service to users which
label provided the governing policy or, if no default label is provided, hold an appropriate clearance as determined by calling the ACDF with the user's
the nil label. The nil label is a label for which the ACDF always returns clearance and a label associated with the service. A clearance might also be associated
Deny when given as the label input.</p> with the service to restrict the set of labels may be used in labeling stanzas. Labels
<p>The term "effective clearance" and "effective label" refer, respectively, and clearances can also be associated with network interfaces, remote servers,
to the clearance and label provided as input to the ACDF.</p> chatrooms, pubsub notes.</p>
<p>Not all sensitivity-based authorization decisions an XMPP server might make <section2 topic="Use in Instant Messaging" anchor="im-use">
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>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>
@ -413,49 +441,48 @@ selector-value = (<item>"|")*<item>
</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 room.</p> <p>A server SHOULD provide a label feature and information discovery for the
room.</p>
<p>Clients SHOULD discover label feature and information on a per room basis.</p> <p>Clients SHOULD discover label feature and information on a per room basis.</p>
</section3> </section3>
<section3 topic='Sending Messages' anchor='muc-send'> <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 <p>This section discusses semantics of &SECURITYLABEL; elements contained in
in &MESSAGE; stanzas containing a &SUBJECT; element.</p> &MESSAGE; stanzas containing a &SUBJECT; element.</p>
<p>The presence of a &SECURITYLABEL; element indicates a request to change <p>The presence of a &SECURITYLABEL; element indicates a request to change the
the room's label, either to the provided label or, if the element is empty, room's label, either to the provided label or, if the element is empty, to unset
to unset the room's label. The server is to refuse the request if the the room's label. The server is to refuse the request if the requestor is not
requestor is not authorized to change the subject, not cleared for the authorized to change the subject, not cleared for the requested label, or if the
requested label, or if the server is otherwise unwilling or unable to make server is otherwise unwilling or unable to make the change. If the label change
the change. If the label change is refused, so must the accompanied is refused, so must the accompanied subject change. Likewise, if the subject
subject change. Likewise, if the subject change is refused, so must the change is refused, so must the accompanied label change.</p>
accompanied label change.</p> <p>Upon change of the room's label, the server MUST immediately remove from the room
<p>Upon change of the room's label, the server MUST immediately remove from all members whom are not cleared for that label.</p>
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
<p>In absence of a &SECURITYLABEL; element, the label associated with the unchanged.</p>
room is unchanged.</p> <p>The room's label can also be changed through room configuration (to be discussed
<p>The room's label can also be changed through room configuration (to be in later revision of this document).</p>
discussed in later revision of this document).</p>
</section3> </section3>
<!-- <!--
<section3 topic='Room Configuration' anchor='muc-config'> <section3 topic='Room Configuration' anchor='muc-config'>
<p>The server may allow for configuration of security label parameters <p>The server may allow for configuration of security label parameters
via room configuration mechanisms. The approach is intended to be via room configuration mechanisms. The approach is intended to be
@ -529,20 +556,20 @@ selector-value = (<item>"|")*<item>
</section3> </section3>
--> -->
</section2> </section2>
<section2 topic='Use in Presence' anchor='presence-use'> <section2 topic="Use in Presence" anchor="presence-use">
<p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server <p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server SHALL treat
SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a any &PRESENCE; stanza that contains a &SECURITYLABEL; as a protocol violation.</p>
protocol violation.</p> <p>Presence information is subject to sensitivity-base authorization decisions, however
<p>Presence information is subject to sensitivity-base authorization decisions, these decisions are made are made using a label associated with the presence
however these decisions are made are made using a label associated with the resource, such as a chatroom's label.</p>
presence resource, such as a chatroom's label.</p>
</section2> </section2>
<section2 topic='Use in PubSub' anchor='pubsub-use'> <section2 topic="Use in PubSub" anchor="pubsub-use">
<section3 topic='Discovery' anchor='pubsub-disco'> <section3 topic="Discovery" anchor="pubsub-disco">
<p>A server SHOULD provide a label feature and information discovery for each 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'
@ -612,41 +639,38 @@ And by opposing end them?
]]></example> ]]></example>
</section3> </section3>
</section2> </section2>
</section1> </section1>
<section1 topic='Extension Considerations' anchor='exts'> <section1 topic="Extension Considerations" anchor="exts">
<p> <p> This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
elements are designed to hold a range of security labels formats. XML namespaces SHOULD elements are designed to hold a range of security labels formats. XML namespaces SHOULD
be used to avoid name clashes. be used to avoid name clashes. </p>
</p> </section1>
</section1>
<!-- <!--
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<p>OPTIONAL.</p> <p>OPTIONAL.</p>
</section1> </section1>
--> -->
<section1 topic='Security Considerations' anchor='security'> <section1 topic="Security Considerations" anchor="security">
<p>This document is all about authorization, a key aspect of security. Hence, <p>This document is all about authorization, a key aspect of security. Hence, security
security considerations are discussed through this document.</p> considerations are discussed through this document.</p>
<p>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 &xmppe2e; signing, or possibly other signing accomplished through use of &xmppdsig; as discussed in Appendix A.</p>
mechanisms.</p> <p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject to any
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject sensitity-based authorization decisions, and may be forwarded throughout the XMPP
to any sensitity-based authorization decisions, and may be forwarded throughout network. The content of these stanzas should not contain information requiring
the XMPP network. The content of these stanzas should not contain information sensitivity-based dissemination controls.</p>
requiring sensitivity-based dissemination controls.</p> </section1>
</section1> <section1 topic="IANA Considerations" anchor="iana">
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p> <p>This document requires no interaction with &IANA;.</p>
</section1> </section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'> <section1 topic="XMPP Registrar Considerations" anchor="registrar">
<p>It is requested the &REGISTRAR; add the extension's namespaces <p>It is requested the &REGISTRAR; add the extension's namespaces and schemas to appropriate
and schemas to appropriate XMPP registries.</p> XMPP registries.</p>
</section1> </section1>
<section1 topic='XML Schemas' anchor='schema'> <section1 topic="XML Schemas" anchor="schema">
<section2 topic='Extension Schema' anchor='schema-sl'> <section2 topic="Extension Schema" anchor="schema-sl">
<p> <p>
<code><![CDATA[ <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
@ -745,14 +769,11 @@ And by opposing end them?
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code> A copy of this schema is available at <link
url="http://www.xmpp.org/schemas/sec-label.xsd">
A copy of this schema is available at http://www.xmpp.org/schemas/sec-label.xsd</link>. </p>
<link url='http://www.xmpp.org/schemas/sec-label.xsd'> </section2>
http://www.xmpp.org/schemas/sec-label.xsd</link>. <section2 topic="&lt;catalog/&gt; schema" anchor="schema-catalog">
</p>
</section2>
<section2 topic='&lt;catalog/&gt; schema' anchor='schema-catalog'>
<p> <p>
<code><![CDATA[ <code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
@ -842,14 +863,11 @@ And by opposing end them?
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code> A copy of this schema is available at <link
url="http://www.xmpp.org/schemas/sec-label-catalog.xsd">
A copy of this schema is available at http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
<link url='http://www.xmpp.org/schemas/sec-label-catalog.xsd'> </section2>
http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. <section2 topic="&lt;esssecuritylabel/&gt; schema" anchor="schema-ess">
</p>
</section2>
<section2 topic='&lt;esssecuritylabel/&gt; schema' anchor='schema-ess'>
<p> <p>
<code><![CDATA[ <code><![CDATA[
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
@ -867,12 +885,9 @@ And by opposing end them?
</xs:annotation> </xs:annotation>
</xs:element> </xs:element>
</xs:schema> </xs:schema>
]]></code> ]]></code> A copy of this schema is available at <link
url="http://www.xmpp.org/schemas/sec-label-ess.xsd">
A copy of this schema is available at http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
<link url='http://www.xmpp.org/schemas/sec-label-ess.xsd'> </section2>
http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </section1>
</p>
</section2>
</section1>
</xep> </xep>

215
xep-0274.xml
View File

@ -14,7 +14,7 @@
<!ENTITY CDCIE-CCP "<span class='ref'>CDCIE-CCP</span> <note>Cross Domain Collaborative Information Environment (CDCIE) Chat Client Protocol Specification, Version 2.0, Trident Systems, Inc., 12 March 2008</note>" > <!ENTITY CDCIE-CCP "<span class='ref'>CDCIE-CCP</span> <note>Cross Domain Collaborative Information Environment (CDCIE) Chat Client Protocol Specification, Version 2.0, Trident Systems, Inc., 12 March 2008</note>" >
<!ENTITY XMLDSIG "<span class='ref'><link url='http://www.w3.org/TR/xmldsig-core/'>XMLDSIG</link></span> <note>XML Signature Syntax and Processing, W3C Recommendation, 10 June 2008 &lt;<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>&gt;.</note>" > <!ENTITY XMLDSIG "<span class='ref'><link url='http://www.w3.org/TR/xmldsig-core/'>XMLDSIG</link></span> <note>XML Signature Syntax and Processing, W3C Recommendation, 10 June 2008 &lt;<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>&gt;.</note>" >
<!ENTITY XPointer "<span class='ref'><link url='http://www.w3.org/TR/xptr'>XPointer</link></span> <note>XML Pointer Language (XPointer), W3C Recommendation, 8 June 2001 &lt;<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>&gt;.</note>" > <!ENTITY XPointer "<span class='ref'><link url='http://www.w3.org/TR/xptr'>XPointer</link></span> <note>XML Pointer Language (XPointer), W3C Recommendation, 8 June 2001 &lt;<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>&gt;.</note>" >
%ents; <!ENTITY xmppdsig "<span class='ref'><link url='http://xmpp.org/extensions/inbox/dsig.html'>XMPP DSIG</link></span> <note>XMPP Digital Signatures &lt;<link url='http://xmpp.org/extensions/inbox/dsig.html'>http://xmpp.org/extensions/inbox/dsig.html</link>&gt;.</note>" >%ents;
]> ]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
@ -22,9 +22,7 @@
<title>Design Considerations for Digital Signatures in XMPP</title> <title>Design Considerations for Digital Signatures in XMPP</title>
<abstract>This document discusses considerations for the design of Digital Signatures in XMPP, <abstract>This document discusses considerations for the design of Digital Signatures in XMPP,
including use cases and requirements. The document also discusses various ways XML Digital including use cases and requirements. The document also discusses various ways XML Digital
Signatures could be used in XMPP.</abstract> Signatures could be used in XMPP.</abstract> &LEGALNOTICE; <number>0274</number>
&LEGALNOTICE;
<number>0274</number>
<status>Experimental</status> <status>Experimental</status>
<type>Informational</type> <type>Informational</type>
<sig>Standards</sig> <sig>Standards</sig>
@ -37,11 +35,21 @@
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>
&kdz; &kdz;
<revision>
<version>0.2</version>
<date>2010-09-29</date>
<initials>kdz</initials>
<remark>
<p>Update discussions based upon introduction of Digital Signatures in XMPP.</p>
</remark>
</revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2009-09-15</date> <date>2009-09-15</date>
<initials>psa</initials> <initials>psa</initials>
<remark><p>Initial published version as accepted for publication by the XMPP Council.</p></remark> <remark>
<p>Initial published version as accepted for publication by the XMPP Council.</p>
</remark>
</revision> </revision>
<revision> <revision>
<version>0.0.1</version> <version>0.0.1</version>
@ -162,10 +170,10 @@
<section2 topic="Use in presence stanzas" anchor="presence-use"> <section2 topic="Use in presence stanzas" anchor="presence-use">
<p>The presence can be viewed as a specialized "publish-subscribe" mechanism. Commonly the <p>The presence can be viewed as a specialized "publish-subscribe" mechanism. Commonly the
publishing entity sends a &PRESENCE; stanza to a presence service and the presence publishing entity sends a &PRESENCE; stanza to a presence service and the presence service
service than forwards the stanza to each subscriber. In basic user presence, the publishing than forwards the stanza to each subscriber. In basic user presence, the publishing entity
entity is the user's client and the presence service is presence service is the provided by is the user's client and the presence service is presence service is the provided by this
this client's server. In this case, the 'to' address is empty.</p> client's server. In this case, the 'to' address is empty.</p>
<p>The publisher may wish to sign the signature for the benefit of each subscriber. Each <p>The publisher may wish to sign the signature for the benefit of each subscriber. Each
subscriber could use this signature to authenticate the publisher and to ensure integrity of subscriber could use this signature to authenticate the publisher and to ensure integrity of
publisher provided information.</p> publisher provided information.</p>
@ -179,8 +187,9 @@
</section2> </section2>
</section1> </section1>
<section1 topic="Requirements" anchor="requires"> <section1 topic="General Requirements" anchor="requires">
<p>For the purposes of this memo, the following requirements are stipulated: </p> <p>For the purposes of this memo, the following requirements are stipulated for a general
solution: </p>
<ol start="1"> <ol start="1">
<li>The extension shall support client signing of stanzas.</li> <li>The extension shall support client signing of stanzas.</li>
<li>The extension shall support service (e.g., multi-user chat service) signing of <li>The extension shall support service (e.g., multi-user chat service) signing of
@ -209,16 +218,24 @@
vCard.</li> vCard.</li>
<li>The extension should be designed such that the successful verification of a signature is <li>The extension should be designed such that the successful verification of a signature is
independent of the extension support in entities involved in the exchange.</li> independent of the extension support in entities involved in the exchange.</li>
<li>The extension should be compatible with object encryption, supporting encryption of signed
content, signing of encrypted content, and signing of encrypted signed content (e.g., triple
wrap content).</li>
</ol> </ol>
<p>Some of above requirements may well be, if not outright mutually exclusive, in opposition to
each other. It is suspected that set of reasonable solutions meeting all of the above
requirements may be empty. To produce a reasonable solution, it is expected that some of the
above requirements be eliminated and hence limiting the solution to some subset of the
applications of digital signatures in XMPP.</p>
</section1> </section1>
<section1 topic="Existing Solutions" anchor="existing"> <section1 topic="Existing Solutions" anchor="existing">
<section2 topic="XMPP E2E" anchor="xmpp-e2e"> <section2 topic="XMPP E2E" anchor="xmpp-e2e">
<p>The &IETF; standardized a signing and encryption facility for XMPP known as <p>The &IETF; standardized a signing and encryption facility for XMPP known as &xmppe2e;. XMPP
&xmppe2e;. XMPP E2E is based upon Secure/Multipurpose Internet Message Extensions E2E is based upon Secure/Multipurpose Internet Message Extensions (&SMIME;) and the
(&SMIME;) and the Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP E2E is intended to be an
E2E is intended to be an end-to-end solution. That is, it enables a sender to sign content end-to-end solution. That is, it enables a sender to sign content sent to a specific
sent to a specific recipient.</p> recipient.</p>
<p>An advantage of the XMPP E2E approach is that it uses an encapsulating signature which <p>An advantage of the XMPP E2E approach is that it uses an encapsulating signature which
protects the signed content from alteration as it is exchanged over an XMPP network. A protects the signed content from alteration as it is exchanged over an XMPP network. A
disadvantage is that implementations which do not support XMPP E2E cannot make use of the disadvantage is that implementations which do not support XMPP E2E cannot make use of the
@ -226,6 +243,15 @@
<p>At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to <p>At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to
have limited applicability. </p> have limited applicability. </p>
</section2> </section2>
<section2 topic="XMPP DSIG" anchor="xmpp-dsig">
<p>The &xep0285; (XMPP DSIG), like the XMPP E2E, uses an encapsulating
signature to protects the signed content from alteration as it is exchanged over an XMPP
network. XMPP DSIG avoids certain dependencies which are believed to have hindered
implementation of XMPP E2E. It is hoped that the XMPP DSIG will prove to be more viable
solution than XMPP E2E. Like XMPP E2E, XMPP DSIG does not support <em>optimistic signing</em>.</p>
<p>At the time of this writing, XMPP DSIG was just introduced.</p>
<p/>
</section2>
<section2 topic="CDCIE-CCP" anchor="cdcie-ccp"> <section2 topic="CDCIE-CCP" anchor="cdcie-ccp">
<p>Alternative approaches have been developed. For instance, the Cross Domain Collaborative <p>Alternative approaches have been developed. For instance, the Cross Domain Collaborative
Information Environment (&CDCIE;) Client Chat Protocol (&CDCIE-CCP;), an XMPP-based Information Environment (&CDCIE;) Client Chat Protocol (&CDCIE-CCP;), an XMPP-based
@ -245,8 +271,8 @@
<section2 topic="Encapsulated v. Encapsulating Signatures" anchor="encap"> <section2 topic="Encapsulated v. Encapsulating Signatures" anchor="encap">
<p>An encapsulating signature is a signature approach that encapsulates the signed content <p>An encapsulating signature is a signature approach that encapsulates the signed content
within the signature syntax. An encapsulated signature is a signature approach where the within the signature syntax. An encapsulated signature is a signature approach where the
signature syntax in encapsulated within the structure of the signed content. XMPP E2E is an signature syntax in encapsulated within the structure of the signed content. XMPP E2E and
example of the former. CDCIE-CCP is an example of the latter.</p> XMPP DSIG are examples of the former. CDCIE-CCP is an example of the latter.</p>
<p>The following example illustrates, using pseudo language, an encapsulating signature over a <p>The following example illustrates, using pseudo language, an encapsulating signature over a
&MESSAGE; stanza.</p> &MESSAGE; stanza.</p>
@ -285,13 +311,13 @@
</encapsulated-signature> </encapsulated-signature>
</message> </message>
]]></example> ]]></example>
<p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E, are <p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and
generally limited to end-to-end use cases. That is, cases where the originator of a stanza XMPP DSIG, are generally limited to end-to-end use cases. That is, cases where the
signs the stanza and send it through the XMPP network to its intended recipient, and only originator of a stanza signs the stanza and send it through the XMPP network to its intended
the intended recipient is expected to make use of the signed content. Entities between the recipient, and only the intended recipient is expected to make use of the signed content.
signer and the intended recipient are expected to forward of the stanza without regard to Entities between the signer and the intended recipient are expected to forward of the stanza
the encapsulating signature, and without themselves signing the stanza. The approach does without regard to the encapsulating signature, and without themselves signing the stanza.
not require forwarding entities to support the signing extension.</p> The approach does not require forwarding entities to support the signing extension.</p>
<p>Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For <p>Simple encapsulating signatures have limited applicability in MUC and PubSub use cases. For
instance, an occupant can sign its submissions to the service for the benefit of the service instance, an occupant can sign its submissions to the service for the benefit of the service
and the service can sign reflected stanzas to occupants. In providing non-anonymous chat and the service can sign reflected stanzas to occupants. In providing non-anonymous chat
@ -382,32 +408,32 @@
</message> </message>
]]></example> ]]></example>
<p>The example.com server is required, per &rfc3920;, to add a 'from' attribute to the <p>The example.com server is required, per &rfc3920;, to add a 'from' attribute to the
&MESSAGE; element before forwarding it to the example.net server. The example.net server &MESSAGE; element before forwarding it to the example.net server. The example.net server is
is required to replace the 'to' attribute with the full JID of the romeo@example.net client required to replace the 'to' attribute with the full JID of the romeo@example.net client it
it intends to forward the message to. These alternatations will "break" the signature.</p> intends to forward the message to. These alternatations will "break" the signature.</p>
<p>XMLDSIG provides for a facility to selective sign XML content. For instance, the client <p>XMLDSIG provides for a facility to selective sign XML content. For instance, the client
could sign the &SUBJECT; and &BODY; element and their content. However, this by could sign the &SUBJECT; and &BODY; element and their content. However, this by itself would
itself would not cover key aspects of the stanza, such that it was a chat &MESSAGE; not cover key aspects of the stanza, such that it was a chat &MESSAGE; addressed to a
addressed to a particular JID and sent from a particular JID. XMLDSIG allows for enveloping particular JID and sent from a particular JID. XMLDSIG allows for enveloping signatures,
signatures, that is a signature that signs a data object contained within the that is a signature that signs a data object contained within the &SIGNATURE; element. The
&SIGNATURE; element. The solution could define an element, such as &XMPPprop; used solution could define an element, such as &XMPPprop; used below, for including properties of
below, for including properties of the stanza in the signature. </p> the stanza in the signature. </p>
</section2> </section2>
<section2 topic="Replay attack protection" anchor="replay"> <section2 topic="Replay attack protection" anchor="replay">
<p>The signature in Example 1 does not provide any protection against replay attack. To <p>The signature in Example 1 does not provide any protection against replay attack. To
address replay attack, as well as other concerns, XMLDSIG defines the address replay attack, as well as other concerns, XMLDSIG defines the &SIGNATUREPROPERTIES;
&SIGNATUREPROPERTIES; element for including information items about the generation of element for including information items about the generation of the Signature, such as the
the Signature, such as the date/time the signature was generated. </p> date/time the signature was generated. </p>
</section2> </section2>
<section2 topic="Manifest Signing" anchor="manifest"> <section2 topic="Manifest Signing" anchor="manifest">
<p>While one could have &SIGNATURE; which included a &REFERENCE; element for each of <p>While one could have &SIGNATURE; which included a &REFERENCE; element for each of four
four elements discussed above within its &SIGNEDINFO; element, this would require elements discussed above within its &SIGNEDINFO; element, this would require reference
reference validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater flexibility over
flexibility over handling of absent references and broken digest values, a &MANIFEST; handling of absent references and broken digest values, a &MANIFEST; can be constructed and
can be constructed and only it signed.</p> only it signed.</p>
<p>Putting all of the above together, the client might send the following signed stanza:</p> <p>Putting all of the above together, the client might send the following signed stanza:</p>
@ -459,14 +485,15 @@
<p>Use of an extension attribute to identify elements may be problematic. In particular, the <p>Use of an extension attribute to identify elements may be problematic. In particular, the
XMPP specifications provide no assurance that this attribute would be forwarded with XMPP specifications provide no assurance that this attribute would be forwarded with
element. While one could identify signed content by other means, such as &XPointer;, element. While one could identify signed content by other means, such as &XPointer;, these
these means would not unambiguously identify the signed content in the face of subsequent means would not unambiguously identify the signed content in the face of subsequent stanza
stanza modification. </p> modification. </p>
<p>The an 'id' attribute is could be used (or possibly 'xml:id'), it may be appropriate for <p>The an 'id' attribute is could be used (or possibly 'xml:id'), it may be appropriate for
the XMPP entity inserting a child element into a stanza to provide an 'xml:id' attribute the XMPP entity inserting a child element into a stanza to provide an 'xml:id' attribute
regardless of what stanza content it might sign.</p> regardless of what stanza content it might sign.</p>
</section2> </section2>
<section2 topic="Multiple Signatures" anchor="multisig"> <section2 topic="Multiple Signatures" anchor="multisig">
<p>Multiple entities can sign a stanza. A single entity may sign a stanza multiple times, <p>Multiple entities can sign a stanza. A single entity may sign a stanza multiple times,
typically on different occasions.</p> typically on different occasions.</p>
@ -474,17 +501,35 @@
<p>Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last <p>Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last
element. A &SIGNATURE; may sign other signatures, or portions thereof.</p> element. A &SIGNATURE; may sign other signatures, or portions thereof.</p>
<p>While a simple chat &MESSAGE; typically transits through only one or two XMPP servers <p>While a simple chat &MESSAGE; typically transits through only one or two XMPP servers and a
and a groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza might include
might include far more than four &SIGNATURE; elements.</p> far more than four &SIGNATURE; elements.</p>
</section2> </section2>
<section2 topic="Dual content" anchor="dual"> <section2 topic="Optimistic Signing" anchor="optimistic">
<p>One possible signing solution is for stanzas to carry alternative sets of content, an <p>Some users design the ability to <em>optimistic signing</em> of stanzas. That is, to sign
unsigned content alternative and a signed content alternative. An entity supporting the all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key
signing extension could make use of the signed content alternative while an entity not aspect of optimistic signing is that receiving entities not supporting the signing
supporting the signing extension could make use of the unsigned content alternative. The extension should be able to make use the message content (excluding the signature
following example not only illustrate this approach, but a significant issue with this information) while those receiving entities supporting the extension can make use of the
approach:</p> message content and the signature information.</p>
<p>Optimistic signing is available in E-mail through the use of S/MIME detached signatures.
Use of S/MIME detached signatures can be problematic. Mail systems, especially restribution
services such as mailing lists, are notorious for changing the signed content and hence
breaking the signature.</p>
<p>In XMPP, as stanzas are generally altered in transit and hence optimistic signing will be
fragile at best. Through use of selective signing and manifesting, issues may be mitigated
to some degree. It is doubtful that a solution exists that provides optimistic signing and
reliability verification.</p>
<section3 topic="Dual content" anchor="dual">
<p>One possible optimistic signing solution is for stanzas to carry <em>alternative</em> sets of
content, an unsigned content alternative and a signed content alternative. The premise of
this approach is that an entity supporting the signing extension could make use of the
signed content alternative while an entity not supporting the signing extension could make
use of the unsigned content alternative. The approach has been suggested to as a mechanism
for support extension-unaware entities downstream of extension-unware groupchat (or like)
services use of the stanza content.</p>
<p>The following example not only illustrate this approach, but highlights some of the
issues with this approach:</p>
<example caption="Dual content message"><![CDATA[ <example caption="Dual content message"><![CDATA[
<message from='hag66@shakespeare.lit/pda' to='darkcave@chat.shakespeare.lit/laptop' <message from='hag66@shakespeare.lit/pda' to='darkcave@chat.shakespeare.lit/laptop'
type='groupchat' xml:lang='en'> type='groupchat' xml:lang='en'>
@ -497,22 +542,46 @@
</signed-info> </signed-info>
<signature-value>...</signature-value> <signature-value>...</signature-value>
</encapslating-signature> </encapslating-signature>
<delay xmlns='urn:xmpp:delay'
from='shakespeare.lit'
stamp='2002-09-10T23:08:25Z'/>
</message> </message>
]]></example> ]]></example>
<p>Note that the &BODY; element values differ in the two alternatives.</p> <p>But it should be obvious that the signed and unsigned contents are not proper
<p>An attacker could alter the unsigned content without alerting entities making use the alternatives. The signed content presumedly is what the signer sent. The unsigned content
signed content.</p> is presumedly a modified version of what the signer sent. The modifications are generally
<p>Instead of treating the signed and unsigned content as alternatives, the solution could important to the entity making use of the stanza. In the above example, note that the
limit use of the signed content to the validation of the unsigned data. However this to/from addresses of the signed content differ from the unsigned content. Note as well
solution suffers from many same issues encapsulated signatures suffer from, as well as that the unsigned content contains a &gt;delay/&lt; element indicating that the stanza was
suffering from unnecessary bloat.</p> delayed in transit. Such modifications are generally important to the proper processing of
the content by not only this entity, but entities to which the content might be forwarded
to. Dual content, even in absence of attacks, simply complicates such processing. </p>
<p>Note that the &BODY; element values differ between the signed and unsigned content. While
it reasonable straight forward (though significant work) to determine that the signed and
unsigned content differ, it is extermely difficult to to determine whether the changes are
due to normal processing or an attack.</p>
<p>Dual content adds significant blot. In simple cases, the approach effective doubles the
content. However, in some use cases, the appraoch may lead to multiple doublings of the
content.</p>
<p>It must be noted that verifying entities downstream of a redistribution will need some
mechanism to determine who signed the stanza, determine what signer is an appropriate
signer, and to obtain the public key of that signer. While certain information can be
placed in key data, the question of whether the signer is an appropriate signer for
purported sender (e.g., a room subscriber) generally would require information from the
redistribution service, and this would generally require the redistribution service to
support an extension to make that information available to entities desiring to verify the
signature(s). If one accepts the premise that downstream verification of redistributed
stanzas, such as via a MUC service, cannot be performed without extension and cooperation
of the redistribution service, then it follows that dual content can be avoided by having
the MUC service also support the signing extension.</p>
<p>Dual content approaches should be avoided.</p> <p>Dual content approaches should be avoided.</p>
</section3>
</section2> </section2>
<section2 topic="Key Info" anchor="key-info"> <section2 topic="Key Info" anchor="key-info">
<p>While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so <p>While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so will
will significantly increase the size of the &SIGNATURE; element. As implementations may significantly increase the size of the &SIGNATURE; element. As implementations may enforce a
enforce a maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza signatures should
signatures should be limited.</p> be limited.</p>
<p>It is also noted there are cases where the signer may not want to expose the key <p>It is also noted there are cases where the signer may not want to expose the key
information to all entities involved in the exchange of stanza.</p> information to all entities involved in the exchange of stanza.</p>
<p>There are a number of ways key information may be published, such as in user's vCard. Key <p>There are a number of ways key information may be published, such as in user's vCard. Key
@ -535,12 +604,12 @@
<p>Designers of the solution should be mind full of security considerations discussed in XMLDSIG <p>Designers of the solution should be mind full of security considerations discussed in XMLDSIG
(regardless of whether XMLDSIG is used in the solution)</p> (regardless of whether XMLDSIG is used in the solution)</p>
<p>If XMLDSIG is used, a number of security considerations would be introduced into the <p>If XMLDSIG is used, a number of security considerations would be introduced into the
solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE; solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE; elements
elements to avoid a wide range of attacks. For instance, an attacker could attempt to mount a to avoid a wide range of attacks. For instance, an attacker could attempt to mount a Denial of
Denial of Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and complex
complex content. Or an attacker could attempt to mount a Distributed Denial of Service sending content. Or an attacker could attempt to mount a Distributed Denial of Service sending a
a message to a chatroom that containing &SIGNATURE; with multiple references to large message to a chatroom that containing &SIGNATURE; with multiple references to large content
content hosted at the attack target in hopes that each room participant will repeated fetch hosted at the attack target in hopes that each room participant will repeated fetch it. A
it. A &SIGNATURE; element might also contain circler references.</p> &SIGNATURE; element might also contain circler references.</p>
</section1> </section1>
</xep> </xep>

20
xep-0285.xml
View File

@ -26,6 +26,12 @@
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>
&kdz; &kdz;
<revision>
<version>0.2</version>
<date>2010-09-29</date>
<initials>kdz</initials>
<remark><p>Minor changes (editorial, cleanup, etc.).</p></remark>
</revision>
<revision> <revision>
<version>0.1</version> <version>0.1</version>
<date>2010-09-15</date> <date>2010-09-15</date>
@ -52,8 +58,10 @@
message is received (in the XMPP community this is called "offline storage" and the message is message is received (in the XMPP community this is called "offline storage" and the message is
referred to as an "offline message"). The authors surmise that RFC 3923 has not been referred to as an "offline message"). The authors surmise that RFC 3923 has not been
implemented mainly because it adds several new dependencies to XMPP clients, especially MIME implemented mainly because it adds several new dependencies to XMPP clients, especially MIME
(along with the CPIM and MSGFMT media types). This document explores the possibility of an (along with the CPIM and MSGFMT media types).</p>
approach that is similar to but simpler than RFC 3923.</p> <p>This document explores the possibility of an
approach that is similar to but simpler than RFC 3923. Like the approach detailed in RFC 3923,
the approach detailed does not support <em>optimistic signing</em>.</p>
</section1> </section1>
<section1 topic="Signing XMPP Stanzas" anchor="stanza"> <section1 topic="Signing XMPP Stanzas" anchor="stanza">
<p>The process that a sending agent follows for securing stanzas is very similar regardless of <p>The process that a sending agent follows for securing stanzas is very similar regardless of
@ -208,7 +216,7 @@
to='juliet@capulet.net/balcony' to='juliet@capulet.net/balcony'
type='error'> type='error'>
<signed xmlns='urn:xmpp:signed:0'> <signed xmlns='urn:xmpp:signed:0'>
XML-character-data-here <!-- original content -->
</signed> </signed>
<error type='modify'> <error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
@ -224,9 +232,9 @@
id='6410ed123' id='6410ed123'
to='juliet@capulet.net/balcony' to='juliet@capulet.net/balcony'
type='error'> type='error'>
<e2e xmlns='urn:xmpp:signed:0'> <signed xmlns='urn:xmpp:signed:0'>
XML-character-data-here <!-- original content -->
</e2e> </signed>
<error type='modify'> <error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<bad-signature xmlns='urn:ietf:params:xml:xmpp-signed:0'/> <bad-signature xmlns='urn:ietf:params:xml:xmpp-signed:0'/>