Summary

  • RFC 3163's mutual mode had the client sign the server's challenge and its own newly chosen random value. The server's final signature also covered both values—but added a third random value because the client had already seen the server challenge before choosing its own.
  • The third value bound that response to a fresh server contribution. It did not make the mechanism a secure channel: RFC 3163 provides no integrity or confidentiality service and warns that active attacks remain possible.

The detail that looks redundant

At first glance, RFC 3163's mutual-authentication exchange seems to repeat itself. The server sends a random challenge, the client signs a transcript containing it, and the server later signs a transcript containing it too. Why should the final server token need a third random number?

The August 2001 memo, “ISO/IEC 9798-3 Authentication SASL Mechanism,” gives a precise answer. Its concern is not the count of messages. It is who knew which challenge at the moment each party chose its own random value. That order affects what a signature can show about the exchange.

RFC 3163 defines two mechanism-name families. 9798-U-<algorithm> authenticates the client to the server. 9798-M-<algorithm> adds mutual entity authentication: the client signs a server challenge, and the server signs a client challenge. The design uses public-key signatures and X.509 certificates, with certificate-path processing in the verification steps.

The order of the signatures

In either mode, the server begins with a random value R_B. The client then generates R_A. Its TokenAB carries certificate material and a signature over R_A and R_B; it may also identify the server. The server checks the signature, confirms that the returned R_B matches the challenge it sent, and checks an optional server identifier.

For unilateral authentication, that client token completes the core exchange. Mutual mode adds a server response. TokenBA2 carries the server's certificate and signs R_A, R_B and a new value, R_C. The client verifies the server's certificate and signature, checks that R_A and R_B match the earlier steps, and checks an optional client identity.

Section 7 explains why the new value matters. Including R_A in the client's signed data means the server cannot obtain that signature on data it selected before the mechanism began. But the reverse direction is not symmetric. The client knew R_B before it chose R_A. Including R_B in the server's signature is necessary for the client to check the transcript, yet that value alone does not offer the same protection to the server. RFC 3163 therefore adds R_C to the server-signed TokenBA2.

This is a transcript-design rationale, not a general proof that every relay, replay or active attack is defeated. The RFC requires cryptographically strong random values and warns that predictable values make the mechanism attackable. The added value addresses the timing gap described by the memo; it cannot repair every property left outside the transcript.

A signature is not a protected session

The boundary is explicit. RFC 3163 says the mechanism supplies authentication only. It does not provide integrity for later protocol messages or confidentiality for their contents. Its security section says protection is only against passive eavesdropping and specifically notes that active attacks, including session hijacking, remain possible. The RFC's IESG note is sharper still: the mechanism takes on PKI complexity while discarding per-transmission integrity, and TLS can provide the effect with integrity benefits.

The certificate fields do not collapse these layers. RFC 3163 allows an authID in TokenAB when the access-control identity differs from the certificate signer's identity. Certificate path acceptance, mechanism authentication, identity mapping and an application's authorization policy are separate decisions. A valid signature verifies covered data under a key; it does not itself decide what an application should permit.

The worked IMAP example does not demonstrate the mutual exchange. RFC 3163 labels it a 9798-U client-authentication example and says Base64 framing and the + response prefix come from the IMAP profile, not from the SASL mechanism. The example is a protocol illustration, not evidence of deployment or interoperability.

Lu Heng's Note 20 offers an interpretive lens: separate evidence that a protocol actually checks from broader claims about identity or authority. Applied here, nonce correspondence and a verified signature belong to the transcript; channel protection and application permission require other controls. That is a reading lens, not a claim by RFC 3163's authors.

Sources

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. RFC Editor record for RFC 3163
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. IANA SASL Mechanisms registry
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng, Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile