Authentication may complete in one of three ways. It may complete successfully, in which case the client is authenticated. It may also fail, in which case the client is not authenticated and the stream and session state remain entirely unchanged.
Finally, it may have completed successfully, but further interaction is required - for example, a password change or second-factor authentication.
If the Client is now authenticated, the Server sends a <success/> element, which contains an OPTIONAL <additional-data/> element containing SASL additional data. It also contains a <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.
+If the Client is now authenticated, the Server sends a <success/> element, which contains contains an <authorization-identity/> element containing the negotiated identity - this is a bare JID, unless resource binding has occurred, in which case it is a full JID.
+It MAY contain an <additional-data> element, containing additional data from the exchange (task or SASL mechanism) that has just completed.
After the final octet of the first <continue> element, any SASL security layer negotiated in the preceding exchange SHALL be immediately in effect.
-Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response.
+Clients respond with a <next/> element, which has a single mandatory attribute of "task", containing the selected task name, and contains an OPTIONAL base64 encoded initial response contained in an <initial-response> element.
This section provides a fictional example. It is important to note that many of the extensions used wihtin this section do not, in fact, exist and therefore are to be avoided.
+Where no additional features that SASL2 makes available are used, the flow of information is identical to the original SASL profile. This example shows the new syntax and draws the reader's attention to the differences.
+Use of SASL2 in this simple scenario saves one round-trip (due to the lack of stream restart).
+Again, this is an equivalent flow to a common SASL1 flow, although using the CRAM-MD5 mechanism which is (thankfully) rarely used in practise.
+Use of SASL2 in this simple scenario again simply saves one round-trip.
+This moves into the deeply hypothetical. A binding extension is posited, alongside an unrealistic 2FA mechanism which somehow mutually authenticates because why not.
+Although the unrealistic 2FA here uses 2 round-trips (real ones will probably use one), the embedding of resource binding as shown here means that a second RTT is saved by SASL2, and there's no net change. A more realistic example would see RTTs saved, and additional negotiations could be added to further reduce RTTs.
+Relative to the SASL profile documented in RFC 6120, this introduces more data unprotected by any security layer negotiated by SASL itself.
While no actual exchanges are introduced that are unprotected, the nature of this exchange might allow for (for example) a resource binding extension to be introduced.
-SASL security layers are sparingly used in the field, however., so this is thought to be a theoretical, rather than practical, concern.
+SASL security layers are sparingly used in the field, however, so this is thought to be a theoretical, rather than practical, concern.
The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, and Florian Schmaus.
+The author wishes to share any credit with many members of the community, including Lance Stout, Ralph Meijer, Phil Roberts and Florian Schmaus.