Difference between revisions of "Projects/Audit"
(Introduce Basic and Detailed levels) |
|||
Line 28: | Line 28: | ||
===Authentication=== |
===Authentication=== |
||
(Common Criteria Class FIA) |
(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==== |
====AS exchange==== |
||
⚫ | |||
+ | =====Basic level===== |
||
⚫ | |||
:: client’s principal; |
:: client’s principal; |
||
:: requested service principal; |
:: requested service principal; |
||
⚫ | |||
:: client’s address and port; |
:: client’s address and port; |
||
:: chosen by KDC enctypes (session key, etc); |
:: chosen by KDC enctypes (session key, etc); |
||
⚫ | |||
+ | =====Detailed level===== |
||
⚫ | |||
+ | :: chosen by KDC enctypes (session key, etc); |
||
:: kdc request: |
:: kdc request: |
||
::: kdc options; |
::: kdc options; |
||
::: requested ticket start/end/renew_till times; |
::: requested ticket start/end/renew_till times; |
||
− | ::: requested |
+ | ::: requested enctypes; |
::: preauth types (on failure); |
::: preauth types (on failure); |
||
::: addresses; |
::: addresses; |
||
Line 49: | Line 53: | ||
====TGS exchange==== |
====TGS exchange==== |
||
− | :: [[#Ticket ID|ticket ID]] (if available); |
||
+ | =====Basic level===== |
||
− | :: KDC status message (“ISSUE” on success); |
||
+ | :: primary [[#Ticket ID|ticket ID]] (for example, TGT ticket ID) |
||
+ | :: derived [[#Ticket ID|ticket ID]] (on success, ticket ID of the newly created ticket) |
||
:: client’s address and port; |
:: client’s address and port; |
||
− | :: chosen by KDC |
+ | :: chosen by KDC enctypes; |
− | :: long-/short-term keys creation/manipulation/cleaning (Common Criteria FCS_CKM.1, FCS_CKM.4); |
||
− | :: referral realm name; |
||
− | :: alternate client principal (s4u, u2u); |
||
− | :: alternate server principal (referral or alternate TGT); |
||
− | :: u2u requested server principal; |
||
:: was ticket renewed; |
:: was ticket renewed; |
||
:: was ticket validated; |
:: was ticket validated; |
||
Line 58: | Line 63: | ||
::: requested service principal; |
::: requested service principal; |
||
::: client’s principal; |
::: client’s principal; |
||
+ | :: kdc reply: |
||
⚫ | |||
+ | =====Detailed level===== |
||
+ | :: was ticket renewed; |
||
+ | :: was ticket validated; |
||
+ | :: kdc request: |
||
::: addresses; |
::: addresses; |
||
::: requested/available enctypes; |
::: requested/available enctypes; |
||
::: KDC options; |
::: KDC options; |
||
⚫ | |||
::: requested ticket start/end/renew_till times; |
::: requested ticket start/end/renew_till times; |
||
:: kdc reply: |
:: kdc reply: |
||
::: client principal (on failure); |
::: client principal (on failure); |
||
::: preauth types (on failure); |
::: preauth types (on failure); |
||
⚫ | |||
+ | |||
+ | =====U2U and S4U===== |
||
+ | ::primary [[#Ticket ID|ticket ID]] |
||
+ | :: alternate client principal; |
||
+ | :: alternate server principal ); |
||
+ | :: u2u requested server principal; |
||
+ | :: kdc request: |
||
⚫ | |||
+ | |||
+ | =====Referrals===== |
||
+ | ::primary [[#Ticket ID|ticket ID]] |
||
+ | :: alternate server principal; |
||
+ | :: referral realm name; |
||
====Policy==== |
====Policy==== |
||
Line 82: | Line 104: | ||
::ticket key type. |
::ticket key type. |
||
+ | ====Secrets==== |
||
⚫ | |||
== Design details == |
== Design details == |
||
Line 94: | Line 118: | ||
(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 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 |
+ | 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 [[#Future work|this]] section. |
====Hybrid==== |
====Hybrid==== |
Revision as of 16:16, 5 June 2013
Contents
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
- ticket ID (on success);
- client’s principal;
- requested service principal;
- client’s address and port;
- chosen by KDC enctypes (session key, etc);
Detailed level
- KDC status message (on failure);
- chosen by KDC enctypes (session key, etc);
- kdc request:
- kdc options;
- requested ticket start/end/renew_till times;
- requested enctypes;
- preauth types (on failure);
- addresses;
- kdc reply:
- ticket;
- client principal (on failure);
- preauth types (on failure) .
TGS exchange
Basic level
- primary ticket ID (for example, TGT ticket ID)
- derived ticket ID (on success, ticket ID of the newly created ticket)
- client’s address and port;
- chosen by KDC enctypes;
- was ticket renewed;
- was ticket validated;
- kdc request:
- requested service principal;
- client’s principal;
- kdc reply:
- ticket (on success).
Detailed level
- was ticket renewed;
- was ticket validated;
- kdc request:
- addresses;
- requested/available enctypes;
- KDC options;
- requested ticket start/end/renew_till times;
- kdc reply:
- client principal (on failure);
- preauth types (on failure);
U2U and S4U
Referrals
- primary ticket ID
- alternate server principal;
- referral realm name;
Policy
- Policies violation when processing requests;
- AS request;
- TGS request;
- S4U2PROXY request.
Ticket details
- client and server principals;
- flags;
- start/end/renew_till times;
- authtime;
- transited encoding contents (for TGS only);
- ticket key type.
Secrets
- long-/short-term keys creation/manipulation/cleaning (Common Criteria FCS_CKM.1, FCS_CKM.4);
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.
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:
Key | Type | Comments |
---|---|---|
tkt_id | STR | ticket ID |
client | STR | client’s principal |
service | STR | requested service principal |
kdc_status | TR | KDC status (“ISSUE” on success) |
fromaddr | STR | client’s address |
fromport | NUM | client’s port |
full_address | STR | Alternative to "fromport"/"fromaddr" |
key_etypes | STR | chosen by KDC encryption types (session key, etc) |
xrealm | STR | referral realm name |
altc_princ | STR | alternate client principal (U2U, S4U) |
alts_princ | STR | alternate server principal (referral or alternate TGT) |
server2 | STR | u2u requested server principal |
tkt_renewed | BOOL | was ticket renewed |
tkt_validated | BOOL | was ticket validated |
req.addresses | STR | requested addresses |
req.avail_etypes | STR | requested/available enc types |
req.kdc_options | NUM | KDC options (forwardable, allow_postdate etc) |
req.pa_type | STR | preauth types |
req.tkt_start | NUM | requested ticket start time |
req.tkt_end | NUM | requested ticket end time |
req.tkt_renew_till | NUM | requested ticket renew-till time |
req.tkt_authtime | NUM | requested ticket authtime |
req.tkt_etype | NUM | requested ticket key type |
req.sectkt_cname | STR | client principal in the second ticket (U2U etc) |
req.sectkt_sname | STR | service principal in the second ticket |
req.sectkt_flags | NUM | second ticket flags |
req.sectkt_start | NUM | second ticket start time |
req.sectkt_end | NUM | second ticket end time |
req.sectkt_authtime | NUM | second ticket authtime |
req.sectkt_etype | NUM | second ticket key type |
req.sname | STR | requested service principal |
req.cname | STR | client's principal |
rep.sname | STR | service principal in ticket |
rep.cname | STR | client principal in ticket |
rep.pa_type | STR | reply preauth types |
rep.rep_flags | NUM | ticket flags |
rep.rep_authtime | NUM | ticket authtime |
rep.tkt_start | NUM | ticket start time |
rep.tkt_end | NUM | ticket end time |
rep.tkt_renew_till | NUM | ticket renewed-till time |
rep.tkt_etype | NUM | ticket key type |
rep.tr_contents | STR | ticket transited-realms list |
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
- Standardize a Ticket_ID;
- Make reporting auditable events configurable. For example, one can choose to report TGS_REQ, but not AS_REQ etc;
- Define and make configurable the DETAILED and BASIC levels of the events;
- 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
- Common Criteria for Information Technology Security Evaluation http://www.commoncriteriaportal.org/files/ccfiles/CCPART2V3.1R4.pdf
- Oracle Solaris Auditing http://docs.oracle.com/cd/E19963-01/html/821-1456/auditov-1.html
- Understanding Linux Audit http://doc.opensuse.org/products/draft/SLES/SLES-security_sd_draft/cha.audit.comp.html
- Advanced Security Audit Policy Settings http://technet.microsoft.com/en-us/library/dd772712(v=ws.10).aspx
- Events Classification in Log Audit http://airccse.org/journal/nsa/0410ijnsa5.pdf
- CEE Log Syntax (CLS) Encoding http://cee.mitre.org/language/1.0-beta1/cls.html