Difference between revisions of "Projects/Audit"

Revision as of 12:02, 20 June 2013

Purpose

Create an Audit infrastructure within MIT Kerberos to monitor security related events on the KDC. In future expand Kerberos Audit facility to the application servers, kadmin if it remains desirable.

Requirements

The new audit system should be:

• build-time enabled;
• run-time pluggable;
• simple, so it could be easily replaced with the OS specific implementations;

Events

This section details the categories of the auditable events and the associated information.

Audit module loaded/unloaded

Startup and shutdown of the audit system must be recorded by audit system;

KDC started/stopped

Startup and shutdown of the KDC must be recorded by audit system;

Authentication

(Common Criteria Class FIA)

We anticipate that multiple levels of details of the auditable events will be needed. We suggest having to levels: Detailed and its subset, Basic.

AS exchange

Basic level

TGT ticket ID (on success);

request ID

client’s address and port;

chosen by KDC session key enctype;

server key enctype;

kdc request:

requested service principal;

client’s principal;

Detailed level

KDC status message (on failure);

kdc request:

kdc options;

requested ticket start, end and renew_till times;

requested enctypes;

preauth types (on failure);

list of requested addresses;

kdc reply:

TGT ticket (on success);

preauth types (on failure) .

TGS exchange

Basic level

TGT ticket ID;

service or referral TGT ticket ID (on success)

request ID

client’s address and port;

chosen by KDC session key enctype;

server key enctype;

was ticket renewed;

was ticket validated;

kdc request:

requested service principal;

client’s principal;

kdc reply:

service ticket (on success).

Detailed level

kdc request:

addresses;

requested enctypes;

KDC options;

requested ticket start, end and renew_till times;

kdc reply:

client principal (on failure);

preauth types (on failure);

referral TGT ticket (on success).

TGS Extensions

S4U2self

entry-point-server's TGT ticket ID;

request ID

On error:

user's pre-authentication data: name and realm or x509 certificate;

kdc_status

local or protocol policy problem (with details?)

On Success

end-service or referral TGT ticket ID

S4U2proxy

entry-point-server's TGT ticket ID;

request ID

user's evidence ticket;

On error:

kdc_status

local or protocol policy problem (with details?)

On Success

end-service or referral TGT ticket ID

Other events

(possible future work)

Policy

Policies violation when processing requests;

AS request;

TGS request;

S4U2PROXY request.

Secrets (Common Criteria FCS_CKM.1, FCS_CKM.4);

long- and short-term keys creation, manipulation and cleaning.

Ticket details

client and server principals;

flags;

start, end and renew_till times;

authtime;

authentication path - encoded list of transited realms for service ticket or referral TGT (for TGS only);

ticket key type.

Design details

The following are highlights of this new feature:

Ticket ID

Ticket ID is recorded as part of audit messages. This allows to link tickets to their initial TGT at any stage of the Kerberos exchange.

For the purpose of this project we will create a private to KDC ticket ID: each successfully created ticket will be hashed and recorded into audit log. The administrators will correlate the primary and derived ticket IDs after the fact.

(For example, a successful AS_REQ results into tkt_ID_1. When it is used in TGS_REQ, tkt_ID_1 is logged together with the hash of the newly created ticket, say tkt_ID_2. If tkt_ID_2 is renewed, and a newly created ticket hash is tkt_ID_3, both tkt_ID_2 and tkt_ID_3 are logged.)

For the future, however, we need a more complex system that would allow to tie the tickets from a successful AS_REQ all the way to the application server. It is marked as an action item in this section.

Request ID

Request ID (hash of the request) is recorded as part of audit messages. Using this piece of information an administrator can easily correlate multiple audit events related to a single request.

Hybrid

The proposal is a hybrid of variadic key-type-value triplet (KTV) and one-API-per-event approaches.

On the KDC side call audit event-specific functions, whose input consists of the event-id, event-status and event-specific structure. If event-specific callback is implemented by the audit plugin, strip the event-specific structure from the security sensitive information and then pass the pointer to the event-specific structure to the plugin. Otherwise, fallback to the generic function with variadic KTV arguments. In the latter case all non-string values should be converted into the strings and the key-types serve as a hint to the plugin implementor about the "original" type of the key-value.

KDC facing API

/* Audit plugin loaded/unloaded */
krb5_error_code 
load_audit_plugin(krb5_context context);
krb5_error_code 
unload_audit_plugin(krb5_context context);
/* event specific functions */
krb5_error_code 
kau_kdc_start(krb5_context context, struct server_handle shdl, int status);
krb5_error_code 
kau_kdc_stop(krb5_context context, krb5_error_code status);
krb5_error_code 
kau_as_req(krb5_context context, struct as_req_state *state, int status);
krb5_error_code 
kau_tgs(krb5_context context, struct tgs_req_audit_state *state, int status);

Pluggable interface

/* Audit plugin vtable */
typedef struct krb5_audit_vtable_st {
   /* Mandatory: name of module. */
   char             *name;
   kau_open_fn       open;
   kau_close_fn      close;
   kau_generic_fn    generic;
   kau_kdc_start_fn  kdc_start;
   kau_kdc_stop_fn   kdc_stop;
   kau_as_req_fn     as_req;
   kau_tgs_req_fn    tgs_req;
} *krb5_audit_vtable;

typedef krb5_error_code
(*kau_open_fn)(kau_ctx *au_ctx);

typedef krb5_error_code
(*kau_close_fn)(kau_ctx au_ctx);

/* general purpose interface to pass unspecified number of 
 *  key-type-value triplets to a plugable interface.
 */
typedef krb5_error_code
(*kau_generic_fn)(kau_ctx au_ctx, const int event_id, const int status, ... );

/* one-API-per-event surrogate */
typedef krb5_error_code
(*kau_kdc_start_fn)(kau_ctx au_ctx, const int event_id, const int status,
                    struct server_handle_san shdl);
typedef krb5_error_code
(*kau_kdc_stop_fn)(kau_ctx au_ctx, const int event_id, const int status);
typedef krb5_error_code
(*kau_as_req_fn)(kau_ctx au_ctx, const int event_id, const int status,
                 struct as_req_state_san *state);
typedef krb5_error_code
(*kau_tgs_fn)(kau_ctx au_ctx, const int event_id, const int status,
              struct tgs_req_state_san *state);

where new types server_handle_san, as_req_state_san and tgs_req_state_san are sanitized variants of server_handle, as_req_state and tgs_req_state structures respectively.

Example

krb5_error_code
kau_as_req(krb5_context context, struct as_req_state *state,
          krb5_error_code  status)
{
   krb5_error_code rc = 0;
   ...
   /* If audit plugin event-specific callback is implemented, call it */
   if (hdl->vt.as_req) {
       rc = hdl->vt.as_req(hdl->au_ctx, event_id, event_status, state);
       return rc;
   }
   /* Otherwise, try the generic one. */
   if (hdl->vt.generic)
       rc = rec_as_req(hdl->au_ctx, event_id, event_status, state);
   return rc;
}

static krb5_error_code
rec_as_req(krb5_context context, struct as_req_state_san *state,
          krb5_error_code status)
{
   krb5_error_code rc = 0;
   ...
   /* All values with TYPE_NUM type-hint are string representations of 
    * their numeric conterparts in 'state' structure.
    */
   hdl->vt.record(hdl->au_ctx, event_id, event_status,
                  "tkt_id",             TYPE_NUM, tkt_id,              // state->tkt_id 
                  "kdc_status",         TYPE_STR, state->status,
                  "full_address",       TYPE_STR, state->full_address,                 
                  /* request */
                  "req.client",      TYPE_STR, state->req_client,   
                  "req.server",      TYPE_STR, state->req_server,  
                  "req.kdc_options", TYPE_STR, state->req_kdc_options,
                  "req.start",       TYPE_NUM, req_from,  // state->req_from
                  "req.end",         TYPE_NUM, req_end,   // state->req_end
                  "req.renew_till",  TYPE_NUM, req_time,  // state->req_rtime 
                  /* reply */
                  "rep.tkt.server",  TYPE_STR, state->rep_tkt_server,
                  "rep.tkt.flags",   TYPE_NUM, rep_tkt_flags,    // state->rep_tkt_flags
                  "rep.tkt.start",   TYPE_NUM, rep_tarttime,     // state->rep_tarttime
                  "rep.tkt.end",     TYPE_NUM, rep_endtime,      // pstate->rep_endtime,
                  "rep.tkt.renew_till",  TYPE_NUM, rep_renew_till,      // state->rep_renew_till
                  "rep.tkt.authtime",    TYPE_NUM, rep_authtime,        // state->rep_authtime,
                  "rep.tkt.key_etype",  TYPE_NUM, rep_session_enctype, // state->rep_session_enctype
   );
   return rc;
}

Dictionary

The possible basic field names are:

Configuration

The following ./configure option to be added:

--with-audit-plugin=simple

(For demo and testing purposes) Build the audit plugin "simple" and enable audit plugin.

Future work

1. Standardize a Ticket_ID;
2. Make reporting auditable events configurable. For example, one can choose to report TGS_REQ, but not AS_REQ etc;
3. Define and make configurable the DETAILED and BASIC levels of the events;
4. Develop Audit system for Preauth and Authdata mechanisms.

Test implementation

We will use libaudit module available on Fedora, Debian, Suse for the first round.

Some "simple" audit plugin will be implemented and Python test system will become aware of its existence. New ./configure --with-audit-plugin option will be introduced to build "simple" audit plugin for testing purpose. If audit is enabled and audit plugin is available, "make check" will store audit messages into audit log file.

References

1. Common Criteria for Information Technology Security Evaluation http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf
2. Oracle Solaris Auditing http://docs.oracle.com/cd/E19963-01/html/821-1456/auditov-1.html
3. Understanding Linux Audit http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.comp.html
4. Advanced Security Audit Policy Settings http://technet.microsoft.com/en-us/library/dd772712(v=ws.10).aspx
5. Events Classification in Log Audit http://airccse.org/journal/nsa/0410ijnsa5.pdf
6. CEE Log Syntax (CLS) Encoding http://cee.mitre.org/language/1.0-beta1/cls.html