メインコンテンツまでスキップ

RFC 9887 - Technical Summary (English Version)

Document: Terminal Access Controller Access-Control System Plus (TACACS+) over TLS 1.3
RFC Number: 9887
Publication Date: December 2025
Status: PROPOSED STANDARD
Updates: RFC 8907

Quick Reference Card​

Critical Requirements (MUST)​

RequirementSpecificationSection
TLS VersionTLS 1.3 minimum3.2
Port NumberTCP 300 for TLS3.1, 7
AuthenticationMutual (client + server)3.1
Certificate ValidationFull path + revocation3.4.1
ObfuscationMUST NOT use with TLS4
Unencrypted FlagMUST be set to 14
0-RTT DataMUST NOT send5.1.2
FallbackMUST NOT to non-TLS5.1.1

Supported Authentication Methods​

  1. Certificate-Based (MANDATORY)

    • X.509 certificates with full chain validation
    • Revocation checking required
    • DNS-ID, IP-ID, or SRV-ID for server identity
    • SNI extension support required

  2. Pre-Shared Keys (PSK) (OPTIONAL)

    • External PSKs (not resumption PSKs)
    • Minimum 16 octets length
    • MUST differ from obfuscation shared secrets

  3. Raw Public Keys (RPK) (OPTIONAL)

    • Out of scope for this document
    • See RFC 7250 for details

Port Assignment​

ServicePortProtocolUsage
TACACS+ (legacy)49TCPNon-TLS connections
TACACS+ over TLS300TCPTLS 1.3+ connections

IANA Registration: Service name "tacacss" on port 300/TCP

TLS Configuration Requirements​

Mandatory Cipher Suites​

  • TLS 1.3 mandatory suites (RFC 8446 Section 9.1)
  • Should be configurable by operators

Certificate Requirements​

  • Path Validation: RFC 5280 Section 6
  • Identity Validation: RFC 9525
  • Revocation: Must check during initial and resumption
  • SNI: Must support (RFC 6066 Section 3)

Prohibited Features​

  • ❌ TLS versions < 1.3
  • ❌ 0-RTT early data
  • ❌ Upgrade from non-TLS
  • ❌ MD5-based obfuscation
  • ❌ Fallback to non-TLS

Connection Lifecycle​

Client                                    Server
  |                                          |
  |--- TCP Connect to port 300 ------------>|
  |                                          |
  |<-- TLS 1.3 Handshake (mutual auth) ---->|
  |                                          |
  |--- TACACS+ Data (TLS app data) -------->|
  |<-- TACACS+ Response -------------------|
  |                                          |
  |--- Close (after session or timeout) --->|

Connection Modes​

  1. Single Connection Mode (RFC 8907 Section 4.3)

    • Multiple TACACS+ sessions over one TLS connection
    • Subject to inactivity timeout
    • Connection may persist briefly

  2. Non-Single Connection Mode

    • One TACACS+ session per TLS connection
    • TCP closed after session completion

TLS Resumption​

  • Ticket Lifetime: Should be configurable (including 0 seconds)
  • Single Use: Each ticket for one resumption only
  • Revocation Check: Required during resumption period
  • Server Behavior: Should allow if ticket valid and unused

Security Considerations Summary​

Threat Model Addressed​

ThreatMitigation
EavesdroppingTLS 1.3 encryption
Man-in-the-MiddleMutual authentication
Replay AttacksNo 0-RTT, nonce mechanisms
Downgrade AttacksSeparate ports, no fallback
Weak CryptoMD5 obsoleted, TLS 1.3 only

Deployment Security​

  1. TLS and non-TLS Separation

    • RECOMMENDED: Separate physical hosts
    • MUST: Separate port numbers
    • Prevents misconfiguration exposure

  2. Certificate Management

    • Follow BCP 195 (RFC 7525)
    • Wildcard certificates: confined to dedicated subdomain
    • CA reachability: plan for network isolation

  3. Configuration Clarity

    • Explicit TLS/non-TLS mode indicators
    • Validation warnings for port mismatches
    • Separate configuration sections

Migration Strategy (5 Phases)​

Phase 1: Assessment​

  • Inventory all TACACS+ clients and servers
  • Identify TLS-capable vs legacy devices
  • Plan network topology changes

Phase 2: Pilot​

  • Deploy TLS servers on port 300 in test environment
  • Configure test clients
  • Validate certificate infrastructure

Phase 3: Initial Deployment​

  • Migrate subset of production clients
  • Monitor for issues
  • Maintain parallel non-TLS infrastructure

Phase 4: Gradual Rollout​

  • Incrementally migrate remaining clients
  • Document any legacy device exceptions
  • Implement compensating controls for non-TLS

Phase 5: Completion​

  • Decommission non-TLS infrastructure
  • Final security audit
  • Update documentation

Critical Rule: Clients MUST NOT fall back to non-TLS if TLS fails

Implementation Checklist​

Server Implementation​

  • TLS 1.3 support (minimum)
  • Listen on port 300 (or configured alternative)
  • Certificate-based mutual authentication
  • Certificate path validation (RFC 5280)
  • Revocation checking
  • SNI extension support
  • Reject packets without TAC_PLUS_UNENCRYPTED_FLAG
  • Reject 0-RTT data
  • TLS resumption support
  • Configurable ticket lifetime
  • Optional: PSK authentication
  • Optional: Raw Public Keys

Client Implementation​

  • TLS 1.3 support (minimum)
  • Connect to port 300 (or configured)
  • Immediate TLS negotiation (no upgrade)
  • Certificate validation
  • SNI extension in ClientHello
  • Set TAC_PLUS_UNENCRYPTED_FLAG = 1
  • No 0-RTT data transmission
  • No fallback to non-TLS
  • TLS resumption support
  • Optional: PSK authentication
  • Optional: Raw Public Keys

Reference Implementation Notes​

Certificate Identity Validation​

Acceptable Identifier Types:
- DNS-ID: tacacs.example.com
- IP-ID: 192.0.2.1 or 2001:db8::1
- SRV-ID: _tacacs._tcp.example.com

NOT Acceptable:
- URI-ID (not used for TACACS+)

Wildcard Certificates​

✅ GOOD: *.tacacs.example.com (dedicated subdomain)
❌ BAD:  *.example.com (too broad)

PSK Identity Format​

- Minimum length: 16 octets
- Follow RFC 9257 Section 6.1
- Must differ from obfuscation secrets

Operational Best Practices​

  1. Monitoring

    • Log all TLS handshake failures
    • Alert on non-TLS connection attempts to port 300
    • Track certificate expiration dates

  2. Certificate Lifecycle

    • Automate renewal (e.g., ACME protocol)
    • Maintain certificate chains locally
    • Plan for CA outages

  3. Testing

    • Regular TLS configuration audits
    • Cipher suite compatibility testing
    • Failover scenario validation

  4. Documentation

    • Maintain inventory of TLS vs non-TLS servers
    • Document migration timeline
    • Record certificate trust anchors

Compliance Requirements​

FIPS 140-3​

  • TLS 1.3 with approved cipher suites
  • MD5 obfuscation obsoleted (non-compliant)
  • Certificate-based authentication recommended

Industry Standards​

  • PCI DSS: Strong cryptography required
  • NIST SP 800-52: TLS guidelines
  • BCP 195: TLS best practices

Common Pitfalls to Avoid​

  1. ❌ Port Mismatch: TLS client connecting to port 49
  2. ❌ Fallback Logic: Trying non-TLS after TLS failure
  3. ❌ Mixed Secrets: Using same keys for obfuscation and PSK
  4. ❌ 0-RTT Enabled: Sending early data
  5. ❌ Certificate Validation Disabled: Accepting invalid certs
  6. ❌ Same Host: Running TLS and non-TLS on same server
  7. ❌ Wildcard Abuse: Using *.example.com for all services
  8. ❌ No Revocation Check: Skipping CRL/OCSP validation

Performance Considerations​

TLS Handshake Overhead​

  • Full Handshake: ~2 RTT (TLS 1.3)
  • Resumption: ~1 RTT
  • Mitigation: Use resumption for repeated connections

Connection Persistence​

  • Single Connection Mode reduces handshake frequency
  • Balance between connection reuse and timeout settings
  • Typical timeout: 60-300 seconds

Certificate Validation​

  • Cache validated certificates
  • Use OCSP stapling to reduce latency
  • Consider TLS Cached Information Extension (RFC 7924)

Troubleshooting Guide​

SymptomPossible CauseSolution
Connection refusedWrong portCheck client configured for port 300
Handshake failureTLS version mismatchEnsure TLS 1.3 support
Certificate errorInvalid cert chainVerify CA trust and certificate validity
Authentication failedMutual auth issueCheck both client and server certificates
TAC_PLUS_UNENCRYPTED_FLAG errorFlag not setEnsure client sets flag to 1
Resumption rejectedTicket expired/usedNormal; full handshake will proceed

Future Considerations​

YANG Data Model​

  • Standardized configuration model needed
  • Would benefit automation and consistency
  • Should include TLS-specific parameters

Protocol Extensions​

  • This document focuses on TLS 1.3
  • Future TLS versions expected to work
  • Monitor IETF TLS WG for updates

IPv6 Deployment​

  • No changes to IPv6 recommendations
  • TLS works identically over IPv4 and IPv6
  • Use IP-ID for IP-based certificate identity

Quick Decision Tree​

Do you need TACACS+ security?
├─ YES → Use TLS (this RFC)
│   ├─ Modern devices → Certificate-based auth
│   ├─ Constrained devices → Consider PSK
│   └─ Legacy devices → Separate non-TLS infrastructure
│
└─ NO → Consider if TACACS+ is appropriate
    └─ High-security environments require TLS
  • RFC 8907: Base TACACS+ Protocol (updated by this RFC)
  • RFC 8446: TLS 1.3 (transport layer)
  • RFC 5280: X.509 PKI (certificates)
  • RFC 9525: Service Identity in TLS (identity validation)
  • RFC 9257: External PSK Guidance
  • RFC 7525 (BCP 195): TLS Best Practices

Document Status​

  • Standards Track: Yes
  • Implementation Required: For new deployments
  • Backward Compatibility: Parallel operation during migration
  • Obsoletes: MD5 obfuscation mechanism only
  • Updates: RFC 8907 (adds TLS profile)

Last Updated: December 26, 2025
Document Version: 1.0 (Complete English Version)
Maintained By: RFC Translation Project

に最終更新