AFS & Kerberos Best Practices Workshop 2008 Design Goals Functions that require authentication Solution Space Kerberos, GSSAPI or SASL (Decide on your

AFS & Kerberos Best Practices Workshop 2008

Design Goals

Functions that require authentication

Solution Space

Kerberos, GSSAPI or SASL (Decide on your API!)

Test Environment

Configuration options

Kerberos vs. GSSAPI

Deployment issues

Overview


- Try for a best practices implementation

- KDC compatibility (MIT/Heimdal/Windows/CyberSafe/others)

- Heterogeneous support (Linux, UNIX, Windows, OSX, Netware)

- Compatibility with the existing TiBS solution

- Customer ease of use

- Minimize support costs

Design Goals


TiBS Server initiated operations

- The TiBS Server is the Kerberos client

- The TiBS Client is the Kerberos application server

- Backup, restore, and auditing programs

- Command line (as root) and cron jobs

-TiBS Client initiated oprerations

- The TiBS Client is the Kerberos client

- The TiBS Server is the Kerberos application server

- Backup (local and request modes)

- Command line (as root OR user) and cron jobs

Functions that require authentication


How to build?

-Statically link against some library

-Dynamically link (dlopen) and ship libraries

-Use a shim to allow clients to build their own binaries

What to build?

- Kerberos 5

-GSSAPI

-SASL

Who to build?

- MIT/Heimdal/OS Vendor/Commercial

Solution Space ([email protected], lots of paths…)

mailto:[email protected]


- You want to get initial credentials.

- You want to renew Kerberos tickets.

- You want to do user-to-user authentication.

- You are writing something for internal use and want to get away with a

minimum amount of code.

- You want to guarantee a single round-trip authentication.

- You are using a datagram protocol.

- You want to make use of various Kerberos ticket fields.

- You‘re not concerned about porting from Heimdal to MIT, or vice versa.

Decide on on your API! (Why choose Kerberos)


- You want API stability between MIT, Heimdal, or other Kerberos

implementations.

- You want to make use of native Windows Kerberos services.

- You want to add GSSAPI mech support to an application that already

implements SASL internally.

- You want to provide a path for supporting other security mechanisms in the

future.

Decide on on your API! (Why choose GSSAPI)


- You want the ability to support a wide variety of security mechanisms,

today.

- You need to interoperate with protocols that use SASL and you can

guarantee that Cyrus-SASL will be available.

- You need the ability to negotiate the use of encryption.

Decide on on your API! (Why choose SASL)


- MIT (1.6.3) and Hiemdal Libraries (1.1)

- Static, dynamic, dlopen (MIT does not support static libraries)

- Solaris & Linux (primary backup servers)

- Kerberos and GSSAPI

- Clients can use Standard, Kerberos, or GSSAPI Authentication

- Servers accept any of these methods

Test Environment


Alternate keytabs (KRB5_KTNAME environment variable)

1. Regular users need authenticate with a common principle

Example: tibs/backup@REALM

2. You have services that do not run as root

TIBS_KEYTAB=/usr/tibs/tibs.keytab

If (setenv("KRB5_KTNAME", keytab_string, 1)) warn…

Our application primarily runs as root, so #1 is possible


mailto:tibs/backup@REALM


Alternate service principles (default==host/hostname@REALM)

1. Regular users need authenticate with a common principle

KRB5_ACCEPT_PRINC=tibs/backup@REALM

2. You have services that do not run as root

3. Allow access to backup clients from multiple servers (as root)

KRB5_KEY_LOOKUP=tibs/backup@REALM

If your service principles are not in service/hostname@REALM format

Kerberos: krb5_mk_req_extended();

GSSAPI: gss_import_name(); with GSS_C_NT_USER_NAME





mailto:service/hostname@REALM


Server Side Access Control Lists

- Regular users use their existing credentials

- Allow or deny services

Example:

user@REALM|host1|backup

*|laptop1|backup

*|*|deny

We will probably need to do this


mailto:user@REALM%7Chost1%7Cbackup


Leaning towards deployment with GSSAPI

Easy implementation using example code from Sun

Windows SSPI

May want use Solaris native libraries

Kerberos vs. GSSAPI


Static Linking

- Works with no configuration changes

- Minimal changes to our installer

- Safe bet for keeping backups running

Dynamic Linking

- Ship dynamic link libraries you compile against

- Manage LD_LIBRRAY_PATH

- Ongoing problems with deployment

Linux GLIBC_2.2.5 with Heimdal-1.1

LD_LIBRARY_PATH=/usr/local/BerkeleyDB/v4/lib

Deployment issues


Linux: strongly considering static linking

Solaris: still looking at the OS libraries, otherwise probably static linking

Windows: looking at SSPI

OSX: stay tuned

SHIM: stay tuned

Deployment issues

Documents

AFS & Kerberos Best Practices Workshop 2008 Design Goals Functions that require authentication Solution Space Kerberos, GSSAPI or SASL (Decide on your