Initial Version
When clients (or initiating servers) connect, thanks to Extensible SASL Profile (XEP-0388)
Although specifications such as Fast Authentication Streamlining Tokens (XEP-0484)
This protocol, herein "IAP", therefore allows a server to provide a token which is tied to what features are available, which the client then uses to indicate the basis of its authentication attempt. If this does not match, the authentication attempt is rejected without prejudice, and can be retried with the currently available features.
Note that the protocol is explicitly possible for both C2S and S2S.
Also note that for multi-step authentication this does not allow pipelining through <challenge/> and <response/> elements.
If a server supports IAP, this is indicated by a stream feature, consisting of an element of config-version, qualified by the namespace urn:xmpp:iap:0. This has two attributes, first, an optional scheme, which has the value (if present) of "opaque". Second, a mandatory value, for which the value is as defined below.
When an initiator is sent this stream feature, it SHOULD immediately cache this value as the current value.
When an initiator wishes to pipeline the <authenticate> with the stream open, it first caches the known config version, and sends this in a similar <config-version>, with the same optional scheme and value attributes as used by the responding entity, as a child of the <authenticate>.
The responder then attempts to match this value against its own current value before proceeding - the precise meaning of match depends on the scheme, though a simple string comparison MUST always be a match.
If a responder sees such an element and it does not match the current value, the responder rejects the <authenticate> with a <failure> "without prejudice", meaning that the attempted authentication is not counted as a "failed login", the account is not penalised or locked out, etc.
The failure SHOULD be of type <aborted>, and MUST carry an application-specific error of <config-version-mismatch>, qualified by the 'urn:xmpp:iap:0' namespace. On failure, the initiator will already have seen the new config-version feature advertised, and MUST update a previously cached value with the new value, and reconsider what <authenticate/> command to use.
Otherwise, the SASL2 authentication proceeds as per normal.
Config versions have schemes, which denote how the server calculates the version. The only defined scheme in this specification (so far) is "opaque", and all token schemes are compatible with "opaque".
The "opaque" scheme is a token which the client MUST NOT (and cannot) derive any meaning from.
While the server is in principle free to include any structured data such that it can "match" a token even if the current configuration differs, typically it would be expected that additional SASL mechanisms, SASL2 subfeatures, etc would be cause to reject the token (as the client might have wished to negotiate these instead or as well). Therefore such "smart" matching is both out of scope for this specification and moreover - until more implementation experience is gained - NOT RECOMMENDED
An exact match (ie, identical tokens by "i;octet") with the currently advertised value MUST be treated as a match.
One example of a conformant mechanism for generating the value would be to generate a hash or HMAC of the rendered features, absent the <config-version>. Note that the initiating entity MUST NOT assume this mechanism is in use, nor attempt to calculate any such hash itself.
Here is the flow from XEP-0484 (FAST), as a single example including the full stream and with annotations to indicate packets and round-trips.
In the initial session, the client has no config version, so waits for the features. On seeing the config-version feature, it will then cache the opaque token for subsequent tokens - but it's already too late to use it this session. Including it anyway in the <authenticate/> is not an error, but achieves nothing.
In a subsequent session, the client will use the config version token cached from the previous session. This allows it to attempt a pipeline safely.
If, when it tries to authenticate, the config version mismatches, then the server will reject the attempt. However, by the time the client sees this error the client will already know that its IAP attempt will fail, since it will have seen the new config-version feature, and indeed will have cached the new token ready to use next time.
It will immediately retry, though it might choose a new method, or take advantage of some new inline protocol.
Servers which attempt interpretation of matching non-identical tokens can cause clients to miss opportunities to improve their security, or gain new features (which might include security features). So again, this remains NOT RECOMMENDED.
There is a temptation to stuff the entirety of the initial pipelined send into TLS 0-RTT early-data; that is also NOT RECOMMENDED because it may allow for replay attacks. However, where explicit protection is in place for replay (such as FAST) this is acceptable.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)