Add initial support for secure binding of labels (digital signatures).
-Extend catalog handling. Minor editorial changes.
-Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog - discovery. Clarify syntax of selector= attribute.
-Update label catalogs to include user input selector.
-Add text regarding default bg/fg colors. Correct examples.
-Reworked discovery and various updates.
-Initial published version.
-Initial draft.
-Extend catalog handling. Minor editorial changes.
Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.
Update label catalogs to include user input selector.
Add text regarding default bg/fg colors. Correct examples.
Reworked discovery and various updates.
Initial published version.
Initial draft.
A security label, sometimes referred to as a confidentiality label, is a structured - representation of the sensitivity of a piece of information. A security label is used in - conjunction with a clearance, a structured representation of what information - sensitivities a person (or other entity) is authorized to access, and a security policy - to control access to each piece of information. For instance, message could be labeled - as "SECRET", and hence requiring the sender and the receiver to have a clearance - granting access to "SECRET" information. &X.841; provides a discussion of security - labels, clearances, and security policy.
-Sensitivity-based authorization is used in networks which operate under a set of - information classification rules, such as in government military agency networks. The - standardized formats for security labels, clearances, and security policy are - generalized and do have application in non-government networks.
-This document describes the use of security labels in &xmpp;. The document specifies how - security label metadata is carried in XMPP. It standardizes a mechanism for carrying ESS - Security Labels in XMPP, as well as provides for use of other label formats. ESS - Security Labels are specified in &rfc2634;. ESS Security Labels are commonly used in - conjunction with &X.500; clearances and either X.841 or &SDN.801c; security - policies.
-A security label, sometimes referred to as a confidentiality label, is + a structured representation of the sensitivity of a piece of information. A security + label is used in conjunction with a clearance, a structured representation of what + information sensitivities a person (or other entity) is authorized to access, and a security + policy to control access to each piece of information. For instance, message could be + labeled as "SECRET", and hence requiring the sender and the receiver to have a + clearance granting access to "SECRET" information. &X.841; provides a discussion of + security labels, clearances, and security policy.
+Sensitivity-based authorization is used in networks which operate under a set of + information classification rules, such as in government military agency networks. The + standardized formats for security labels, clearances, and security policy are + generalized and do have application in non-government networks.
+This document describes the use of security labels in &xmpp;. The document specifies + how security label metadata is carried in XMPP. It standardizes a mechanism for + carrying ESS Security Labels in XMPP, as well as provides for use of other label + formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are + commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c; + security policies.
+Note: The &IC-ISM; label example is for illustrative purposes only.
- -To securely bind the security label to the message, &xep0285; can be used as detailed below.
-The document details when security label metadata should or should not be provided, and - how this metadata is to be processed.
+Note: The &IC-ISM; label example is for illustrative purposes only.
+ +The document details when security label metadata should or should not be provided, and how + this metadata is to be processed.
-This document does not provide: -
This document does not provide: +
If an entity supports the XMPP Security Label protocol, it MUST report that fact by - including a service discovery feature of "urn:xmpp:sec-label:0" in response to - a &xep0030; information request. Clients wishing to include a XMPP Security Label - element in any stanza they generate SHOULD determine if their server supports the XMPP - Security Label protocol. If their server does not support XMPP Security Label, the - client SHOULD NOT generate XMPP Security Labels as the server not supporting this - protocol will generally ignore XMPP Security Labels as they would any other unrecognized - element.
-If an entity supports secure binding of the XMPP Security Label using &xmppdsig;, it MUST - report the fact by including a service discover feature of - "urn:xmpp:sec-label:dsig:0"" 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.
-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.
-If an entity supports the XMPP Security Label protocol, it MUST report that fact + by including a service discovery feature of "urn:xmpp:sec-label:0" in + response to a &xep0030; information request. Clients wishing to include a XMPP + Security Label element in any stanza they generate SHOULD determine if their + server supports the XMPP Security Label protocol. If their server does not + support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels + as the server not supporting this protocol will generally ignore XMPP Security + Labels as they would any other unrecognized element.
+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.
+An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata - includes a security label, zero or more equivalent security labels, and optionally - display marking data.
-An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata + includes a security label, zero or more equivalent security labels, and optionally display + marking data.
+The security label metadata is carried in an &SECURITYLABEL; element. The &SECURITYLABEL; - element which contains one and only one &LABEL; element, zero or more &EQUIVALENTLABEL; - elements, and an optional &DISPLAYMARKING; element.
-The &LABEL; provides the primary security label. It is commonly issued by the sender - under the security policy of that they and their home server operating under. The - &LABEL; contains either a single element representing the primary security label or is - empty to indicate use of a default.
-Each &EQUIVALENTLABEL; represents an equivalent security label under other policies. Each - &EQUIVALENTLABEL; contains a single element representing the equivalent label. This - element might be used when a recepient is known to hold a clearance under a different - policy than the sender.
-The &DISPLAYMARKING; element contains a display string for use by implementations which - are unable to utilize the applicable security policy to generate display markings. The - element may optionally contain two attributes, fgcolor= and bgcolor=, - whose values are HTML color strings (e.g., 'red' or '#ff0000'), for - use in colorizing the display marking. The fgcolor= default is black. - The bgcolor= default is white.
-The security label metadata is carried in an &SECURITYLABEL; element. + The &SECURITYLABEL; element which contains one and only one &LABEL; element, + zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.
+The &LABEL; provides the primary security label. It is commonly issued + by the sender under the security policy of that they and their home + server operating under. The &LABEL; contains either a single element + representing the primary security label or is empty to indicate use of + a default.
+Each &EQUIVALENTLABEL; represents an equivalent security label under + other policies. Each &EQUIVALENTLABEL; contains a single element + representing the equivalent label. This element might be used when + a recepient is known to hold a clearance under a different policy + than the sender.
+The &DISPLAYMARKING; element contains a display string for use by + implementations which are unable to utilize the applicable security policy + to generate display markings. The element may optionally contain two + attributes, fgcolor= and bgcolor=, whose values are HTML + color strings (e.g., 'red' or '#ff0000'), for use in + colorizing the display marking. The fgcolor= default is black. + The bgcolor= default is white. +
+ -A client can request a catalog for a particular JID by sending a catalog discovery - request to the client's server. Where the JID is hosted by some other server, the - client's server is expected to produce a suitable catalog (or fail the request). The - client's server may, as needed, query catalogs from other servers in order to fulfill - the client's request.
-While this specification does not preclude a client from directing a catalog request - elsewhere, it is noted that catalog returned by a party other than its server may not be - directly useable by the client. For instance, the client's server might require a - particular only-locally-known label be used in messages to a particular remote JID.
-It is RECOMMENDED the server publish catalogs of security label for use by clients.
-If catalog is restrictive, as indicated by the restrictive attribute with value of true, - the client SHOULD use one of the labels (or no label) offered by the catalog.
-One and only one of the items may have a default attribute with value of true. The client - should default to this item in cases where the user has not selected an item.
-An item may have no label. Such an item offers a choice of sending a stanza without a - label.
-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.
-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.-
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.
-To indicate the support for label catalog discovery, a server advertises the - urn:xmpp:sec-label:catalog:2 feature. The following pair of examples - illustrates this feature discovery.
-Each item in the catalog may contain a selector attribute. The value of this attribute - represents the item's placement in a hierarchical organization of the items. The value - of the selector attribute conforms to the selector-value ABNF production:
- +A client can request a catalog for a particular JID by sending + a catalog discovery request to the client's server. Where the JID + is hosted by some other server, the client's server is expected to + produce a suitable catalog (or fail the request). The client's server + may, as needed, query catalogs from other servers in order to + fulfill the client's request.
+While this specification does not preclude a client from directing + a catalog request elsewhere, it is noted that catalog returned by + a party other than its server may not be directly useable by the + client. For instance, the client's server might require a particular + only-locally-known label be used in messages to a particular remote + JID.
+It is RECOMMENDED the server publish catalogs of security label + for use by clients.
+If catalog is restrictive, as indicated by the restrictive attribute + with value of true, the client SHOULD use one of the labels + (or no label) offered by the catalog.
+One and only one of the items may have a default attribute with + value of true. The client should default to this item in cases + where the user has not selected an item.
+An item may have no label. Such an item offers a choice of + sending a stanza without a label.
+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.
+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.+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.
+To indicate the support for label catalog discovery, a server + advertises the urn:xmpp:sec-label:catalog:2 feature. + The following pair of examples illustrates this feature discovery.
+Each item in the catalog may contain a selector attribute. The + value of this attribute represents the item's placement in a + hierarchical organization of the items. The value of the selector + attribute conforms to the selector-value ABNF production: +
+"|")*- -- ]]> -
where <item> is a sequence of characters not including "|".
-A value of "X|Y|Z" indicates that this item is "Z" in the the "Y" subset of the "X" - subset of items. This information may be used, for instance, in generating label - selection menus in graphical user interfaces.
-Note: use of unnecessarily deep hierarchies should be avoided.-+ + where <item> is a sequence of characters not including "|".
+A value of "X|Y|Z" indicates that this item is "Z" in the + the "Y" subset of the "X" subset of items. This information may + be used, for instance, in generating label selection menus in + graphical user interfaces.
+Note: use of unnecessarily deep hierarchies should be + avoided.+- ]]> "|")* + +- ]]>
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).
-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).
- -- ]]> - "|")* ]]>
The sensitivity-based access control decisions discussed herein are to be made - independently of other access control decisions or other facilities. That is, the - sensitivity-based access control decisions are not conditional on other factors.
-It is intended that &SECURITYLABEL; elements are only used as prescribed by this - document, or other formal specifications. Any other use of &SECURITYLABEL; SHOULD be - viewed as a protocol violation. The stanza SHOULD be discarded with, if approrpriate, an - error response. Such error responses SHOULD NOT include content from the violating - stanza, excepting that necessary to well-formed error responses.
-When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED. Absence of - a &SECURITYLABEL; element implies the stanza has the default label as specified in the - governing security policy. Given that the governing policy may not specify a default - label, hence denying access to the stanza, supporting clients SHOULD provide a - &SECURITYLABEL; element where prescribed.
-Typically, a client would allow the user to choose populate the &SECURITYLABEL; from one - of from a small set of security labels selections known to it (through configuration - and/or discovery and/or other means), such as from a pull-down menu. That selection - would include appropriate values for the &LABEL;, &DISPLAYMARKING;, and - &EQUIVALENTLABEL; elements.
-A policy-aware client may provide the user with an interface allowing the user to produce - custom labeling data for inclusion in this set. A policy-aware client SHOULD preclude - the user from producing &LABEL; values which the user's own clearance does not grant - access to, and SHOULD preclude sending any label which the user's own clearance does not - grant access to. Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an - equivalent policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the display - marking prescribed for the &LABEL; under the governing policy, or, if the governing - policy prescribes no display marking for the &LABEL;, absent.
-A client which receives a stanza with &SECURITYLABEL; element is to promiently display - the &DISPLAYMARKING; value. A policy-aware may alternatively promiently display the - marking for the &LABEL; prescribed by the governing policy.
-Each server is expected to make a number of sensitivity-based authorization decisions. - Each decision is made by evaluating an Access Control Decision Function (ACDF) with a - governing policy, a clearance, and a security label. The ACDF yields either - Grant or Deny.
-If the user holds a valid clearance (known to the server) under the governing policy, the - clearance input is the user's clearance. Otherwise, if the governing policy provides a - default clearance, the clearance input is the default clearance. Otherwise, the - clearance input is the nil clearance. The nil clearance is a clearance for which the - ACDF always returns Deny when given as the clearance input.
-If the stanza contains a &SECURITYLABEL; element and the either the &LABEL; element or - one of the &EQUIVALENTLABEL; elements contain an appropriate label, that label input is - that label. Otherwise, the label input is the default label provided the governing - policy or, if no default label is provided, the nil label. The nil label is a label for - which the ACDF always returns Deny when given as the label input.
-The term "effective clearance" and "effective label" refer, respectively, to the - clearance and label provided as input to the ACDF.
-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.
-A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.
- -A client may provide a &SECURITYLABEL; element in &MESSAGE; stanzas.
- -A server SHOULD provide a label feature and information discovery for the - room.
-Clients SHOULD discover label feature and information on a per room basis.
-Sending groupchat messages is similiar to sending normal messages, however their - are a few differences.
-Groupchat messages are addressed to the room. The room clearance must be suitable - for the message label, else it should be rejected.
-The room's clearance may allow a variety of labels to be used. Not all partipants - may be cleared for all labels allowed in the room. The server MUST only deliver - messages to partipants for which they are cleared to receive.
-Private messages are treated as discussed in the "Use in Instant Messaging" - section. (Should private messages be restricted by room's configuration?)
-Invitations may be labeled.
-This section discusses semantics of &SECURITYLABEL; elements contained in - &MESSAGE; stanzas containing a &SUBJECT; element.
-The presence of a &SECURITYLABEL; element indicates a request to change the - room's label, either to the provided label or, if the element is empty, to unset - the room's label. The server is to refuse the request if the requestor is not - authorized to change the subject, not cleared for the requested label, or if the - server is otherwise unwilling or unable to make the change. If the label change - is refused, so must the accompanied subject change. Likewise, if the subject - change is refused, so must the accompanied label change.
-Upon change of the room's label, the server MUST immediately remove from the room - all members whom are not cleared for that label.
-In absence of a &SECURITYLABEL; element, the label associated with the room is - unchanged.
-The room's label can also be changed through room configuration (to be discussed - in later revision of this document).
-&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server SHALL treat - any &PRESENCE; stanza that contains a &SECURITYLABEL; as a protocol violation.
-Presence information is subject to sensitivity-base authorization decisions, however - these decisions are made are made using a label associated with the presence - resource, such as a chatroom's label.
-A server SHOULD provide a label feature and information discovery for each - node.
-Clients SHOULD discover label feature and information on a per node basis.
-Each item may be individually labeled.
-&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server + SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a + protocol violation.
+Presence information is subject to sensitivity-base authorization decisions, + however these decisions are made are made using a label associated with the + presence resource, such as a chatroom's label.
+A server SHOULD provide a label feature and information discovery for each node.
+Clients SHOULD discover label feature and information on a per node basis.
+Each item may be individually labeled.
+The service then notifies appropriately cleared subscribers.
-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 - be used to avoid name clashes.
-+ 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 + be used to avoid name clashes. +
+This document is all about authorization, a key aspect of security. Hence, security - considerations are discussed through this document.
-Security labels generally should be securely bound to the object. This may be - accomplished through use of &xmppdsig; as discussed in Appendix A.
-Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject to any - sensitity-based authorization decisions, and may be forwarded throughout the XMPP - network. The content of these stanzas should not contain information requiring - sensitivity-based dissemination controls.
-This document requires no interaction with &IANA;.
-It is requested the ®ISTRAR; add the extension's namespaces and schemas to appropriate - XMPP registries.
-
- This document is all about authorization, a key aspect of security. Hence,
+ security considerations are discussed through this document. Security labels generally should be securely bound to the object. This may be
+ accomplished through use of &xmppe2e; signing, or possibly other signing
+ mechanisms. Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
+ to any sensitity-based authorization decisions, and may be forwarded throughout
+ the XMPP network. The content of these stanzas should not contain information
+ requiring sensitivity-based dissemination controls.
+
This document requires no interaction with &IANA;.
+It is requested the ®ISTRAR; add the extension's namespaces + and schemas to appropriate XMPP registries.
+
+
A copy of this schema is available at
- http://www.xmpp.org/schemas/sec-label.xsd.
-
+
+ A copy of this schema is available at
+
+ http://www.xmpp.org/schemas/sec-label.xsd.
+
+
A copy of this schema is available at
- 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.
+
+
A copy of this schema is available at
- http://www.xmpp.org/schemas/sec-label-ess.xsd.
Update discussions based upon introduction of Digital Signatures in XMPP.
-Initial published version as accepted for publication by the XMPP Council.
-Initial published version as accepted for publication by the XMPP Council.
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 - than forwards the stanza to each subscriber. In basic user presence, the publishing entity - is the user's client and the presence service is presence service is the provided by this - client's server. In this case, the 'to' address is empty.
+ publishing entity sends a &PRESENCE; stanza to a presence service and the presence + service than forwards the stanza to each subscriber. In basic user presence, the publishing + entity is the user's client and the presence service is presence service is the provided by + this client's server. In this case, the 'to' address is empty.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 publisher provided information.
@@ -187,9 +179,8 @@For the purposes of this memo, the following requirements are stipulated for a general - solution:
+For the purposes of this memo, the following requirements are stipulated:
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.
The &IETF; standardized a signing and encryption facility for XMPP known as &xmppe2e;. XMPP - E2E is based upon Secure/Multipurpose Internet Message Extensions (&SMIME;) and the - Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP E2E is intended to be an - end-to-end solution. That is, it enables a sender to sign content sent to a specific - recipient.
+The &IETF; standardized a signing and encryption facility for XMPP known as + &xmppe2e;. XMPP E2E is based upon Secure/Multipurpose Internet Message Extensions + (&SMIME;) and the Cryptographic Message Syntax (&CMS;). As it's name implies, XMPP + E2E is intended to be an end-to-end solution. That is, it enables a sender to sign content + sent to a specific recipient.
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 disadvantage is that implementations which do not support XMPP E2E cannot make use of the @@ -243,15 +226,6 @@
At the time of this writing, XMPP E2E has not been widely implemented. XMPP E2E appears to have limited applicability.
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 optimistic signing.
-At the time of this writing, XMPP DSIG was just introduced.
- -Alternative approaches have been developed. For instance, the Cross Domain Collaborative
Information Environment (&CDCIE;) Client Chat Protocol (&CDCIE-CCP;), an XMPP-based
@@ -271,8 +245,8 @@
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
- signature syntax in encapsulated within the structure of the signed content. XMPP E2E and
- XMPP DSIG are examples of the former. CDCIE-CCP is an example of the latter.
The following example illustrates, using pseudo language, an encapsulating signature over a &MESSAGE; stanza.
@@ -311,13 +285,13 @@ ]]> -Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E and - XMPP DSIG, are generally limited to end-to-end use cases. That is, cases where the - originator of a stanza signs the stanza and send it through the XMPP network to its intended - recipient, and only the intended recipient is expected to make use of the signed content. - Entities between the signer and the intended recipient are expected to forward of the stanza - without regard to the encapsulating signature, and without themselves signing the stanza. - The approach does not require forwarding entities to support the signing extension.
+Applicability of a simple (non-nesting) encapsulating signatures, such as in XMPP E2E, are + generally limited to end-to-end use cases. That is, cases where the originator of a stanza + signs the stanza and send it through the XMPP network to its intended recipient, and only + the intended recipient is expected to make use of the signed content. Entities between the + signer and the intended recipient are expected to forward of the stanza without regard to + the encapsulating signature, and without themselves signing the stanza. The approach does + not require forwarding entities to support the signing extension.
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 and the service can sign reflected stanzas to occupants. In providing non-anonymous chat @@ -408,32 +382,32 @@ ]]>
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 - required to replace the 'to' attribute with the full JID of the romeo@example.net client it - intends to forward the message to. These alternatations will "break" the signature.
+ &MESSAGE; element before forwarding it to the example.net server. The example.net server + is required to replace the 'to' attribute with the full JID of the romeo@example.net client + it intends to forward the message to. These alternatations will "break" the signature.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 - not cover key aspects of the stanza, such that it was a chat &MESSAGE; addressed to a - particular JID and sent from a particular JID. XMLDSIG allows for enveloping signatures, - that is a signature that signs a data object contained within the &SIGNATURE; element. The - solution could define an element, such as &XMPPprop; used below, for including properties of - the stanza in the signature.
+ could sign the &SUBJECT; and &BODY; element and their content. However, this by + itself would not cover key aspects of the stanza, such that it was a chat &MESSAGE; + addressed to a particular JID and sent from a particular JID. XMLDSIG allows for enveloping + signatures, that is a signature that signs a data object contained within the + &SIGNATURE; element. The solution could define an element, such as &XMPPprop; used + below, for including properties of the stanza in the signature.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; - element for including information items about the generation of the Signature, such as the - date/time the signature was generated.
+ address replay attack, as well as other concerns, XMLDSIG defines the + &SIGNATUREPROPERTIES; element for including information items about the generation of + the Signature, such as the date/time the signature was generated.While one could have &SIGNATURE; which included a &REFERENCE; element for each of four - elements discussed above within its &SIGNEDINFO; element, this would require reference - validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater flexibility over - handling of absent references and broken digest values, a &MANIFEST; can be constructed and - only it signed.
+While one could have &SIGNATURE; which included a &REFERENCE; element for each of + four elements discussed above within its &SIGNEDINFO; element, this would require + reference validation for each &REFERENCE; (See 2.3 of XMLDSIG). To provide greater + flexibility over handling of absent references and broken digest values, a &MANIFEST; + can be constructed and only it signed.
Putting all of the above together, the client might send the following signed stanza:
@@ -485,15 +459,14 @@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 - element. While one could identify signed content by other means, such as &XPointer;, these - means would not unambiguously identify the signed content in the face of subsequent stanza - modification.
+ element. While one could identify signed content by other means, such as &XPointer;, + these means would not unambiguously identify the signed content in the face of subsequent + stanza modification.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 regardless of what stanza content it might sign.
Multiple entities can sign a stanza. A single entity may sign a stanza multiple times, typically on different occasions.
@@ -501,36 +474,18 @@Each signer simply adds their &SIGNATURE; element to the stanza, typically as the last element. A &SIGNATURE; may sign other signatures, or portions thereof.
-While a simple chat &MESSAGE; typically transits through only one or two XMPP servers and a - groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza might include - far more than four &SIGNATURE; elements.
+While a simple chat &MESSAGE; typically transits through only one or two XMPP servers + and a groupchat &MESSAGE; may typically transits one to three XMPP servers, a stanza + might include far more than four &SIGNATURE; elements.
Some users design the ability to optimistic signing of stanzas. That is, to sign - all stanzas adhere to a configured criteria, such as all &MESSAGE; stanzas, they send. A key - aspect of optimistic signing is that receiving entities not supporting the signing - extension should be able to make use the message content (excluding the signature - information) while those receiving entities supporting the extension can make use of the - message content and the signature information.
-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.
-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.
-One possible optimistic signing solution is for stanzas to carry alternative 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.
-The following example not only illustrate this approach, but highlights some of the - issues with this approach:
-One possible signing solution is for stanzas to carry alternative sets of content, an + unsigned content alternative and a signed content alternative. 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 + following example not only illustrate this approach, but a significant issue with this + approach:
+But it should be obvious that the signed and unsigned contents are not proper - alternatives. The signed content presumedly is what the signer sent. The unsigned content - is presumedly a modified version of what the signer sent. The modifications are generally - important to the entity making use of the stanza. In the above example, note that the - to/from addresses of the signed content differ from the unsigned content. Note as well - that the unsigned content contains a >delay/< element indicating that the stanza was - 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.
-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.
-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.
-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.
-Dual content approaches should be avoided.
-Note that the &BODY; element values differ in the two alternatives.
+An attacker could alter the unsigned content without alerting entities making use the + signed content.
+Instead of treating the signed and unsigned content as alternatives, the solution could + limit use of the signed content to the validation of the unsigned data. However this + solution suffers from many same issues encapsulated signatures suffer from, as well as + suffering from unnecessary bloat.
+Dual content approaches should be avoided.
While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so will - significantly increase the size of the &SIGNATURE; element. As implementations may enforce a - maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza signatures should - be limited.
+While a signer may provide a &KEYINFO; element within the &SIGNATURE;, doing so + will significantly increase the size of the &SIGNATURE; element. As implementations may + enforce a maximum stanza size as small as 10,000 bytes, use of &KEYINFO; in stanza + signatures should be limited.
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.
There are a number of ways key information may be published, such as in user's vCard. Key @@ -604,12 +535,12 @@
Designers of the solution should be mind full of security considerations discussed in XMLDSIG (regardless of whether XMLDSIG is used in the solution)
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 - to avoid a wide range of attacks. For instance, an attacker could attempt to mount a Denial of - Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and complex - content. Or an attacker could attempt to mount a Distributed Denial of Service sending a - message to a chatroom that containing &SIGNATURE; with multiple references to large content - hosted at the attack target in hopes that each room participant will repeated fetch it. A - &SIGNATURE; element might also contain circler references.
+ solution. Implementations need to take special care in processing XMLDSIG &SIGNATURE; + elements to avoid a wide range of attacks. For instance, an attacker could attempt to mount a + Denial of Service attack by sending a &SIGNATURE; purporting to sign arbitrary large and + complex content. Or an attacker could attempt to mount a Distributed Denial of Service sending + a message to a chatroom that containing &SIGNATURE; with multiple references to large + content hosted at the attack target in hopes that each room participant will repeated fetch + it. A &SIGNATURE; element might also contain circler references.Minor changes (editorial, cleanup, etc.).
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 optimistic signing.
+ (along with the CPIM and MSGFMT media types). This document explores the possibility of an + approach that is similar to but simpler than RFC 3923.The process that a sending agent follows for securing stanzas is very similar regardless of
@@ -216,7 +208,7 @@
to='juliet@capulet.net/balcony'
type='error'>