From 958bdd5bb438fbebd7fd00b927a956317336560d Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Tue, 9 Nov 2010 14:29:31 -0800 Subject: [PATCH] misc updates --- xep-0258.xml | 91 ++++++++++++++++++++++++++-------------------------- 1 file changed, 45 insertions(+), 46 deletions(-) diff --git a/xep-0258.xml b/xep-0258.xml index 3fabd2fe..b9f6239b 100644 --- a/xep-0258.xml +++ b/xep-0258.xml @@ -36,6 +36,12 @@ Kurt.Zeilenga@Isode.COM Kurt.Zeilenga@Isode.COM + + 0.7 + 2010-11-09 + kdz +

Illustrate XEP 45 security label room configuration. Make clarifications and m inor editorial changes.

 + 0.6 2010-07-30 @@ -86,11 +92,11 @@ label is used in conjunction with a clearance, a structured representation of what information sensitivities a person (or other entity) is authorized to access, and a security policy to control access to each piece of information. For instance, message could be - labeled as "SECRET", and hence requiring the sender and the receiver to have a + labeled as "SECRET", and hence requiring the sender and the receiver to each have a clearance granting access to "SECRET" information. &X.841; provides a discussion of security labels, clearances, and security policy.

Sensitivity-based authorization is used in networks which operate under a set of - information classification rules, such as in government military agency networks. The + information classification rules, such as in government agency networks. The standardized formats for security labels, clearances, and security policy are generalized and do have application in non-government networks.

This document describes the use of security labels in &xmpp;. The document specifies @@ -125,7 +131,7 @@

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:

Such mechanisms may be introduced in subsequent documents.

+ +

This document does discuss how one might securely bind a security label to a stanza. + It is expected a subsequent document will tackle this topic.

-

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.

+

An entity (client or server) which supports the XMPP Security Label protocol + 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.

@@ -170,10 +179,6 @@ ]]> - @@ -234,12 +239,12 @@ 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 +

If catalog is restrictive, as indicated by the restrict attribute with value of true, the client SHOULD use one of the labels (or no label) offered by the catalog.

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.

+ value of true. The client should default the label selection 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 @@ -258,9 +263,10 @@

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 +

Items in the catalog may contain a selector attribute. The value of this attribute represents the item's placement in a - hierarchical organization of the items. The value of the selector + hierarchical organization of the items. If one item has a selector + attribute, all items should have a selector item. The value of the selector attribute conforms to the selector-value ABNF production:

"|")* avoided.
@@ -298,7 +305,7 @@ selector-value = ("|")*

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).

+ ]]> @@ -308,7 +315,7 @@ selector-value = ("|")* + restrict='false'> SECRET @@ -327,7 +334,7 @@ selector-value = ("|")* - + RESTRICTED - + ]]> + @@ -455,12 +463,12 @@ selector-value = ("|")*

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 @@ -630,13 +629,14 @@ And by opposing end them?

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.

+

It is desirable to securely bind the security label to the object it labels. + This may be accomplished through use of digital signatures. Specification of such + is left to a future document. +

This document requires no interaction with &IANA;.

@@ -803,7 +803,6 @@ And by opposing end them? - User input selector @@ -812,7 +811,7 @@ And by opposing end them? - Default Item + default selection