DJabberd
view release on metacpan or search on metacpan
doc/rfc3920-notes.txt view on Meta::CPAN
advertises a list of available SASL authentication mechanisms;
each of these is a <mechanism/> element included as a child
within a <mechanisms/> container element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a
child of a <features/> element in the streams namespace. If Use
of TLS (Section 5) needs to be established before a particular
Saint-Andre, Ed. Standards Track [Page 28]
RFC 3920 XMPP Core October 2004
authentication mechanism may be used, the receiving entity MUST
NOT provide that mechanism in the list of available SASL
authentication mechanisms prior to TLS negotiation. If the
initiating entity presents a valid certificate during prior TLS
negotiation, the receiving entity SHOULD offer the SASL EXTERNAL
mechanism to the initiating entity during SASL negotiation (refer
to [SASL]), although the EXTERNAL mechanism MAY be offered under
other circumstances as well.
3. The initiating entity selects a mechanism by sending an <auth/>
element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity and including an appropriate
value for the 'mechanism' attribute. This element MAY contain
XML character data (in SASL terminology, the "initial response")
if the mechanism supports or requires it; if the initiating
entity needs to send a zero-length initial response, it MUST
transmit the response as a single equals sign ("="), which
indicates that the response is present but contains no data.
4. If necessary, the receiving entity challenges the initiating
entity by sending a <challenge/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity; this element MAY contain XML character data (which MUST
be computed in accordance with the definition of the SASL
mechanism chosen by the initiating entity).
5. The initiating entity responds to the challenge by sending a
<response/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving
entity; this element MAY contain XML character data (which MUST
be computed in accordance with the definition of the SASL
mechanism chosen by the initiating entity).
6. If necessary, the receiving entity sends more challenges and the
initiating entity sends more responses.
This series of challenge/response pairs continues until one of three
things happens:
1. The initiating entity aborts the handshake by sending an <abort/>
element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl'
namespace to the receiving entity. Upon receiving an <abort/>
element, the receiving entity SHOULD allow a configurable but
reasonable number of retries (at least 2), after which it MUST
terminate the TCP connection; this enables the initiating entity
(e.g., an end-user client) to tolerate incorrectly-provided
credentials (e.g., a mistyped password) without being forced to
reconnect.
Saint-Andre, Ed. Standards Track [Page 29]
RFC 3920 XMPP Core October 2004
2. The receiving entity reports failure of the handshake by sending
a <failure/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity (the particular cause of failure SHOULD be communicated in
an appropriate child element of the <failure/> element as defined
under SASL Errors (Section 6.4)). If the failure case occurs,
the receiving entity SHOULD allow a configurable but reasonable
number of retries (at least 2), after which it MUST terminate the
TCP connection; this enables the initiating entity (e.g., an
end-user client) to tolerate incorrectly-provided credentials
(e.g., a mistyped password) without being forced to reconnect.
3. The receiving entity reports success of the handshake by sending
a <success/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating
entity; this element MAY contain XML character data (in SASL
terminology, "additional data with success") if required by the
chosen SASL mechanism. Upon receiving the <success/> element,
the initiating entity MUST initiate a new stream by sending an
opening XML stream header to the receiving entity (it is not
necessary to send a closing </stream> tag first, since the
receiving entity and initiating entity MUST consider the original
stream to be closed upon sending or receiving the <success/>
element). Upon receiving the new stream header from the
initiating entity, the receiving entity MUST respond by sending a
new XML stream header to the initiating entity, along with any
available features (but not including the STARTTLS and SASL
features) or an empty <features/> element (to signify that no
additional features are available); any such additional features
not defined herein MUST be defined by the relevant extension to
XMPP.
6.3. SASL Definition
The profiling requirements of [SASL] require that the following
information be supplied by a protocol definition:
service name: "xmpp" {=sasl-service-name}
initiation sequence: After the initiating entity provides an opening
XML stream header and the receiving entity replies in kind, the
receiving entity provides a list of acceptable authentication
methods. The initiating entity chooses one method from the list
and sends it to the receiving entity as the value of the
'mechanism' attribute possessed by an <auth/> element, optionally
including an initial response to avoid a round trip.
Saint-Andre, Ed. Standards Track [Page 30]
RFC 3920 XMPP Core October 2004
exchange sequence: Challenges and responses are carried through the
exchange of <challenge/> elements from receiving entity to
initiating entity and <response/> elements from initiating entity
to receiving entity. The receiving entity reports failure by
sending a <failure/> element and success by sending a <success/>
element; the initiating entity aborts the exchange by sending an
<abort/> element. Upon successful negotiation, both sides
consider the original XML stream to be closed and new stream
headers are sent by both entities.
security layer negotiation: The security layer takes effect
immediately after sending the closing ">" character of the
<success/> element for the receiving entity, and immediately after
receiving the closing ">" character of the <success/> element for
the initiating entity. The order of layers is first [TCP], then
[TLS], then [SASL], then XMPP.
use of the authorization identity: The authorization identity may be
used by xmpp to denote the non-default <node@domain> of a client
or the sending <domain> of a server.
6.4. SASL Errors
The following SASL-related error conditions are defined:
{=sasl-error-types}
o <aborted/> -- The receiving entity acknowledges an <abort/>
element sent by the initiating entity; sent in reply to the
<abort/> element.
o <incorrect-encoding/> -- The data provided by the initiating
entity could not be processed because the [BASE64] encoding is
incorrect (e.g., because the encoding does not adhere to the
definition in Section 3 of [BASE64]); sent in reply to a
<response/> element or an <auth/> element with initial response
data.
o <invalid-authzid/> -- The authzid provided by the initiating
entity is invalid, either because it is incorrectly formatted or
because the initiating entity does not have permissions to
authorize that ID; sent in reply to a <response/> element or an
<auth/> element with initial response data.
o <invalid-mechanism/> -- The initiating entity did not provide a
mechanism or requested a mechanism that is not supported by the
receiving entity; sent in reply to an <auth/> element.
Saint-Andre, Ed. Standards Track [Page 31]
RFC 3920 XMPP Core October 2004
o <mechanism-too-weak/> -- The mechanism requested by the initiating
entity is weaker than server policy permits for that initiating
entity; sent in reply to a <response/> element or an <auth/>
element with initial response data.
o <not-authorized/> -- The authentication failed because the
initiating entity did not provide valid credentials (this includes
but is not limited to the case of an unknown username); sent in
reply to a <response/> element or an <auth/> element with initial
response data.
o <temporary-auth-failure/> -- The authentication failed because of
a temporary error condition within the receiving entity; sent in
reply to an <auth/> element or <response/> element.
6.5. Client-to-Server Example
The following example shows the data flow for a client authenticating
with a server using SASL, normally after successful TLS negotiation
(note: the alternate steps shown below are provided to illustrate the
protocol for failure cases; they are not exhaustive and would not
necessarily be triggered by the data sent in the example).
Step 1: Client initiates stream to server:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
to='example.com'
version='1.0'>
Step 2: Server responds with a stream tag sent to client:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_234'
from='example.com'
version='1.0'>
Step 3: Server informs client of available authentication mechanisms:
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
Saint-Andre, Ed. Standards Track [Page 32]
RFC 3920 XMPP Core October 2004
Step 4: Client selects an authentication mechanism:
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'/>
Step 5: Server sends a [BASE64] encoded challenge to client:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>
doc/rfc3920-notes.txt view on Meta::CPAN
The following rules apply to stanza-related errors:
o The receiving or processing entity that detects an error condition
in relation to a stanza MUST return to the sending entity a stanza
of the same kind (message, presence, or IQ), whose 'type'
attribute is set to a value of "error" (such a stanza is called an
"error stanza" herein).
o The entity that generates an error stanza SHOULD include the
original XML sent so that the sender can inspect and, if
necessary, correct the XML before attempting to resend.
o An error stanza MUST contain an <error/> child element.
o An <error/> child MUST NOT be included if the 'type' attribute has
a value other than "error" (or if there is no 'type' attribute).
o An entity that receives an error stanza MUST NOT respond to the
stanza with a further error stanza; this helps to prevent looping.
Saint-Andre, Ed. Standards Track [Page 53]
RFC 3920 XMPP Core October 2004
9.3.2. Syntax
The syntax for stanza-related errors is as follows:
<stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here]
<error type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</error>
</stanza-kind>
The stanza-kind is one of message, presence, or iq.
The value of the <error/> element's 'type' attribute MUST be one of
the following:
o cancel -- do not retry (the error is unrecoverable)
o continue -- proceed (the condition was only a warning)
o modify -- retry after changing the data sent
o auth -- retry after providing credentials
o wait -- retry after waiting (the error is temporary)
The <error/> element:
o MUST contain a child element corresponding to one of the defined
stanza error conditions specified below; this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace.
o MAY contain a <text/> child containing XML character data that
describes the error in more detail; this element MUST be qualified
by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD
possess an 'xml:lang' attribute.
o MAY contain a child element for an application-specific error
condition; this element MUST be qualified by an
application-defined namespace, and its structure is defined by
that namespace.
The <text/> element is OPTIONAL. If included, it SHOULD be used only
to provide descriptive or diagnostic information that supplements the
meaning of a defined condition or application-specific condition. It
SHOULD NOT be interpreted programmatically by an application. It
Saint-Andre, Ed. Standards Track [Page 54]
RFC 3920 XMPP Core October 2004
SHOULD NOT be used as the error message presented to a user, but MAY
be shown in addition to the error message associated with the
included condition element (or elements).
Finally, to maintain backward compatibility, the schema (specified in
[XMPP-IM]) allows the optional inclusion of a 'code' attribute on the
<error/> element.
9.3.3. Defined Conditions
The following conditions are defined for use in stanza errors.
o <bad-request/> -- the sender has sent XML that is malformed or
that cannot be processed (e.g., an IQ stanza that includes an
unrecognized value of the 'type' attribute); the associated error
type SHOULD be "modify".
o <conflict/> -- access cannot be granted because an existing
resource or session exists with the same name or address; the
associated error type SHOULD be "cancel".
o <feature-not-implemented/> -- the feature requested is not
implemented by the recipient or server and therefore cannot be
processed; the associated error type SHOULD be "cancel".
o <forbidden/> -- the requesting entity does not possess the
required permissions to perform the action; the associated error
type SHOULD be "auth".
o <gone/> -- the recipient or server can no longer be contacted at
this address (the error stanza MAY contain a new address in the
XML character data of the <gone/> element); the associated error
type SHOULD be "modify".
o <internal-server-error/> -- the server could not process the
stanza because of a misconfiguration or an otherwise-undefined
internal server error; the associated error type SHOULD be "wait".
o <item-not-found/> -- the addressed JID or item requested cannot be
found; the associated error type SHOULD be "cancel".
o <jid-malformed/> -- the sending entity has provided or
communicated an XMPP address (e.g., a value of the 'to' attribute)
or aspect thereof (e.g., a resource identifier) that does not
adhere to the syntax defined in Addressing Scheme (Section 3); the
associated error type SHOULD be "modify".
Saint-Andre, Ed. Standards Track [Page 55]
RFC 3920 XMPP Core October 2004
o <not-acceptable/> -- the recipient or server understands the
request but is refusing to process it because it does not meet
criteria defined by the recipient or server (e.g., a local policy
regarding acceptable words in messages); the associated error type
SHOULD be "modify".
o <not-allowed/> -- the recipient or server does not allow any
entity to perform the action; the associated error type SHOULD be
"cancel".
o <not-authorized/> -- the sender must provide proper credentials
before being allowed to perform the action, or has provided
improper credentials; the associated error type SHOULD be "auth".
o <payment-required/> -- the requesting entity is not authorized to
access the requested service because payment is required; the
associated error type SHOULD be "auth".
o <recipient-unavailable/> -- the intended recipient is temporarily
unavailable; the associated error type SHOULD be "wait" (note: an
application MUST NOT return this error if doing so would provide
information about the intended recipient's network availability to
an entity that is not authorized to know such information).
o <redirect/> -- the recipient or server is redirecting requests for
this information to another entity, usually temporarily (the error
stanza SHOULD contain the alternate address, which MUST be a valid
JID, in the XML character data of the <redirect/> element); the
associated error type SHOULD be "modify".
o <registration-required/> -- the requesting entity is not
authorized to access the requested service because registration is
required; the associated error type SHOULD be "auth".
o <remote-server-not-found/> -- a remote server or service specified
as part or all of the JID of the intended recipient does not
exist; the associated error type SHOULD be "cancel".
o <remote-server-timeout/> -- a remote server or service specified
as part or all of the JID of the intended recipient (or required
to fulfill a request) could not be contacted within a reasonable
amount of time; the associated error type SHOULD be "wait".
o <resource-constraint/> -- the server or recipient lacks the system
resources necessary to service the request; the associated error
type SHOULD be "wait".
Saint-Andre, Ed. Standards Track [Page 56]
RFC 3920 XMPP Core October 2004
o <service-unavailable/> -- the server or recipient does not
currently provide the requested service; the associated error type
SHOULD be "cancel".
o <subscription-required/> -- the requesting entity is not
authorized to access the requested service because a subscription
is required; the associated error type SHOULD be "auth".
o <undefined-condition/> -- the error condition is not one of those
defined by the other conditions in this list; any error type may
be associated with this condition, and it SHOULD be used only in
conjunction with an application-specific condition.
o <unexpected-request/> -- the recipient or server understood the
request but was not expecting it at this time (e.g., the request
was out of order); the associated error type SHOULD be "wait".
( run in 3.286 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )