Skip to content

F-3.9: AUTH_SHORT Session Credentials

Classification

  • Severity: Low
  • CVSS Vector: N/A (informational)
  • Affected Versions: Any NFS version advertising AUTH_SHORT (flavor 2)
  • RFC Reference: RFC 5531 S14 (AUTH_SHORT flavor 2), RFC 1057 S9.3 (short-hand credentials)
  • Prerequisite: Server advertises or issues AUTH_SHORT verifiers in replies
  • Kernel Code: include/linux/sunrpc/msg_prot.h:19 (defines RPC_AUTH_SHORT=2)

Summary

AUTH_SHORT (auth_flavor 2) is a session credential mechanism defined in the original ONC RPC specification (RFC 1057 S9.3). After a successful AUTH_SYS call, the server may return an AUTH_SHORT verifier in its reply -- an opaque token that the client can use in place of the full AUTH_SYS credential body on subsequent calls, reducing per-RPC overhead. The security implication is that AUTH_SHORT tokens are bearer credentials with no cryptographic binding: any party that captures or guesses the token can impersonate the authenticated session. However, Linux knfsd never issues or accepts AUTH_SHORT credentials -- the authtab[2] slot is NULL -- so this finding is informational on Linux targets and only relevant for non-Linux NFS servers (Solaris, NetApp ONTAP, FreeBSD) that may implement the mechanism.

Technical detail

AUTH_SHORT protocol flow

RFC 1057 S9.3 describes the intended flow:

  1. Client sends an RPC call with full AUTH_SYS credentials (flavor 1): uid, gid, auxiliary groups, machinename
  2. Server authenticates the request and returns a reply with verf_flavor=AUTH_SHORT and verf_body=<opaque token>
  3. On subsequent calls, the client may send auth_flavor=AUTH_SHORT with auth_body=<opaque token> instead of the full AUTH_SYS credential
  4. The server maps the opaque token back to the original credential internally
  5. If the token expires or is invalid, the server returns AUTH_REJECTEDVERF, and the client falls back to full AUTH_SYS

Security properties of AUTH_SHORT tokens

Property Value
Cryptographic binding None -- opaque token, no MAC or signature
Replay protection None -- token is static until revoked
Expiration Implementation-defined (may be indefinite)
Scope Session-local on the issuing server
Wire visibility Plaintext on non-TLS connections

An attacker who captures an AUTH_SHORT token from the wire (see F-3.1) can replay it from a different source IP to impersonate the original client. The token is strictly weaker than AUTH_SYS because AUTH_SYS at least carries the claimed identity (uid/gid) visibly, whereas AUTH_SHORT hides the identity behind an opaque blob that the server trusts unconditionally.

Linux knfsd: not affected

Linux knfsd does not implement AUTH_SHORT:

  • include/linux/sunrpc/msg_prot.h defines RPC_AUTH_SHORT=2 as a constant
  • The authtab[] array in net/sunrpc/svcauth.c has a NULL entry for index 2
  • Any incoming RPC call with auth_flavor=2 receives AUTH_REJECTEDCRED
  • The server never returns AUTH_SHORT verifiers in replies

This finding fires only when AUTH_SHORT appears in the MOUNT MNT auth_flavors list or in an NFSv4 SECINFO response, indicating a non-Linux NFS server that advertises (and potentially accepts) AUTH_SHORT credentials.

Where AUTH_SHORT appears

  • MOUNT MNT reply: The auth_flavors list may include flavor 2 alongside flavor 1 (AUTH_SYS). This is a server advertisement, not a client choice at mount time.
  • NFSv4 SECINFO: Per-object security flavor negotiation can list AUTH_SHORT.
  • RPC reply verifiers: After a successful AUTH_SYS call, the reply's verf_flavor field may be set to AUTH_SHORT with a non-empty verf_body.

Non-Linux implementations

Implementation AUTH_SHORT Support
Linux knfsd Not implemented (authtab[2] = NULL)
Solaris/Illumos Historically supported; may issue tokens
FreeBSD Not commonly used; varies by version
NetApp ONTAP May advertise in auth_flavors for compatibility
macOS Not supported

Impact

  • On Linux targets: None. AUTH_SHORT is dead code. The finding is a server fingerprinting signal -- advertising flavor 2 indicates a non-Linux NFS implementation.
  • On non-Linux targets: AUTH_SHORT tokens are replayable bearer credentials. Capture one from the wire and reuse it to impersonate the original client without knowing their uid/gid.
  • Fingerprinting value: Presence of AUTH_SHORT in auth_flavors helps identify the NFS server implementation, which may inform other attack choices.

Detection (nfswolf)

The analyzer checks for AUTH_SHORT (flavor 2) in two places:

  1. MOUNT auth_flavors: After a successful MNT call, the reply's auth_flavors list is inspected. If flavor 2 is present, the finding fires at Info severity.
  2. NFSv4 SECINFO: For NFSv4 exports, a SECINFO call on the export root returns per-object security flavors. Flavor 2 in this list triggers the same finding.

The check is passive -- no AUTH_SHORT handshake is attempted. nfswolf does not implement AUTH_SHORT credential issuance or replay.

Remediation

  1. No action needed on Linux -- knfsd does not support AUTH_SHORT. The finding is purely informational.
  2. On non-Linux servers, disable AUTH_SHORT if the implementation allows it. The mechanism provides no security benefit over full AUTH_SYS and adds a replayable credential surface.
  3. Use sec=krb5 -- Kerberos replaces both AUTH_SYS and AUTH_SHORT with cryptographically bound, non-replayable credentials.
  4. Enable RPC-with-TLS (RFC 9289) -- encrypts the wire, preventing AUTH_SHORT token capture even if the server issues them.
Finding Relationship
F-1.1: UID/GID Spoofing AUTH_SYS spoofing is the baseline; AUTH_SHORT is an abbreviated form of the same trust model
F-1.5: Credential Replay AUTH_SHORT tokens are replayable credentials, a subset of the general credential replay finding
F-3.1: Plaintext Wire Protocol AUTH_SHORT tokens are visible in plaintext on non-TLS connections
F-3.7: AUTH_DH Advertised Another obsolete/unusual auth flavor; both indicate legacy configuration