This document outlines the security design, threat model, and audit findings for kerbsec. The library prioritizes security by delegating cryptographic operations to the system's GSS-API implementation and following defense-in-depth principles.

1. Network Attacks

   • Man-in-the-middle (MITM)
   • Replay attacks
   • Token tampering
   • Downgrade attacks

2. Authentication Attacks

   • Credential theft
   • Brute force
   • Pass-the-hash/ticket

3. Memory Attacks

   • Memory dumps
   • Side-channel leaks
   • Timing attacks

1. System Compromise: If the OS is compromised, Kerberos tickets are accessible
2. KDC Compromise: Requires infrastructure security beyond this library
3. Physical Access: Requires OS-level protections
4. Cryptographic Breaks: Relies on system GSS-API implementation

┌───────────────────────────┐
│     Application Layer     │ ← Input validation
├───────────────────────────┤
│     kerbsec Library       │ ← Safe abstractions
├───────────────────────────┤
│     GSS-API (System)      │ ← Cryptography
├───────────────────────────┤
│     Kerberos Protocol     │ ← Authentication
├───────────────────────────┤
│     Network Transport     │ ← TLS (optional)
└───────────────────────────┘

• API Boundary: All inputs validated before GSS-API calls
• FFI Boundary: Unsafe code isolated in src/ffi/
• Platform Boundary: Platform-specific code in cfg blocks
• Feature Boundary: Security features cannot be disabled without explicit opt-in

The trace feature implements structured logging with strict security policies:

• Passwords or passphrases
• Kerberos tickets (TGT, service tickets)
• Session keys or key material
• Full token contents (AP-REQ, AP-REP)
• Wrapped/unwrapped message data
• Credential cache contents

• Token sizes (not contents)
• Operation success/failure status
• Realm and principal names
• FQDNs and SPNs
• Error codes (major/minor)
• Configuration flags
• Message metadata

// GOOD: Log metadata only
debug!(
    target: "kerbsec::iov",
    token_size = token.len(),
    encrypted = conf_req,
    "wrapped message"
);

// BAD: Never log sensitive data
// debug!("session_key = {:?}", key); // NEVER DO THIS

• No hardcoded passwords, keys, or tokens in source
• No test credentials in examples
• Environment variables used for KRB5CCNAME

# Audit for potential secret logging
rg -i "password|secret|key|token" --type rust | grep -v "session_key\|keytab"

• No credentials logged at any level
• Session keys never logged
• GSS tokens not logged in full

• Session keys should be zeroized after use
• GSS tokens should be cleared from memory
• Consider using zeroize crate for sensitive buffers

// Recommendation: Add to Cargo.toml
zeroize = { version = "1.7", features = ["derive"] }

// Example usage:
use zeroize::{Zeroize, ZeroizeOnDrop};

#[derive(Zeroize, ZeroizeOnDrop)]
struct SessionKey {
    #[zeroize(skip)]
    id: u32,
    key: Vec<u8>,
}

• Sequence numbers enforced
• Timestamp validation (5 min skew)
• Tests for replay detection

• Auth level cannot be downgraded
• Tests for downgrade scenarios

• RC4 disabled by default
• Requires explicit allow-weak-crypto feature
• Tests verify RC4 rejection

• IP addresses require SPN override
• Invalid SPNs handled gracefully
• Tests for edge cases

• Length checks before parsing
• Bounds checking on all reads
• No unsafe buffer operations

• Generic error messages for auth failures
• No stack traces in production
• No internal paths exposed

• Default to most secure options
• Explicit opt-in for weaker security
• Context not established on any error

• Only essential crates used
• No unmaintained dependencies
• libgssapi pinned to stable version

# Check for known vulnerabilities
cargo audit

# Review dependency tree
cargo tree

# Check licenses
cargo license

• Respects system Kerberos config
• Uses system credential cache
• No custom file permissions set

• No custom crypto implementation
• Delegates to system GSS-API
• Transport security handled by caller

1. Add memory zeroization for sensitive data

   • Session keys
   • GSS tokens
   • Credential cache data

2. Add rate limiting for auth attempts

   • Prevent brute force
   • Log excessive failures

3. Add audit logging

   • Authentication events
   • Authorization failures
   • Suspicious patterns

1. Fuzz testing for PDU parsing
2. Constant-time comparisons for MACs
3. Certificate pinning support for channel bindings

1. FIPS mode support
2. HSM integration for keys
3. Threat model documentation

Report security vulnerabilities to:

• Private: security@example.com
• Public: GitHub Security Advisories

• MIT License: No warranty, use at own risk
• Export Control: May be subject to export restrictions
• No Cryptographic Code: Uses system GSS-API only

// All unsafe operations isolated
#[cfg(target_os = "linux")]
unsafe fn wrap_iov_real(...) {
    // Validated inputs
    // Bounded operations
    // Error propagation
}

// RC4 disabled by default
#[cfg(not(feature = "allow-weak-crypto"))]
if uses_rc4(etype) {
    return Err(Error::WeakCrypto);
}

Credential delegation (GSS_C_DELEG_FLAG) is a powerful but dangerous feature that allows the server to impersonate the client. This is disabled by default for security reasons.

1. Complete Impersonation: The server can act as the client to any service
2. Credential Theft: Compromised servers can steal delegated credentials
3. Lateral Movement: Attackers can use delegated credentials to move through the network
4. Audit Trail Loss: Actions performed with delegated credentials appear to come from the original client

Only enable delegation when ALL of these conditions are met:

• The server is fully trusted and under your control
• The server needs to access resources on behalf of the client
• No alternative architecture (like token-based authorization) is feasible
• Strong audit logging is in place
• The delegation is time-limited

// Only enable for trusted servers
let config = KerberosConfig::builder()
    .realm("CORP.EXAMPLE.COM")
    .target_host("trusted-internal-server.corp.example.com")
    .delegation(true)  // DANGEROUS: Only for trusted servers
    .build()?;

// After authentication, handle delegated credentials carefully
if ctx.has_delegated_credentials() {
    // Log the delegation event with full context
    audit_log!("DELEGATION_GRANTED", client = principal, server = spn);

    // Export credentials with care
    let creds = ctx.export_delegated_credentials()?;

    // Use credentials with time limits and scope restrictions
    // Never store delegated credentials persistently
}

1. Constrained Delegation: Use S4U2Proxy to limit which services can be accessed
2. Time Limits: Set short credential lifetimes
3. Audit Everything: Log all delegation requests and usage
4. Network Segmentation: Isolate servers that require delegation
5. Regular Rotation: Rotate service accounts frequently

The GSS_C_DCE_STYLE flag (0x1000) is enabled by default for DCE/RPC compatibility. This flag modifies GSS-API behavior:

1. Sequence Checking: GSS sequence number checking is disabled (DCE/RPC has its own)
2. Out-of-Order Messages: Allows messages to be processed out of order
3. Replay Cache: GSS replay detection is modified to work with DCE/RPC semantics

Consider disabling DCE-style only when:

• Not using DCE/RPC protocols
• Implementing a custom protocol that needs GSS sequence protection
• Maximum GSS-API security is required regardless of compatibility

// Disable DCE-style for non-DCE protocols
let config = KerberosConfig::builder()
    .realm("EXAMPLE.COM")
    .target_host("server.example.com")
    .dce_style(false)  // Use standard GSS-API semantics
    .build()?;

Channel bindings tie the Kerberos authentication to the underlying transport, preventing token forwarding attacks:

use kerbsec::channel_bindings::{ChannelBindings, ChannelBindingType};

// Create TLS channel bindings
let cb = ChannelBindings {
    initiator_addrtype: 0,
    initiator_address: Vec::new(),
    acceptor_addrtype: 0,
    acceptor_address: Vec::new(),
    application_data: tls_exporter_material,  // From RFC 5929
    binding_type: Some(ChannelBindingType::TlsServerEndPoint),
};

let config = KerberosConfig::builder()
    .realm("EXAMPLE.COM")
    .target_host("server.example.com")
    .channel_bindings(Some(cb))
    .build()?;

Benefits:

• Prevents token forwarding
• Binds Kerberos to TLS session
• Mitigates MITM attacks
• Required by some compliance standards

• ✅ Replay attack detection
• ✅ Sequence number validation
• ✅ Downgrade prevention
• ✅ Weak cipher rejection
• ✅ SPN validation
• ✅ Clock skew handling

• Fuzzing with AFL/LibFuzzer
• Property-based testing
• Timing attack analysis
• Memory safety with Miri

1. Report: Send to security contact
2. Triage: Assess severity (CVSS)
3. Fix: Develop patch in private
4. Disclose: Coordinate disclosure
5. Release: Publish fix with advisory

| Level | Response Time | Example | |----------|---------------|-----------------------|| | Critical | 24 hours | RCE, auth bypass | | High | 7 days | Privilege escalation | | Medium | 30 days | Information disclosure | | Low | Next release | Theoretical issues |

# Rust security lints
cargo clippy --all-features -- -D warnings

# Security audit for dependencies
cargo audit

# Check for unsafe code
grep -r "unsafe" src/ --include="*.rs"

# Memory safety with Miri (nightly)
cargo +nightly miri test

# Memory leaks
valgrind --leak-check=full cargo test

# Address sanitizer (Linux)
RUSTFLAGS="-Z sanitizer=address" cargo +nightly test

# Thread sanitizer
RUSTFLAGS="-Z sanitizer=thread" cargo +nightly test

# Install cargo-fuzz
cargo install cargo-fuzz

# Run fuzzer
cargo fuzz run token_parser

# With AFL
cargo afl build
cargo afl fuzz -i in -o out target/debug/fuzz_target

# Generate coverage report
cargo tarpaulin --all-features --out Html

# With llvm-cov
cargo llvm-cov --html --all-features

• No new unsafe code without justification
• No logging of sensitive data
• Input validation for all public APIs
• Error messages don't leak information
• Tests for security-relevant changes
• Documentation for security implications

• Check for timing vulnerabilities
• Verify error handling
• Audit dependencies added
• Review unsafe blocks
• Check for panics in hot paths

Last updated: January 2025