unable to authenticate with some jabber servers

[porridge]

The following line in jabber_handle_stream_features() means that it is impossible to authenticate with a server which requires the whole "user@domain" string (rather than just "user").

string_append_n(str, s->uid+5, xstrchr(s->uid+5, '@')-s->uid-5);

I don't know what the standards dictate, but at least an option that would control this behaviour would be useful.

[mgorny]

Maybe we should add some additional 'username' sessvar, and use above only when it's not set.

[porridge]

After browsing the standards, it seems to me that the whole user@domain string should be sent. Here are some relevant snippets:

Extensible Messaging and Presence Protocol (XMPP): Core  http://www.ietf.org/rfc/rfc3920.txt

| 3.  Addressing Scheme
|
| 3.5.  Determination of Addresses
| [...]
|    After SASL negotiation (Section 6) and, if appropriate, Resource
|    Binding (Section 7), the receiving entity for a stream MUST determine
|    the initiating entity's JID.
| [...]
|    For client-to-server communications, the "bare JID" (<node@domain>)
|    SHOULD be the authorization identity, derived from the authentication
|    identity, as defined in [SASL], if no authorization identity was
|    specified during SASL negotiation (Section 6); the resource
|    identifier portion of the "full JID" (<node@domain/resource>) SHOULD
|    be the resource identifier negotiated by the client and server during
|    Resource Binding (Section 7).
|
|    The receiving entity MUST ensure that the resulting JID (including
|    node identifier, domain identifier, resource identifier, and
|    separator characters) conforms to the rules and formats defined
|    earlier in this section; to meet this restriction, the receiving
|    entity may need to replace the JID sent by the initiating entity with
|    the canonicalized JID as determined by the receiving entity.
| [...]
|
| 6.  Use of SASL
|
| 6.1.  Overview
|
|    XMPP includes a method for authenticating a stream by means of an
|    XMPP-specific profile of the Simple Authentication and Security Layer
|    (SASL) protocol [SASL].  SASL provides a generalized method for
|    adding authentication support to connection-based protocols, and XMPP
|    uses a generic XML namespace profile for SASL that conforms to the
|    profiling requirements of [SASL].
|
|    The following rules apply:
| [...]
|    7.  If the initiating entity wishes to act on behalf of another
|        entity and the selected SASL mechanism supports transmission of
|        an authorization identity, the initiating entity MUST provide an
|        authorization identity during SASL negotiation.  If the
|        initiating entity does not wish to act on behalf of another
|        entity, it MUST NOT provide an authorization identity.  As
|        specified in [SASL], the initiating entity MUST NOT provide an
|        authorization identity unless the authorization identity is
|        different from the default authorization identity derived from
|        the authentication identity as described in [SASL].  If provided,
|        the value of the authorization identity MUST be of the form
|        <domain> (i.e., a domain identifier only) for servers and of the
|        form <node@domain> (i.e., node identifier and domain identifier)
|        for clients.
| [...]
|
| 6.2.  Narrative
| [...]
|    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.
| [...]
|
| 6.3.  SASL Definition
|
|    The profiling requirements of [SASL] require that the following
|    information be supplied by a protocol definition:
| [...]
|    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.

Simple Authentication and Security Layer (SASL)  http://tools.ietf.org/html/rfc4422

| 3.4.1. Authorization Identity String
|    
|    The authorization identity string is a sequence of zero or more
|    Unicode [Unicode] characters, excluding the NUL (U+0000) character,
|    representing the identity to act as.
|    
|    If the authorization identity string is absent, the client is
|    requesting to act as the identity the server associates with the
|    client's credentials.  An empty string is equivalent to an absent
|    authorization identity.
|    
|    A non-empty authorization identity string indicates that the client
|    wishes to act as the identity represented by the string.  In this
|    case, the form of identity represented by the string, as well as the
|    precise syntax and semantics of the string, is protocol specific.
| 
|    While the character encoding schema used to transfer the
|    authorization identity string in the authentication exchange is
|    mechanism specific, mechanisms are expected to be capable of carrying
|    the entire Unicode repertoire (with the exception of the NUL
|    character).
|    
| 4. Protocol Requirements
|
|    In order for a protocol to offer SASL services, its specification
|    MUST supply the following information:
|    
| [...]
|        
|    4) Prescribe the syntax and semantics of non-empty authorization
|       identity strings (see Section 3.4.1).
|        
|       In order to avoid interoperability problems due to differing
|       normalizations, the protocol specification MUST detail precisely
|       how and where (client or server) non-empty authorization identity
|       strings are prepared, including all normalizations, for comparison
|       and other applicable functions to ensure proper function.
|        
|       Specifications are encouraged to prescribe use of existing
|       authorization identity forms as well as existing string
|       representations, such as simple user names [RFC4013].
|
|       Where the specification does not precisely prescribe how
|       identities in SASL relate to identities used elsewhere in the
|       protocol, for instance, in access control policy statements, it
|       may be appropriate for the protocol to provide a facility by which
|       the client can discover information (such as the representation of
|       the identity used in making access control decisions) about
|       established identities for these uses.

The PLAIN Simple Authentication and Security Layer (SASL) Mechanism  http://www.ietf.org/rfc/rfc4616.txt

| 2.  PLAIN SASL Mechanism
| 
|    The mechanism consists of a single message, a string of [UTF-8]
|    encoded [Unicode] characters, from the client to the server.  The
|    client presents the authorization identity (identity to act as),
|    followed by a NUL (U+0000) character, followed by the authentication
|    identity (identity whose password will be used), followed by a NUL
|    (U+0000) character, followed by the clear-text password.  As with
|    other SASL mechanisms, the client does not provide an authorization
|    identity when it wishes the server to derive an identity from the
|    credentials and use that as the authorization identity.
|
| [...]
|
|    The authorization identity (authzid), authentication identity
|    (authcid), password (passwd), and NUL character deliminators SHALL be
|    transferred as [UTF-8] encoded strings of [Unicode] characters.  As
|    the NUL (U+0000) character is used as a deliminator, the NUL (U+0000)
|    character MUST NOT appear in authzid, authcid, or passwd productions.
|
|    The form of the authzid production is specific to the application-
|    level protocol's SASL profile [SASL].  The authcid and passwd
|    productions are form-free.  Use of non-visible characters or
|    characters that a user may be unable to enter on some keyboards is
|    discouraged.

[porridge]

FYI, this is  http://bugs.debian.org/506678

[darkjames]

Hi,

Sending user@domain doesn't work with my jabber server (jabber.org), so I think the best approach is to make this behaviour configurable.

Have you got any patch? :)

[porridge]

Replying to darkjames:

Hi, Sending user@domain doesn't work with my jabber server (jabber.org), so I think the best approach is to make this behaviour configurable.

:-/

Have you got any patch? :)

No, and I have stopped using that server so I'm afraid I won't be able to provide a tested one.

[darkjames]

Closing, please reopen when you hit again this bug :)