diff --git a/xep-0115.xml b/xep-0115.xml index 41c3a65e..6b378223 100644 --- a/xep-0115.xml +++ b/xep-0115.xml @@ -221,7 +221,7 @@

The protocol defined herein addresses the following requirements:

-
    +
    1. Clients must be able to participate even if they support only &xmppcore;, &xmppim;, and XEP-0030.
    2. Clients must be able to participate even if they are on networks without connectivity to other XMPP servers, services offering specialized XMPP extensions, or HTTP servers.These first two requirements effectively eliminated XEP-0060 as a possible implementation of entity capabilities.
    3. Clients must be able to retrieve information without querying every entity with which they communicate.
      4. @@ -270,7 +270,7 @@

      In order to help prevent poisoning of entity capabilities information, the value of the verification string MUST be generated according to the following method.

      Note: All sorting operations MUST be performed using "i;octet" collation as specified in Section 9.3 of &rfc4790;.

      -
        +
        1. Initialize an empty string S.
        2. Sort the service discovery identities A registry of service discovery identities is located at &DISCOCATEGORIES;. by category and then by type and then by xml:lang (if it exists), formatted as CATEGORY '/' [TYPE] '/' [LANG] '/' [NAME]. Note that each slash is included even if the TYPE, LANG, or NAME is not included.
        3. For each identity, append the 'category/type/lang/name' to S, followed by the '<' character.
          4. @@ -278,11 +278,11 @@
        4. For each feature, append the feature to S, followed by the '<' character.
        5. If the service discovery information response includes XEP-0128 data forms, sort the forms by the FORM_TYPE (i.e., by the XML character data of the <value/> element).
        6. For each extended service discovery information form: -
            +
            1. Append the XML character data of the FORM_TYPE field's <value/> element, followed by the '<' character.
            2. Sort the fields by the value of the "var" attribute.
            3. For each field: -
                +
                1. Append the value of the "var" attribute, followed by the '<' character.
                2. Sort values by the XML character data of the <value/> element.
                3. For each <value/> element, append the XML character data, followed by the '<' character.
                  4. @@ -295,14 +295,27 @@
                -

                Consider an entity whose category is "client", whose service discovery type is "pc", whose service discovery name is "Exodus 0.9.1", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorithm, the verification string would be generated as follows:

                -
                  -
                1. S = ''
                  2. -
                2. Only one identity: "client/pc"
                  3. -
                3. S = 'client/pc//Exodus 0.9.1<'
                  4. -
                4. Sort the features: "http://jabber.org/protocol/caps", "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".
                  5. -
                5. S = 'client/pc//Exodus 0.9.1<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'
                  6. -
                6. ver = QgayPKawpkPSDYmwT/WM94uAlu0=
                  7. +

                  Consider an entity whose category is "client", whose service discovery type is "pc", whose service discovery name is "Exodus 0.9.1", and whose supported features are "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", and "http://jabber.org/protocol/muc". Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):

                  +
                    +
                  1. +

                    S = ''

                    +
                    2. +
                  2. +

                    Only one identity: "client/pc"

                    +
                    3. +
                  3. +

                    S = 'client/pc//Exodus 0.9.1<'

                    +
                    4. +
                  4. +

                    Sort the features: "http://jabber.org/protocol/caps", "http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".

                    +
                    5. +
                  5. +

                    S = 'client/pc//Exodus 0.9.1<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< +
                    http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'

                    +
                    6. +
                  6. +

                    ver = QgayPKawpkPSDYmwT/WM94uAlu0=

                    +
                  @@ -345,33 +358,58 @@ </iq>

                  Using the SHA-1 algorithm, the verification string would be generated as follows (note: line breaks in the verification string are included only for the purposes of readability):

                  -
                    -
                  1. S = ''
                    2. -
                  2. Two identities: "client/pc/Psi" and "client/pc/Ψ"
                    3. -
                  3. S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<'
                    4. -
                  4. Sort the features: "http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".
                    5. -
                  5. S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info -
                    <http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc'.
                    6. -
                  6. Sort the extended service discovery forms by FORM_TYPE (there is only one: "urn:xmpp:dataforms:softwareinfo").
                    7. -
                  7. S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<'
                    8. -
                  8. Sort the fields by var and append the value(s): "ip_version<ipv4<ipv6", "os<Mac", "os_version<10.5.1", "software<Psi", "software_version<0.11".
                    9. -
                  9. S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info<http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<ip_version<ipv4<ipv6<os<Mac<os_version<10.5.1<software<Psi<software_version<0.11<'
                    10. -
                  10. ver = q07IKJEyjvHSyhy//CH0CxmKi8w=
                    11. +
                      +
                    1. +

                      S = ''

                      +
                      2. +
                    2. +

                      Two identities: "client/pc/Psi" and "client/pc/Ψ"

                      +
                      3. +
                    3. +

                      S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<'

                      +
                      4. +
                    4. +

                      Sort the features: "http://jabber.org/protocol/caps", http://jabber.org/protocol/disco#info", "http://jabber.org/protocol/disco#items", "http://jabber.org/protocol/muc".

                      +
                      5. +
                    5. +

                      + S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< +
                      http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<'. +

                      +
                      6. +
                    6. +

                      Sort the extended service discovery forms by FORM_TYPE (there is only one: "urn:xmpp:dataforms:softwareinfo").

                      +
                      7. +
                    7. +

                      S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< +
                      http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo<'

                      +
                      8. +
                    8. +

                      Sort the fields by var and append the value(s): "ip_version<ipv4<ipv6", "os<Mac", "os_version<10.5.1", "software<Psi", "software_version<0.11".

                      +
                      9. +
                    9. +

                      S = 'client/pc/el/Ψ 0.11<client/pc/en/Psi 0.11<http://jabber.org/protocol/caps<http://jabber.org/protocol/disco#info< +
                      http://jabber.org/protocol/disco#items<http://jabber.org/protocol/muc<urn:xmpp:dataforms:softwareinfo< +
                      ip_version<ipv4<ipv6<os<Mac<os_version<10.5.1<software<Psi<software_version<0.11<'

                      +
                      10. +
                    10. +

                      ver = q07IKJEyjvHSyhy//CH0CxmKi8w=

                      +

                    When an entity receives a value of the 'ver' attribute that appears to be a verification string generated in accordance with the generation method defined in this specification, it MUST process the 'ver' according to the following method.

                    -
                      +
                      1. Verify that the <c/> element includes a 'hash' attribute. If it does not, ignore the 'ver' or treat it as generated in accordance with the Legacy Format (if supported).
                      2. If the value of the 'hash' attribute does not match one of the processing application's supported hash functions, do the following: -
                          +
                          1. Send a service discovery information request to the generating entity.
                          2. Receive a service discovery information response from the generating entity.
                          3. Do not validate or globally cache the verification string as described below; instead, the processing application SHOULD associate the discovered identity+features only with the JabberID of the generating entity.
                        1. If the value of the 'hash' attribute matches one of the processing application's supported hash functions, validate the verification string by doing the following: -
                            +
                            1. Send a service discovery information request to the generating entity.
                            2. Receive a service discovery information response from the generating entity.
                            3. If the response includes more than one service discovery identity with the same category/type/lang/name, consider the entire response to be ill-formed.
                              4. @@ -538,7 +576,7 @@
                            4. Given knowledge of a particular value S used as the input message to the hash function, an attacker can find a value S' that yields V (this is known as a "second preimage attack").

                              5. In practice, a preimage attack would need to meet all of the following criteria in order to be effective against the entity capabilities protocol:

                              -
                                +
                                1. The hashing algorithm used would need to be found not only theoretically but practically vulnerable to first or second preimage attacks (e.g., this is not yet true of the MD5 or SHA-1 algorithms, but may become true in the future).
                                2. An attacker would need to find an input message X or S' that matches the hash V for a particular value of V or S, which may not be practical given that (a) the values of S used as input to the hash function in entity capabilities are relatively short and (b) cryptanalysis to date indicates that existing hash functions may not be vulnerable to preimage attacks except in the case of relatively long input messages (on the order of 255 blocks).
                                3. The input message X or S' would need to conform to the structure of S as specified under Verification String, including the order of service discovery identity or identities followed by service discovery features, delimited by the '<' character and sorted using "i;octet" collation.