[jdev] Authentication Process For Jabber.com

[Peter Saint-Andre]

On 03/10/2008 10:44 AM, Justin Karneges wrote:
> On Monday 10 March 2008 2:01 am, Sergei Golovan wrote:
>> On 3/10/08, Justin Karneges <justin-keyword-jabber.093179 at affinix.com> 
> wrote:
>>>  Further, since some XML parsers throw error when an unrecognized prefix
>>> is encountered, those clients/servers would most likely respond not with
>>> a stanza error, but with an xml-not-well-formed *stream* error and close
>>> the connection.
>>>
>>>  I think we have to be very careful about how this stuff is routed. 
>>> Obviously clients shouldn't be generating invalid XML, but servers
>>> shouldn't be routing it either.  A good server would disconnect whoever
>>> sent gajim:die rather than routing it and DoS'ing other clients.
>> I would like to see (probably in a separate section) rules for closing
>> streams like the following:
>>
>> 1) If an entity sends non-well-formed XML as defined in
>> http://www.w3.org/TR/2006/REC-xml-20060816 then the receiving entity
>> MUST close the stream and return xml-not-well-formed error.
>>
>> 2) If an entity sends namespace-non-well-formed XML as defined in
>> http://www.w3.org/TR/REC-xml-names then the receiving entity MUST
>> close the stream and return xml-not-well-formed error (or may be it's
>> better to introduce a separate error for this case).

Thanks to Sergei for the suggestions.

I've added a section on well-formedness to rfc3920bis and I have
included these two rules. The section reads as follows in my working copy:

   A XMPP entity MUST NOT accept XML data from another entity if that
   data is not well-formed in accordance with both the definition of
   "well-formed" in Section 2.1 of [XML] and the definition of
   "namespace-well-formed" in Section 7 of [XML‑NAMES]. If an XMPP
   entity receives XML data that is not so well-formed, it MUST return
   an <xml-not-well-formed/> stream error and close the stream over
   which the data was sent.

>> 3) IF an entity defines XMLNS prefix in a stream header and use it in
>> a stanza (which means that the stanza isn't routable as is) then the
>> receiving entity MAY close the stream and return xml-non-well-formed
>> error, but SHOULD move namespace definition to a stanza level (or
>> convert namespace prefix into xmlns attribute) and process the stanza.
>>
>> (The third rule is arguable though.) 

Yes I think this is quite arguable. This would require the receiving
entity to remember all prefixes and apply them as necessary, which seems
like an unnecessary burden.

Our existing text from the "Extended Namespaces" section says:

   An implementation SHOULD NOT generate namespace prefixes for elements
   qualified by content (as opposed to stream) namespaces other than the
   default namespace. However, if included, the namespace declarations
   for those prefixes MUST be included on the stanza root or a child
   thereof, not at the level of the stream element (this helps to ensure
   that any such namespace declaration is routed and delivered with the
   stanza, instead of assumed from the stream).

>> These rules ensure
>> namespace-well-formedness of XMPP streams, and no custom XML parsers
>> will be necessary to parse XMPP streams. Currently, general XML
>> parsers either ignore namespace prefixes at all (which means that
>> clients using them will loose some data) or break on unbound prefixes
>> (which means disconnections on <gajim:die/>).

That is a laudable goal. Do you think we achieve the goal with the
well-formedness text above, plus the existing rule regarding extended
namespaces?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20080530/a5fd0412/attachment-0002.bin>