The register protocol - Info/Query: the catch-all protocol

Info/Query and client registration

6.1 Info/Query: the catch-all protocol

6.2.2 The register protocol

The register protocol, defined in the jabber:iq:register namespace, is carried out directly between the client and its Jabber server. The register protocol is often the only protocol that Jabber servers allow a client to conduct before they are authenticated.6 If you disable the register protocol’s ability to create new accounts, you will only be able to use the register protocol after you are authenticated.

In general, the register protocol involves sending a register get query to probe the server’s capabilities and then setting registration information using a set

query.7 Figure 6.3 shows a sequence diagram of this process. Probing the server prior to setting is not required but will let you know what registration fields the server supports. The result of sending unsupported fields to the server is not spec- ified by the register protocol.

The server will usually either drop the unsupported fields or store them without using them. In the former case, the client is wasting bandwidth, in the latter, there is another IQ extension protocol, jabber:iq:private,8 that is specifically 6 _{For example, the message and presence packets are almost never accepted from an unauthenticated}

client.

7 _{One of the toughest aspects of discussing jabber is making sure everyone is using a common vocabulary.}

In this case, we are talking about a groupchat message packes that is written in XML code as: <message type="groupchat">message content</message>.

8 _{See appendix A for more information about this protocol.}

user/client Server Probe <iq> type=“get” Response Valid fields Register <iq> type=“set” Response success/error Figure 6.3

The register protocol typically involves probing the server for register support followed by account creation/update using a _set packet.

172 CHAPTER 6

Info/Query and client registration

designed to store arbitrary client data on the server. For these reasons it is rec- ommended that you probe the server for register protocol support prior to using the protocol.

A register probe involves sending an empty register get quer y packet to the ser ver:

Notice the lack of sender or recipient addresses in the <iq> packet. Prior to authentication, you may only address messages to the server so setting a recipient address is irrelevant. In addition, the client has no authenticated Jabber ID. This makes it incorrect to set either the to or from attributes of the <iq> packet. Since the <query> tag contains no subpackets, the server treats the query as a probe of its register protocol support to see what registration fields it handles.

The server responds with an IQ result query containing the empty fields it supports, or an IQ error indicating that the register protocol is not supported.9 The typical response looks like the following:

The server can indicate zero or more valid Jabber registration fields representing name, address, phone number, email address, and so forth (see the jabber:iq:register reference page in the appendix for valid fields). Clients will typically create a form with a text field next to a label containing the name of the field. For example, in response to the probe example shown earlier the typical client would present a form that looks like:

Username:

Password (hidden): E-mail:

Phone number:

9 _{You’ll typically encounter this behavior if you try to register using an unauthenticated client on a server}

that does not allow you to use register to create new user accounts. However the error may also indicate that register is entirely unsupported on the server.

Registration creates and manages accounts 173

Notice that three of the fields, <username>, <password>, and <hash>, are not handled as generic registration fields. Clients should recognize them as standard Jabber register protocol fields that have special significance as shown in table 6.2.

Table 6.2 Standard register fields and their significance.

I’ll cover the authentication protocols in the next chapter so we’ll skip the details of how they work. The only thing you need to be aware of is that users must select a username and password to register a new account.10 The client will use the password to generate the authentication credentials that go into the <password>,

<hash>_,<sequence>_{, and}<token>_.

The client obtains the user’s registration information, fills in the appropriate register fields, and sends them in a set_{query to the server. There are two basic}

types of set register queries depending on whether the client and server will be using plain/digest or zero-knowledge authentication.11 In the case of plain or digest authentication, the register set query sends the password as plain text in the <password>_field:

Field Meaning

username Will be used as the “user” part of the Jabber ID associated with this account. In

addition, “username” identifies the account to authenticate with (see chapter 7 on authentication).

password Used as the “password” credential in plain and digest authentication. The presence

of the password element indicates that the server supports either plain or digest authentication (see chapter 7 on authentication).

hash Used as the “hash” credential in zero-knowledge authentication. The presence of

the hash element indicates the server supports zero-knowledge authentication. The server expects register packets to contain <hash>, <sequence>, and <token> fields in a “set” register query when setting up zero-knowledge authentication credentials.

10_{Modifying or removing accounts requires the client to be authenticated. In this case, the username and}

password need to be sent only if they are being modified. Normally, usernames are not changeable but there is nothing in the standards restricting you from doing this.

11_{The server will indicate to the client which register authentication methods it supports by sending}

either a <password/>, <hash/>, or both in the register probe result packet. Plain, digest, and zero- knowledge are the three authentication protocols supported by the Jabber standards. We’ll discuss them in depth in chapter 7.

174 CHAPTER 6

Info/Query and client registration

<username>myName</username> <password>myPassword</password> <email>[email protected]</email> <phone>760-555-1234</phone> </query> </iq>

User names are case-insensitive.

In the case of zero-knowledge authentication support in the register protocol, the client must generate the zero-knowledge authentication credentials

<hash>, <sequence>, and <token> from the user’s password. Usernames are case-insensitive. Once the client generates these credentials, it sends them in the register

set query.12

<iq type='set' id='register_set_id'> <query xmlns='jabber:iq:register'> <username>myName</username> <hash>23ea323be3231</hash> <sequence>100</sequence> <token>9823cd2323fa</token> <email>[email protected]</email> <phone>760-555-1234</phone> </query> </iq>

Successfully setting the user account values with the register protocol will result in the server returning an empty result packet:

Otherwise the server returns a normal IQ error packet indicating why the register set query failed. Typically, this is due to the username being taken in the case of new user registration, or the client needing to be authenticated to change an existing user account.

Finally, if your server allows it, the register protocol supports the automatic removal of accounts. In order to do so, authenticate with the server and send a register removal packet:

</query> </iq>

12_{One of the main benefits of zero-knowledge authentication is that the client never shares the}

user’s password with the server. This eliminates the possibility that an attacker can intercept the password when it is being sent across the network, and prevents server break-ins from compro- mising a user’s password.

The Jabber server modifications 175

The server will respond with either an empty result packet indicating success, or an error packet explaining what is wrong. As with automatic account creation, automatic removal is a feature that administrators should carefully consider before they enable it on their servers.

Now that we’ve covered the register protocol used to support user accounts, let’s take a look at the code modifications to the Jabber server and client needed to support them.

In document Instant Messaging in Java The Jabber Protocols pdf (Page 196-200)