mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-24 10:12:19 -05:00
Revert unpublished changes
This reverts portions of commit c1173e8cf7a40a936e68a873069e191b846c7182 touching XEP 258.
This commit is contained in:
Kurt Zeilenga
parent
afce71aca9
commit
3eb5db6e0c
599
xep-0258.xml
599
xep-0258.xml
@ -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 specifies
|
<abstract>This document describes the use of security labels in XMPP. The document
|
||||||
how security label metadata is carried in XMPP, when this metadata should or should not
|
specifies how security label metadata is carried in XMPP, when this metadata
|
||||||
be provided, and how the metadata is to be processed.</abstract>
|
should or should not be provided, and how the metadata is to be processed.</abstract>
|
||||||
&LEGALNOTICE;
|
&LEGALNOTICE;
|
||||||
<number>0258</number>
|
<number>0258</number>
|
||||||
<status>Experimental</status>
|
<status>Experimental</status>
|
||||||
@ -26,98 +26,79 @@
|
|||||||
<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>
|
||||||
&kdz;
|
<author>
|
||||||
<revision>
|
<firstname>Kurt</firstname>
|
||||||
<version>0.7</version>
|
<surname>Zeilenga</surname>
|
||||||
<date>2010-09-29</date>
|
<email>Kurt.Zeilenga@Isode.COM</email>
|
||||||
<initials>kdz</initials>
|
<jid>Kurt.Zeilenga@Isode.COM</jid>
|
||||||
<remark>
|
</author>
|
||||||
<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>
|
<remark><p>Extend catalog handling. Minor editorial changes.</p></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>
|
<remark><p>Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.</p></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>
|
<remark><p>Update label catalogs to include user input selector.</p></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>
|
<remark><p>Add text regarding default bg/fg colors. Correct examples.</p></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>
|
<remark><p>Reworked discovery and various updates.</p></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>
|
<remark><p>Initial published version.</p></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>
|
<remark><p>Initial draft.</p></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 a structured
|
<p>A security label, sometimes referred to as a confidentiality label, is
|
||||||
representation of the sensitivity of a piece of information. A security label is used in
|
a structured representation of the sensitivity of a piece of information. A security
|
||||||
conjunction with a clearance, a structured representation of what information
|
label is used in conjunction with a clearance, a structured representation of what
|
||||||
sensitivities a person (or other entity) is authorized to access, and a security policy
|
information sensitivities a person (or other entity) is authorized to access, and a security
|
||||||
to control access to each piece of information. For instance, message could be labeled
|
policy to control access to each piece of information. For instance, message could be
|
||||||
as "SECRET", and hence requiring the sender and the receiver to have a clearance
|
labeled as "SECRET", and hence requiring the sender and the receiver to have a
|
||||||
granting access to "SECRET" information. &X.841; provides a discussion of security
|
clearance granting access to "SECRET" information. &X.841; provides a discussion of
|
||||||
labels, clearances, and security policy.</p>
|
security labels, clearances, and security policy.</p>
|
||||||
<p>Sensitivity-based authorization is used in networks which operate under a set of
|
<p>Sensitivity-based authorization is used in networks which operate under a set of
|
||||||
information classification rules, such as in government military agency networks. The
|
information classification rules, such as in government military agency networks. The
|
||||||
standardized formats for security labels, clearances, and security policy are
|
standardized formats for security labels, clearances, and security policy are
|
||||||
generalized and do have application in non-government networks.</p>
|
generalized and do have application in non-government networks.</p>
|
||||||
<p>This document describes the use of security labels in &xmpp;. The document specifies how
|
<p>This document describes the use of security labels in &xmpp;. The document specifies
|
||||||
security label metadata is carried in XMPP. It standardizes a mechanism for carrying ESS
|
how security label metadata is carried in XMPP. It standardizes a mechanism for
|
||||||
Security Labels in XMPP, as well as provides for use of other label formats. ESS
|
carrying ESS Security Labels in XMPP, as well as provides for use of other label
|
||||||
Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in
|
formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are
|
||||||
conjunction with &X.500; clearances and either X.841 or &SDN.801c; security
|
commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
|
||||||
policies.</p>
|
security policies.</p>
|
||||||
<example caption="Message with ESS Security Label"><![CDATA[
|
<example caption="Message with ESS Security Label"><![CDATA[
|
||||||
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
||||||
<body>This content is classified.</body>
|
<body>This content is classified.</body>
|
||||||
@ -141,64 +122,34 @@
|
|||||||
]]></example>
|
]]></example>
|
||||||
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
|
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
|
||||||
|
|
||||||
<p>To securely bind the security label to the message, &xep0285; can be used as detailed below.</p>
|
<p>The document details when security label metadata should or should not be provided, and how
|
||||||
<example caption="Message with Securely bound ESS Security Label"><![CDATA[
|
this metadata is to be processed.</p>
|
||||||
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
|
||||||
<signed xmlns="urn:xmpp:signed:0">
|
|
||||||
<signature algorithm="RSA-SHA1">To-be-computed
|
|
||||||
</signature>
|
|
||||||
<data>
|
|
||||||
PG1lc3NhZ2UgdG89J3JvbWVvQGV4YW1wbGUubmV0JyBmcm9tPSdqdWxpZXRAZXhhbXBsZS5jb20v
|
|
||||||
YmFsY29ueSc+CiAgICA8Ym9keT5UaGlzIGNvbnRlbnQgaXMgY2xhc3NpZmllZC48L2JvZHk+CiAg
|
|
||||||
ICA8c2VjdXJpdHlsYWJlbCB4bWxucz0ndXJuOnhtcHA6c2VjLWxhYmVsOjAnPgogICAgICAgIDxk
|
|
||||||
aXNwbGF5bWFya2luZyBmZ2NvbG9yPSdibGFjaycgYmdjb2xvcj0ncmVkJz5TRUNSRVQ8L2Rpc3Bs
|
|
||||||
YXltYXJraW5nPgogICAgICAgIDxsYWJlbD48aWNpc21sYWJlbCB4bWxucz0naHR0cDovL2V4YW1w
|
|
||||||
bGUuZ292L0lDLUlTTS8wJyBjbGFzc2lmaWNhdGlvbj0nUycKICAgICAgICAgICAgb3duZXJQcm9k
|
|
||||||
dWNlcj0nVVNBJy8+PC9sYWJlbD4KICAgIDwvc2VjdXJpdHlsYWJlbD4KPC9tZXNzYWdlPgo=
|
|
||||||
</data>
|
|
||||||
</message>
|
|
||||||
]]>
|
|
||||||
</example>
|
|
||||||
|
|
||||||
<p>The document details when security label metadata should or should not be provided, and
|
|
||||||
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 enforce at its
|
<li>any mechanism for a client might discover the security policy
|
||||||
home server, or any other server;</li>
|
enforce at its home server, or any other server;</li>
|
||||||
<li>any mechanism for a client to discover the user's clearance, or the clearance of
|
<li>any mechanism for a client to discover the user's clearance,
|
||||||
associated with any resource; nor</li>
|
or the clearance of associated with any resource; nor</li>
|
||||||
<li>any administrative mechanism for a client to configure configure policy,
|
<li>any administrative mechanism for a client to configure
|
||||||
clearance, and labels of any resource.</li>
|
configure policy, clearance, and labels of any resource.</li>
|
||||||
</ul>
|
</ul>
|
||||||
Such mechanisms may be introduced in subsequent documents.</p>
|
|
||||||
</section1>
|
|
||||||
|
|
||||||
<section1 topic="Discovering Feature Support" anchor="disco">
|
Such mechanisms may be introduced in subsequent documents.</p>
|
||||||
<p>If an entity supports the XMPP Security Label protocol, it MUST report that fact by
|
</section1>
|
||||||
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
|
<section1 topic='Discovering Feature Support' anchor='disco'>
|
||||||
element in any stanza they generate SHOULD determine if their server supports the XMPP
|
<p>If an entity supports the XMPP Security Label protocol, it MUST report that fact
|
||||||
Security Label protocol. If their server does not support XMPP Security Label, the
|
by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in
|
||||||
client SHOULD NOT generate XMPP Security Labels as the server not supporting this
|
response to a &xep0030; information request. Clients wishing to include a XMPP
|
||||||
protocol will generally ignore XMPP Security Labels as they would any other unrecognized
|
Security Label element in any stanza they generate SHOULD determine if their
|
||||||
element.</p>
|
server supports the XMPP Security Label protocol. If their server does not
|
||||||
<p>If an entity supports secure binding of the XMPP Security Label using &xmppdsig;, it MUST
|
support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels
|
||||||
report the fact by including a service discover feature of
|
as the server not supporting this protocol will generally ignore XMPP Security
|
||||||
"<tt>urn:xmpp:sec-label:dsig:0</tt>"" in response to a &xep0030; information request.
|
Labels as they would any other unrecognized element.</p>
|
||||||
Clients wishing to include a securely bound XMPP Security Label element in any stanza
|
<p>As each service domain may have different support for security labels, servers
|
||||||
they generate SHOULD determine if their server supports the XMPP Security Label
|
should advertise and clients should perform appropriate discovery lookups on a
|
||||||
protocol. If their server does not support securely bound XMPP Security Label, the
|
per service basis.</p>
|
||||||
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'
|
||||||
@ -215,21 +166,20 @@
|
|||||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||||
...
|
...
|
||||||
<feature var='urn:xmpp:sec-label:0'/>
|
<feature var='urn:xmpp:sec-label:0'/>
|
||||||
<feature var='urn:xmpp:sec-label:dsig:0'/>
|
|
||||||
...
|
...
|
||||||
</query>
|
</query>
|
||||||
</iq>
|
</iq>
|
||||||
]]></example>
|
]]></example>
|
||||||
<!--
|
<!--
|
||||||
<p>A server should only include &IDENTITY; elements in the response for services
|
<p>A server should only include &IDENTITY; elements in the response for services
|
||||||
the user is cleared to use.</p>
|
the user is cleared to use.</p>
|
||||||
-->
|
-->
|
||||||
</section1>
|
</section1>
|
||||||
|
|
||||||
<section1 topic="Protocol" anchor="protocol">
|
<section1 topic='Protocol' anchor='protocol'>
|
||||||
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
|
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
|
||||||
includes a security label, zero or more equivalent security labels, and optionally
|
includes a security label, zero or more equivalent security labels, and optionally display
|
||||||
display marking data.</p>
|
marking data.</p>
|
||||||
<example caption="Labeled Message"><![CDATA[
|
<example caption="Labeled Message"><![CDATA[
|
||||||
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
||||||
<body>This content is classified.</body>
|
<body>This content is classified.</body>
|
||||||
@ -246,69 +196,85 @@
|
|||||||
</securitylabel>
|
</securitylabel>
|
||||||
</message>
|
</message>
|
||||||
]]></example>
|
]]></example>
|
||||||
<p>The security label metadata is carried in an &SECURITYLABEL; element. The &SECURITYLABEL;
|
<p>The security label metadata is carried in an &SECURITYLABEL; element.
|
||||||
element which contains one and only one &LABEL; element, zero or more &EQUIVALENTLABEL;
|
The &SECURITYLABEL; element which contains one and only one &LABEL; element,
|
||||||
elements, and an optional &DISPLAYMARKING; element.</p>
|
zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
|
||||||
<p>The &LABEL; provides the primary security label. It is commonly issued by the sender
|
<p>The &LABEL; provides the primary security label. It is commonly issued
|
||||||
under the security policy of that they and their home server operating under. The
|
by the sender under the security policy of that they and their home
|
||||||
&LABEL; contains either a single element representing the primary security label or is
|
server operating under. The &LABEL; contains either a single element
|
||||||
empty to indicate use of a default.</p>
|
representing the primary security label or is empty to indicate use of
|
||||||
<p>Each &EQUIVALENTLABEL; represents an equivalent security label under other policies. Each
|
a default.</p>
|
||||||
&EQUIVALENTLABEL; contains a single element representing the equivalent label. This
|
<p>Each &EQUIVALENTLABEL; represents an equivalent security label under
|
||||||
element might be used when a recepient is known to hold a clearance under a different
|
other policies. Each &EQUIVALENTLABEL; contains a single element
|
||||||
policy than the sender.</p>
|
representing the equivalent label. This element might be used when
|
||||||
<p>The &DISPLAYMARKING; element contains a display string for use by implementations which
|
a recepient is known to hold a clearance under a different policy
|
||||||
are unable to utilize the applicable security policy to generate display markings. The
|
than the sender.</p>
|
||||||
element may optionally contain two attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>,
|
<p>The &DISPLAYMARKING; element contains a display string for use by
|
||||||
whose values are HTML color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for
|
implementations which are unable to utilize the applicable security policy
|
||||||
use in colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>.
|
to generate display markings. The element may optionally contain two
|
||||||
The <tt>bgcolor=</tt> default is <tt>white</tt>. </p>
|
attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML
|
||||||
</section1>
|
color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for use in
|
||||||
|
colorizing the display marking. The <tt>fgcolor=</tt> default is <tt>black</tt>.
|
||||||
|
The <tt>bgcolor=</tt> default is <tt>white</tt>.
|
||||||
|
</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
<section1 topic="Label Catalog Discovery" anchor="label-catalog">
|
<section1 topic='Label Catalog Discovery' anchor='label-catalog'>
|
||||||
<p>A client can request a catalog for a particular JID by sending a catalog discovery
|
<p>A client can request a catalog for a particular JID by sending
|
||||||
request to the client's server. Where the JID is hosted by some other server, the
|
a catalog discovery request to the client's server. Where the JID
|
||||||
client's server is expected to produce a suitable catalog (or fail the request). The
|
is hosted by some other server, the client's server is expected to
|
||||||
client's server may, as needed, query catalogs from other servers in order to fulfill
|
produce a suitable catalog (or fail the request). The client's server
|
||||||
the client's request.</p>
|
may, as needed, query catalogs from other servers in order to
|
||||||
<p>While this specification does not preclude a client from directing a catalog request
|
fulfill the client's request.</p>
|
||||||
elsewhere, it is noted that catalog returned by a party other than its server may not be
|
<p>While this specification does not preclude a client from directing
|
||||||
directly useable by the client. For instance, the client's server might require a
|
a catalog request elsewhere, it is noted that catalog returned by
|
||||||
particular only-locally-known label be used in messages to a particular remote JID.</p>
|
a party other than its server may not be directly useable by the
|
||||||
<p>It is RECOMMENDED the server publish catalogs of security label for use by clients.</p>
|
client. For instance, the client's server might require a particular
|
||||||
<p>If catalog is restrictive, as indicated by the restrictive attribute with value of true,
|
only-locally-known label be used in messages to a particular remote
|
||||||
the client SHOULD use one of the labels (or no label) offered by the catalog.</p>
|
JID.</p>
|
||||||
<p>One and only one of the items may have a default attribute with value of true. The client
|
<p>It is RECOMMENDED the server publish catalogs of security label
|
||||||
should default to this item in cases where the user has not selected an item.</p>
|
for use by clients.</p>
|
||||||
<p>An item may have no label. Such an item offers a choice of sending a stanza without a
|
<p>If catalog is restrictive, as indicated by the restrictive attribute
|
||||||
label.</p>
|
with value of true, the client SHOULD use one of the labels
|
||||||
<p>Each catalog provided should only contain labels for which the client is allowed to use
|
(or no label) offered by the catalog.</p>
|
||||||
(based upon the user's authorization) in a particular context (such as in chatroom). A
|
<p>One and only one of the items may have a default attribute with
|
||||||
catalog may not be include the complete set of labels available for the use by the
|
value of true. The client should default to this item in cases
|
||||||
client in the context.</p>
|
where the user has not selected an item.</p>
|
||||||
<blockquote>Note: the single catalog per context approach used here is likely inadequate in
|
<p>An item may have no label. Such an item offers a choice of
|
||||||
enviroments where there are a large number of labels in use. It is expected that a more
|
sending a stanza without a label.</p>
|
||||||
sophisticated approach will be introduced in a subsequent revision of this
|
<p>Each catalog provided should only contain labels for which the client
|
||||||
|
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, servers should
|
<p>As each service domain may have different support for security labels,
|
||||||
advertise and clients should perform appropriate discovery lookups on a per service
|
servers should advertise and clients should perform appropriate
|
||||||
basis.</p>
|
discovery lookups on a per service basis.</p>
|
||||||
<p>To indicate the support for label catalog discovery, a server advertises the
|
<p>To indicate the support for label catalog discovery, a server
|
||||||
<tt>urn:xmpp:sec-label:catalog:2</tt> feature. The following pair of examples
|
advertises the <tt>urn:xmpp:sec-label:catalog:2</tt> feature.
|
||||||
illustrates this feature discovery.</p>
|
The following pair of examples illustrates this feature discovery.</p>
|
||||||
<p>Each item in the catalog may contain a selector attribute. The value of this attribute
|
<p>Each item in the catalog may contain a selector attribute. The
|
||||||
represents the item's placement in a hierarchical organization of the items. The value
|
value of this attribute represents the item's placement in a
|
||||||
of the selector attribute conforms to the selector-value ABNF production: <blockquote>
|
hierarchical organization of the items. The value of the selector
|
||||||
<![CDATA[
|
attribute conforms to the selector-value ABNF production:
|
||||||
|
<blockquote>
|
||||||
|
<![CDATA[
|
||||||
selector-value = (<item>"|")*<item>
|
selector-value = (<item>"|")*<item>
|
||||||
]]>
|
]]>
|
||||||
</blockquote>
|
</blockquote>
|
||||||
</p>
|
</p>
|
||||||
<p>where <item> is a sequence of characters not including "|".</p>
|
<p>where <item> is a sequence of characters not including "|".</p>
|
||||||
<p>A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X"
|
<p>A value of "X|Y|Z" indicates that this item is "Z" in the
|
||||||
subset of items. This information may be used, for instance, in generating label
|
the "Y" subset of the "X" subset of items. This information may
|
||||||
selection menus in graphical user interfaces.</p>
|
be used, for instance, in generating label selection menus in
|
||||||
<blockquote>Note: use of unnecessarily deep hierarchies should be avoided.</blockquote>
|
graphical user interfaces.</p>
|
||||||
|
<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'
|
||||||
@ -329,9 +295,7 @@ selector-value = (<item>"|")*<item>
|
|||||||
</iq>
|
</iq>
|
||||||
]]></example>
|
]]></example>
|
||||||
|
|
||||||
<p>The following example pair illustrates catalog discovery. Note that client directs the
|
<p>The following example pair illustrates catalog discovery. Note that client directs the &IQ; to its server regardless of which catalog it requests (via the to= attribute of in &CATALOG; element).</p>
|
||||||
&IQ; to its server regardless of which catalog it requests (via the to= attribute of in
|
|
||||||
&CATALOG; element).</p>
|
|
||||||
|
|
||||||
<example caption="Label Catalog request"><![CDATA[
|
<example caption="Label Catalog request"><![CDATA[
|
||||||
<iq type='get' id='cat1'>
|
<iq type='get' id='cat1'>
|
||||||
@ -376,64 +340,72 @@ selector-value = (<item>"|")*<item>
|
|||||||
</catalog>
|
</catalog>
|
||||||
</iq>
|
</iq>
|
||||||
]]></example>
|
]]></example>
|
||||||
</section1>
|
</section1>
|
||||||
|
|
||||||
<section1 topic="Use in XMPP" anchor="xmpp-use">
|
<section1 topic='Use in XMPP' anchor='xmpp-use'>
|
||||||
<p>The sensitivity-based access control decisions discussed herein are to be made
|
<p>The sensitivity-based access control decisions discussed herein are to be
|
||||||
independently of other access control decisions or other facilities. That is, the
|
made independently of other access control decisions or other facilities.
|
||||||
sensitivity-based access control decisions are not conditional on other factors.</p>
|
That is, the sensitivity-based access control decisions are not conditional
|
||||||
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by this
|
on other factors.</p>
|
||||||
document, or other formal specifications. Any other use of &SECURITYLABEL; SHOULD be
|
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by
|
||||||
viewed as a protocol violation. The stanza SHOULD be discarded with, if approrpriate, an
|
this document, or other formal specifications. Any other use of
|
||||||
error response. Such error responses SHOULD NOT include content from the violating
|
&SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD
|
||||||
stanza, excepting that necessary to well-formed error responses.</p>
|
be discarded with, if approrpriate, an error response. Such error responses
|
||||||
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. Absence of
|
SHOULD NOT include content from the violating stanza, excepting that
|
||||||
a &SECURITYLABEL; element implies the stanza has the default label as specified in the
|
necessary to well-formed error responses.</p>
|
||||||
governing security policy. Given that the governing policy may not specify a default
|
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED.
|
||||||
label, hence denying access to the stanza, supporting clients SHOULD provide a
|
Absence of a &SECURITYLABEL; element implies the stanza has the default label
|
||||||
&SECURITYLABEL; element where prescribed.</p>
|
as specified in the governing security policy. Given that the governing
|
||||||
<p>Typically, a client would allow the user to choose populate the &SECURITYLABEL; from one
|
policy may not specify a default label, hence denying access to the stanza,
|
||||||
of from a small set of security labels selections known to it (through configuration
|
supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p>
|
||||||
and/or discovery and/or other means), such as from a pull-down menu. That selection
|
<p>Typically, a client would allow the user to choose populate the
|
||||||
would include appropriate values for the &LABEL;, &DISPLAYMARKING;, and
|
&SECURITYLABEL; from one of from a small set of security labels selections
|
||||||
&EQUIVALENTLABEL; elements.</p>
|
known to it (through configuration and/or discovery and/or other means),
|
||||||
<p>A policy-aware client may provide the user with an interface allowing the user to produce
|
such as from a pull-down menu. That selection would include appropriate
|
||||||
custom labeling data for inclusion in this set. A policy-aware client SHOULD preclude
|
values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p>
|
||||||
the user from producing &LABEL; values which the user's own clearance does not grant
|
<p>A policy-aware client may provide the user with an interface allowing the
|
||||||
access to, and SHOULD preclude sending any label which the user's own clearance does not
|
user to produce custom labeling data for inclusion in this set. A
|
||||||
grant access to. Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an
|
policy-aware client SHOULD preclude the user from producing &LABEL; values
|
||||||
equivalent policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the display
|
which the user's own clearance does not grant access to, and SHOULD preclude
|
||||||
marking prescribed for the &LABEL; under the governing policy, or, if the governing
|
sending any label which the user's own clearance does not grant access to.
|
||||||
policy prescribes no display marking for the &LABEL;, absent.</p>
|
Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent
|
||||||
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently display
|
policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the
|
||||||
the &DISPLAYMARKING; value. A policy-aware may alternatively promiently display the
|
display marking prescribed for the &LABEL; under the governing policy, or,
|
||||||
marking for the &LABEL; prescribed by the governing policy.</p>
|
if the governing policy prescribes no display marking for the &LABEL;,
|
||||||
<p>Each server is expected to make a number of sensitivity-based authorization decisions.
|
absent.</p>
|
||||||
Each decision is made by evaluating an Access Control Decision Function (ACDF) with a
|
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
|
||||||
governing policy, a clearance, and a security label. The ACDF yields either
|
display the &DISPLAYMARKING; value. A policy-aware may alternatively
|
||||||
<em>Grant</em> or <em>Deny</em>.</p>
|
promiently display the marking for the &LABEL; prescribed by the governing
|
||||||
<p>If the user holds a valid clearance (known to the server) under the governing policy, the
|
policy.</p>
|
||||||
clearance input is the user's clearance. Otherwise, if the governing policy provides a
|
<p>Each server is expected to make a number of sensitivity-based authorization
|
||||||
default clearance, the clearance input is the default clearance. Otherwise, the
|
decisions. Each decision is made by evaluating an Access Control Decision
|
||||||
clearance input is the nil clearance. The nil clearance is a clearance for which the
|
Function (ACDF) with a governing policy, a clearance, and a security label.
|
||||||
ACDF always returns Deny when given as the clearance input.</p>
|
The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p>
|
||||||
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; element or
|
<p>If the user holds a valid clearance (known to the server) under the
|
||||||
one of the &EQUIVALENTLABEL; elements contain an appropriate label, that label input is
|
governing policy, the clearance input is the user's clearance. Otherwise,
|
||||||
that label. Otherwise, the label input is the default label provided the governing
|
if the governing policy provides a default clearance, the clearance input
|
||||||
policy or, if no default label is provided, the nil label. The nil label is a label for
|
is the default clearance. Otherwise, the clearance input is the nil clearance.
|
||||||
which the ACDF always returns Deny when given as the label input.</p>
|
The nil clearance is a clearance for which the ACDF always returns Deny when
|
||||||
<p>The term "effective clearance" and "effective label" refer, respectively, to the
|
given as the clearance input.</p>
|
||||||
clearance and label provided as input to the ACDF.</p>
|
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL;
|
||||||
<p>Not all sensitivity-based authorization decisions an XMPP server might make involve a
|
element or one of the &EQUIVALENTLABEL; elements contain an appropriate label,
|
||||||
user clearance and/or stanza label. A server may only provide service to users which
|
that label input is that label. Otherwise, the label input is the default
|
||||||
hold an appropriate clearance as determined by calling the ACDF with the user's
|
label provided the governing policy or, if no default label is provided,
|
||||||
clearance and a label associated with the service. A clearance might also be associated
|
the nil label. The nil label is a label for which the ACDF always returns
|
||||||
with the service to restrict the set of labels may be used in labeling stanzas. Labels
|
Deny when given as the label input.</p>
|
||||||
and clearances can also be associated with network interfaces, remote servers,
|
<p>The term "effective clearance" and "effective label" refer, respectively,
|
||||||
chatrooms, pubsub notes.</p>
|
to the clearance and label provided as input to the ACDF.</p>
|
||||||
<section2 topic="Use in Instant Messaging" anchor="im-use">
|
<p>Not all sensitivity-based authorization decisions an XMPP server might make
|
||||||
|
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>
|
||||||
@ -441,48 +413,49 @@ 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
|
<p>A server SHOULD provide a label feature and information discovery for the room.</p>
|
||||||
room.</p>
|
|
||||||
<p>Clients SHOULD discover label feature and information on a per room basis.</p>
|
<p>Clients SHOULD discover label feature and information on a per room basis.</p>
|
||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Sending Messages" anchor="muc-send">
|
<section3 topic='Sending Messages' anchor='muc-send'>
|
||||||
<p>Sending groupchat messages is similiar to sending normal messages, however their
|
<p>Sending groupchat messages is similiar to sending normal messages, however
|
||||||
are a few differences.</p>
|
their are a few differences.</p>
|
||||||
<p>Groupchat messages are addressed to the room. The room clearance must be suitable
|
<p>Groupchat messages are addressed to the room. The room clearance must
|
||||||
for the message label, else it should be rejected.</p>
|
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
|
<p>The room's clearance may allow a variety of labels to be used. Not all
|
||||||
may be cleared for all labels allowed in the room. The server MUST only deliver
|
partipants may be cleared for all labels allowed in the room. The server
|
||||||
messages to partipants for which they are cleared to receive.</p>
|
MUST only deliver messages to partipants for which they are cleared to
|
||||||
|
receive.</p>
|
||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Private Messages" anchor="muc-private">
|
<section3 topic='Private Messages' anchor='muc-private'>
|
||||||
<p>Private messages are treated as discussed in the "Use in Instant Messaging"
|
<p>Private messages are treated as discussed in the "Use in Instant Messaging"
|
||||||
section. (Should private messages be restricted by room's configuration?)</p>
|
section. (Should private messages be restricted by room's configuration?)</p>
|
||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Invitations" anchor="muc-invite">
|
<section3 topic='Invitations' anchor='muc-invite'>
|
||||||
<p>Invitations may be labeled.</p>
|
<p>Invitations may be labeled.</p>
|
||||||
</section3>
|
</section3>
|
||||||
<section3 topic="Changing Subject" anchor="muc-subject">
|
<section3 topic='Changing Subject' anchor='muc-subject'>
|
||||||
<p>This section discusses semantics of &SECURITYLABEL; elements contained in
|
<p>This section discusses semantics of &SECURITYLABEL; elements contained
|
||||||
&MESSAGE; stanzas containing a &SUBJECT; element.</p>
|
in &MESSAGE; stanzas containing a &SUBJECT; element.</p>
|
||||||
<p>The presence of a &SECURITYLABEL; element indicates a request to change the
|
<p>The presence of a &SECURITYLABEL; element indicates a request to change
|
||||||
room's label, either to the provided label or, if the element is empty, to unset
|
the room's label, either to the provided label or, if the element is empty,
|
||||||
the room's label. The server is to refuse the request if the requestor is not
|
to unset the room's label. The server is to refuse the request if the
|
||||||
authorized to change the subject, not cleared for the requested label, or if the
|
requestor is not authorized to change the subject, not cleared for the
|
||||||
server is otherwise unwilling or unable to make the change. If the label change
|
requested label, or if the server is otherwise unwilling or unable to make
|
||||||
is refused, so must the accompanied subject change. Likewise, if the subject
|
the change. If the label change is refused, so must the accompanied
|
||||||
change is refused, so must the accompanied label change.</p>
|
subject change. Likewise, if the subject change is refused, so must the
|
||||||
<p>Upon change of the room's label, the server MUST immediately remove from the room
|
accompanied label change.</p>
|
||||||
all members whom are not cleared for that label.</p>
|
<p>Upon change of the room's label, the server MUST immediately remove from
|
||||||
<p>In absence of a &SECURITYLABEL; element, the label associated with the room is
|
the room all members whom are not cleared for that label.</p>
|
||||||
unchanged.</p>
|
<p>In absence of a &SECURITYLABEL; element, the label associated with the
|
||||||
<p>The room's label can also be changed through room configuration (to be discussed
|
room is unchanged.</p>
|
||||||
in later revision of this document).</p>
|
<p>The room's label can also be changed through room configuration (to be
|
||||||
|
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
|
||||||
@ -556,20 +529,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 SHALL treat
|
<p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server
|
||||||
any &PRESENCE; stanza that contains a &SECURITYLABEL; as a protocol violation.</p>
|
SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a
|
||||||
<p>Presence information is subject to sensitivity-base authorization decisions, however
|
protocol violation.</p>
|
||||||
these decisions are made are made using a label associated with the presence
|
<p>Presence information is subject to sensitivity-base authorization decisions,
|
||||||
resource, such as a chatroom's label.</p>
|
however these decisions are made are made using a label associated with the
|
||||||
|
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
|
<p>A server SHOULD provide a label feature and information discovery for each node.</p>
|
||||||
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'
|
||||||
@ -639,38 +612,41 @@ 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> This extension is itself is extensible. In particular, the &LABEL; and &EQUIVALENTLABEL;
|
<p>
|
||||||
|
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. </p>
|
be used to avoid name clashes.
|
||||||
</section1>
|
</p>
|
||||||
|
</section1>
|
||||||
|
|
||||||
<!--
|
<!--
|
||||||
<section1 topic='Implementation Notes' anchor='impl'>
|
<section1 topic='Implementation Notes' anchor='impl'>
|
||||||
<p>OPTIONAL.</p>
|
<p>OPTIONAL.</p>
|
||||||
</section1>
|
</section1>
|
||||||
-->
|
-->
|
||||||
<section1 topic="Security Considerations" anchor="security">
|
<section1 topic='Security Considerations' anchor='security'>
|
||||||
<p>This document is all about authorization, a key aspect of security. Hence, security
|
<p>This document is all about authorization, a key aspect of security. Hence,
|
||||||
considerations are discussed through this document.</p>
|
security considerations are discussed through this document.</p>
|
||||||
<p>Security labels generally should be securely bound to the object. This may be
|
<p>Security labels generally should be securely bound to the object. This may be
|
||||||
accomplished through use of &xmppdsig; as discussed in Appendix A.</p>
|
accomplished through use of &xmppe2e; signing, or possibly other signing
|
||||||
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject to any
|
mechanisms.</p>
|
||||||
sensitity-based authorization decisions, and may be forwarded throughout the XMPP
|
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
|
||||||
network. The content of these stanzas should not contain information requiring
|
to any sensitity-based authorization decisions, and may be forwarded throughout
|
||||||
sensitivity-based dissemination controls.</p>
|
the XMPP network. The content of these stanzas should not contain information
|
||||||
</section1>
|
requiring sensitivity-based dissemination controls.</p>
|
||||||
<section1 topic="IANA Considerations" anchor="iana">
|
</section1>
|
||||||
|
<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 ®ISTRAR; add the extension's namespaces and schemas to appropriate
|
<p>It is requested the ®ISTRAR; add the extension's namespaces
|
||||||
XMPP registries.</p>
|
and schemas to appropriate 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'?>
|
||||||
@ -769,11 +745,14 @@ And by opposing end them?
|
|||||||
</xs:complexType>
|
</xs:complexType>
|
||||||
</xs:element>
|
</xs:element>
|
||||||
</xs:schema>
|
</xs:schema>
|
||||||
]]></code> A copy of this schema is available at <link
|
]]></code>
|
||||||
url="http://www.xmpp.org/schemas/sec-label.xsd">
|
|
||||||
http://www.xmpp.org/schemas/sec-label.xsd</link>. </p>
|
A copy of this schema is available at
|
||||||
</section2>
|
<link url='http://www.xmpp.org/schemas/sec-label.xsd'>
|
||||||
<section2 topic="<catalog/> schema" anchor="schema-catalog">
|
http://www.xmpp.org/schemas/sec-label.xsd</link>.
|
||||||
|
</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic='<catalog/> schema' anchor='schema-catalog'>
|
||||||
<p>
|
<p>
|
||||||
<code><![CDATA[
|
<code><![CDATA[
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
@ -863,11 +842,14 @@ And by opposing end them?
|
|||||||
</xs:complexType>
|
</xs:complexType>
|
||||||
</xs:element>
|
</xs:element>
|
||||||
</xs:schema>
|
</xs:schema>
|
||||||
]]></code> A copy of this schema is available at <link
|
]]></code>
|
||||||
url="http://www.xmpp.org/schemas/sec-label-catalog.xsd">
|
|
||||||
http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>. </p>
|
A copy of this schema is available at
|
||||||
</section2>
|
<link url='http://www.xmpp.org/schemas/sec-label-catalog.xsd'>
|
||||||
<section2 topic="<esssecuritylabel/> schema" anchor="schema-ess">
|
http://www.xmpp.org/schemas/sec-label-catalog.xsd</link>.
|
||||||
|
</p>
|
||||||
|
</section2>
|
||||||
|
<section2 topic='<esssecuritylabel/> schema' anchor='schema-ess'>
|
||||||
<p>
|
<p>
|
||||||
<code><![CDATA[
|
<code><![CDATA[
|
||||||
<?xml version="1.0" encoding="UTF-8"?>
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
@ -885,9 +867,12 @@ And by opposing end them?
|
|||||||
</xs:annotation>
|
</xs:annotation>
|
||||||
</xs:element>
|
</xs:element>
|
||||||
</xs:schema>
|
</xs:schema>
|
||||||
]]></code> A copy of this schema is available at <link
|
]]></code>
|
||||||
url="http://www.xmpp.org/schemas/sec-label-ess.xsd">
|
|
||||||
http://www.xmpp.org/schemas/sec-label-ess.xsd</link>. </p>
|
A copy of this schema is available at
|
||||||
</section2>
|
<link url='http://www.xmpp.org/schemas/sec-label-ess.xsd'>
|
||||||
</section1>
|
http://www.xmpp.org/schemas/sec-label-ess.xsd</link>.
|
||||||
|
</p>
|
||||||
|
</section2>
|
||||||
|
</section1>
|
||||||
</xep>
|
</xep>
|
||||||
|
|||||||
215
xep-0274.xml
215
xep-0274.xml
@ -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 <<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>>.</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 <<link url='http://www.w3.org/TR/xmldsig-core/'>http://www.w3.org/TR/xmldsig-core/</link>>.</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 <<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>>.</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 <<link url='http://www.w3.org/TR/xptr'>http://www.w3.org/TR/xptr</link>>.</note>" >
|
||||||
<!ENTITY xmppdsig "<span class='ref'><link url='http://xmpp.org/extensions/inbox/dsig.html'>XMPP DSIG</link></span> <note>XMPP Digital Signatures <<link url='http://xmpp.org/extensions/inbox/dsig.html'>http://xmpp.org/extensions/inbox/dsig.html</link>>.</note>" >%ents;
|
%ents;
|
||||||
]>
|
]>
|
||||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||||
<xep>
|
<xep>
|
||||||
@ -22,7 +22,9 @@
|
|||||||
<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> &LEGALNOTICE; <number>0274</number>
|
Signatures could be used in XMPP.</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>0274</number>
|
||||||
<status>Experimental</status>
|
<status>Experimental</status>
|
||||||
<type>Informational</type>
|
<type>Informational</type>
|
||||||
<sig>Standards</sig>
|
<sig>Standards</sig>
|
||||||
@ -35,21 +37,11 @@
|
|||||||
<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>
|
<remark><p>Initial published version as accepted for publication by the XMPP Council.</p></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>
|
||||||
@ -170,10 +162,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 service
|
publishing entity sends a &PRESENCE; stanza to a presence service and the presence
|
||||||
than forwards the stanza to each subscriber. In basic user presence, the publishing entity
|
service than forwards the stanza to each subscriber. In basic user presence, the publishing
|
||||||
is the user's client and the presence service is presence service is the provided by this
|
entity is the user's client and the presence service is presence service is the provided by
|
||||||
client's server. In this case, the 'to' address is empty.</p>
|
this 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>
|
||||||
@ -187,9 +179,8 @@
|
|||||||
</section2>
|
</section2>
|
||||||
</section1>
|
</section1>
|
||||||
|
|
||||||
<section1 topic="General Requirements" anchor="requires">
|
<section1 topic="Requirements" anchor="requires">
|
||||||
<p>For the purposes of this memo, the following requirements are stipulated for a general
|
<p>For the purposes of this memo, the following requirements are stipulated: </p>
|
||||||
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
|
||||||
@ -218,24 +209,16 @@
|
|||||||
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 &xmppe2e;. XMPP
|
<p>The &IETF; standardized a signing and encryption facility for XMPP known as
|
||||||
E2E is based upon Secure/Multipurpose Internet Message Extensions (&SMIME;) and the
|
&xmppe2e;. XMPP E2E is based upon Secure/Multipurpose Internet Message Extensions
|
||||||
Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP E2E is intended to be an
|
(&SMIME;) and the Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP
|
||||||
end-to-end solution. That is, it enables a sender to sign content sent to a specific
|
E2E is intended to be an end-to-end solution. That is, it enables a sender to sign content
|
||||||
recipient.</p>
|
sent to a specific 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
|
||||||
@ -243,15 +226,6 @@
|
|||||||
<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
|
||||||
@ -271,8 +245,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 and
|
signature syntax in encapsulated within the structure of the signed content. XMPP E2E is an
|
||||||
XMPP DSIG are examples of the former. CDCIE-CCP is an example of the latter.</p>
|
example 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>
|
||||||
@ -311,13 +285,13 @@
|
|||||||
</encapsulated-signature>
|
</encapsulated-signature>
|
||||||
</message>
|
</message>
|
||||||
]]></example>
|
]]></example>
|
||||||
<p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and
|
<p>Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E, are
|
||||||
XMPP DSIG, are generally limited to end-to-end use cases. That is, cases where the
|
generally limited to end-to-end use cases. That is, cases where the originator of a stanza
|
||||||
originator of a stanza signs the stanza and send it through the XMPP network to its intended
|
signs the stanza and send it through the XMPP network to its intended recipient, and only
|
||||||
recipient, and only the intended recipient is expected to make use of the signed content.
|
the intended recipient is expected to make use of the signed content. Entities between the
|
||||||
Entities between the signer and the intended recipient are expected to forward of the stanza
|
signer and the intended recipient are expected to forward of the stanza without regard to
|
||||||
without regard to the encapsulating signature, and without themselves signing the stanza.
|
the encapsulating signature, and without themselves signing the stanza. The approach does
|
||||||
The approach does not require forwarding entities to support the signing extension.</p>
|
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
|
||||||
@ -408,32 +382,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 is
|
&MESSAGE; element before forwarding it to the example.net server. The example.net server
|
||||||
required to replace the 'to' attribute with the full JID of the romeo@example.net client it
|
is required to replace the 'to' attribute with the full JID of the romeo@example.net client
|
||||||
intends to forward the message to. These alternatations will "break" the signature.</p>
|
it 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 itself would
|
could sign the &SUBJECT; and &BODY; element and their content. However, this by
|
||||||
not cover key aspects of the stanza, such that it was a chat &MESSAGE; addressed to a
|
itself would not cover key aspects of the stanza, such that it was a chat &MESSAGE;
|
||||||
particular JID and sent from a particular JID. XMLDSIG allows for enveloping signatures,
|
addressed to a particular JID and sent from a particular JID. XMLDSIG allows for enveloping
|
||||||
that is a signature that signs a data object contained within the &SIGNATURE; element. The
|
signatures, that is a signature that signs a data object contained within the
|
||||||
solution could define an element, such as &XMPPprop; used below, for including properties of
|
&SIGNATURE; element. The solution could define an element, such as &XMPPprop; used
|
||||||
the stanza in the signature. </p>
|
below, for including properties of 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 &SIGNATUREPROPERTIES;
|
address replay attack, as well as other concerns, XMLDSIG defines the
|
||||||
element for including information items about the generation of the Signature, such as the
|
&SIGNATUREPROPERTIES; element for including information items about the generation of
|
||||||
date/time the signature was generated. </p>
|
the Signature, such as the 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 four
|
<p>While one could have &SIGNATURE; which included a &REFERENCE; element for each of
|
||||||
elements discussed above within its &SIGNEDINFO; element, this would require reference
|
four elements discussed above within its &SIGNEDINFO; element, this would require
|
||||||
validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater flexibility over
|
reference validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater
|
||||||
handling of absent references and broken digest values, a &MANIFEST; can be constructed and
|
flexibility over handling of absent references and broken digest values, a &MANIFEST;
|
||||||
only it signed.</p>
|
can be constructed and 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>
|
||||||
@ -485,15 +459,14 @@
|
|||||||
|
|
||||||
<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;, these
|
element. While one could identify signed content by other means, such as &XPointer;,
|
||||||
means would not unambiguously identify the signed content in the face of subsequent stanza
|
these means would not unambiguously identify the signed content in the face of subsequent
|
||||||
modification. </p>
|
stanza 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>
|
||||||
@ -501,35 +474,17 @@
|
|||||||
<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 and a
|
<p>While a simple chat &MESSAGE; typically transits through only one or two XMPP servers
|
||||||
groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza might include
|
and a groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza
|
||||||
far more than four &SIGNATURE; elements.</p>
|
might include far more than four &SIGNATURE; elements.</p>
|
||||||
</section2>
|
</section2>
|
||||||
<section2 topic="Optimistic Signing" anchor="optimistic">
|
<section2 topic="Dual content" anchor="dual">
|
||||||
<p>Some users design the ability to <em>optimistic signing</em> of stanzas. That is, to sign
|
<p>One possible signing solution is for stanzas to carry alternative sets of content, an
|
||||||
all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key
|
unsigned content alternative and a signed content alternative. An entity supporting the
|
||||||
aspect of optimistic signing is that receiving entities not supporting the signing
|
signing extension could make use of the signed content alternative while an entity not
|
||||||
extension should be able to make use the message content (excluding the signature
|
supporting the signing extension could make use of the unsigned content alternative. The
|
||||||
information) while those receiving entities supporting the extension can make use of the
|
following example not only illustrate this approach, but a significant issue with this
|
||||||
message content and the signature information.</p>
|
approach:</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'>
|
||||||
@ -542,46 +497,22 @@
|
|||||||
</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>But it should be obvious that the signed and unsigned contents are not proper
|
<p>Note that the &BODY; element values differ in the two alternatives.</p>
|
||||||
alternatives. The signed content presumedly is what the signer sent. The unsigned content
|
<p>An attacker could alter the unsigned content without alerting entities making use the
|
||||||
is presumedly a modified version of what the signer sent. The modifications are generally
|
signed content.</p>
|
||||||
important to the entity making use of the stanza. In the above example, note that the
|
<p>Instead of treating the signed and unsigned content as alternatives, the solution could
|
||||||
to/from addresses of the signed content differ from the unsigned content. Note as well
|
limit use of the signed content to the validation of the unsigned data. However this
|
||||||
that the unsigned content contains a >delay/< element indicating that the stanza was
|
solution suffers from many same issues encapsulated signatures suffer from, as well as
|
||||||
delayed in transit. Such modifications are generally important to the proper processing of
|
suffering from unnecessary bloat.</p>
|
||||||
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 will
|
<p>While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so
|
||||||
significantly increase the size of the &SIGNATURE; element. As implementations may enforce a
|
will significantly increase the size of the &SIGNATURE; element. As implementations may
|
||||||
maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza signatures should
|
enforce a maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza
|
||||||
be limited.</p>
|
signatures should 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
|
||||||
@ -604,12 +535,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; elements
|
solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE;
|
||||||
to avoid a wide range of attacks. For instance, an attacker could attempt to mount a Denial of
|
elements to avoid a wide range of attacks. For instance, an attacker could attempt to mount a
|
||||||
Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and complex
|
Denial of Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and
|
||||||
content. Or an attacker could attempt to mount a Distributed Denial of Service sending a
|
complex content. Or an attacker could attempt to mount a Distributed Denial of Service sending
|
||||||
message to a chatroom that containing &SIGNATURE; with multiple references to large content
|
a message to a chatroom that containing &SIGNATURE; with multiple references to large
|
||||||
hosted at the attack target in hopes that each room participant will repeated fetch it. A
|
content hosted at the attack target in hopes that each room participant will repeated fetch
|
||||||
&SIGNATURE; element might also contain circler references.</p>
|
it. A &SIGNATURE; element might also contain circler references.</p>
|
||||||
</section1>
|
</section1>
|
||||||
</xep>
|
</xep>
|
||||||
|
|||||||
20
xep-0285.xml
20
xep-0285.xml
@ -26,12 +26,6 @@
|
|||||||
<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>
|
||||||
@ -58,10 +52,8 @@
|
|||||||
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).</p>
|
(along with the CPIM and MSGFMT media types). This document explores the possibility of an
|
||||||
<p>This document explores the possibility of an
|
approach that is similar to but simpler than RFC 3923.</p>
|
||||||
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
|
||||||
@ -216,7 +208,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'>
|
||||||
<!-- original content -->
|
XML-character-data-here
|
||||||
</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'/>
|
||||||
@ -232,9 +224,9 @@
|
|||||||
id='6410ed123'
|
id='6410ed123'
|
||||||
to='juliet@capulet.net/balcony'
|
to='juliet@capulet.net/balcony'
|
||||||
type='error'>
|
type='error'>
|
||||||
<signed xmlns='urn:xmpp:signed:0'>
|
<e2e xmlns='urn:xmpp:signed:0'>
|
||||||
<!-- original content -->
|
XML-character-data-here
|
||||||
</signed>
|
</e2e>
|
||||||
<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'/>
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user