diff --git a/xep-0258.xml b/xep-0258.xml index db00aa71..3fabd2fe 100644 --- a/xep-0258.xml +++ b/xep-0258.xml @@ -12,113 +12,94 @@ ]> -
- Security Labels in XMPP - This document describes the use of security labels in XMPP. The document specifies - how security label metadata is carried in XMPP, when this metadata should or should not - be provided, and how the metadata is to be processed. - &LEGALNOTICE; - 0258 - Experimental - Standards Track - Standards - Council - - XMPP Core - XEP-0001 - XEP-0285 - - - - sec-label - &kdz; - - 0.7 - 2010-09-29 - kdz - -

Add initial support for secure binding of labels (digital signatures).

- - - - 0.6 - 2010-07-30 - kdz - -

Extend catalog handling. Minor editorial changes.

- - - - 0.5 - 2009-07-27 - kdz - -

Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog - discovery. Clarify syntax of selector= attribute.

- - - - 0.4 - 2009-07-23 - kdz - -

Update label catalogs to include user input selector.

- - - - 0.3 - 2009-03-20 - kdz - -

Add text regarding default bg/fg colors. Correct examples.

- - - - 0.2 - 2009-03-10 - kdz - -

Reworked discovery and various updates.

- - - - 0.1 - 2009-01-05 - psa - -

Initial published version.

- - - - 0.0.081203 - 2008-12-03 - kdz - -

Initial draft.

- - -
+
+ Security Labels in XMPP + This document describes the use of security labels in XMPP. The document + specifies how security label metadata is carried in XMPP, when this metadata + should or should not be provided, and how the metadata is to be processed. + &LEGALNOTICE; + 0258 + Experimental + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + + + + sec-label + + Kurt + Zeilenga + Kurt.Zeilenga@Isode.COM + Kurt.Zeilenga@Isode.COM + + + 0.6 + 2010-07-30 + kdz +

Extend catalog handling. Minor editorial changes.

 + + + 0.5 + 2009-07-27 + kdz +

Remove &LABEL;/&EQUIVALENTLABEL; type= attribute. Clarify label catalog discovery. Clarify syntax of selector= attribute.

 + + + 0.4 + 2009-07-23 + kdz +

Update label catalogs to include user input selector.

 + + + 0.3 + 2009-03-20 + kdz +

Add text regarding default bg/fg colors. Correct examples.

 + + + 0.2 + 2009-03-10 + kdz +

Reworked discovery and various updates.

 + + + 0.1 + 2009-01-05 + psa +

Initial published version.

 + + + 0.0.081203 + 2008-12-03 + kdz +

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.

+ This content is classified. @@ -129,7 +110,7 @@ ]]> - This content is classified. @@ -139,67 +120,37 @@ ]]> -

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.

- - - To-be-computed - - - PG1lc3NhZ2UgdG89J3JvbWVvQGV4YW1wbGUubmV0JyBmcm9tPSdqdWxpZXRAZXhhbXBsZS5jb20v - YmFsY29ueSc+CiAgICA8Ym9keT5UaGlzIGNvbnRlbnQgaXMgY2xhc3NpZmllZC48L2JvZHk+CiAg - ICA8c2VjdXJpdHlsYWJlbCB4bWxucz0ndXJuOnhtcHA6c2VjLWxhYmVsOjAnPgogICAgICAgIDxk - aXNwbGF5bWFya2luZyBmZ2NvbG9yPSdibGFjaycgYmdjb2xvcj0ncmVkJz5TRUNSRVQ8L2Rpc3Bs - YXltYXJraW5nPgogICAgICAgIDxsYWJlbD48aWNpc21sYWJlbCB4bWxucz0naHR0cDovL2V4YW1w - bGUuZ292L0lDLUlTTS8wJyBjbGFzc2lmaWNhdGlvbj0nUycKICAgICAgICAgICAgb3duZXJQcm9k - dWNlcj0nVVNBJy8+PC9sYWJlbD4KICAgIDwvc2VjdXJpdHlsYWJlbD4KPC9tZXNzYWdlPgo= - - - ]]> - - -

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: -

    -
  • any mechanism for a client might discover the security policy enforce at its - home server, or any other server;
    • -
  • any mechanism for a client to discover the user's clearance, or the clearance of - associated with any resource; nor
    • -
  • any administrative mechanism for a client to configure configure policy, - clearance, and labels of any resource.
    • -
- Such mechanisms may be introduced in subsequent documents.

- +

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.

+ This content is classified. @@ -246,77 +196,93 @@ ]]> -

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.

- The service then notifies appropriately cleared subscribers.

+ @@ -637,42 +610,45 @@ And by opposing end them? ]]> - - - + + + - -

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.

+ + + +

+ @@ -769,13 +745,16 @@ And by opposing end them? - ]]> 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. +

+ + +

+ @@ -885,9 +867,12 @@ And by opposing end them? - ]]> A copy of this schema is available at - http://www.xmpp.org/schemas/sec-label-ess.xsd.

- - + ]]> + + A copy of this schema is available at + + http://www.xmpp.org/schemas/sec-label-ess.xsd. +

+ +