We use the Backus-Naur Form to denote the elements of our policy language.
Curly brackets, {}, surround items that can repeat zero or more times.
A vertical line, |, separates alternatives. Items inside double quotes
are the terminal symbols.
An EACL is specified according to the following format:
eacl ::= {eacl_entry}
eacl_entry ::= pos_access_right conditions | neg_access_right conditions
pos_access_right ::= "pos_access_right" def_auth value
neg_access_right ::= "neg_access_right" def_auth value
conditions ::= pre_conds mid_conds rr_conds post_conds
pre_conds ::= {condition}
mid_conds ::= {condition}
rr_conds ::= {condition}
post_conds ::= {condition}
condition ::= cond_type def_auth value
cond_type ::= alphanumeric_string
def_auth ::= alphanumeric_string
value ::= alphanumeric_string
cond_type defines the type of condition, e.g., access identity or time.
def_auth indicates the authority responsible for defining the value within the cond_type, e.g., Kerberos.
value is the value of condition. Its semantics is determined by the cond_type field. The name space for the value is defined by the def_auth field.
It should be pointed out that the EACL language description presented here is not complete. Our current framework supports flexible policy composition model. The discussion of this issue is beyond the scope of this paper.
Next we present an example of an EACL that governs access to a host.
Entry 1 specifies that Tom can not login to the host.
Entries 2 and 3 mean that logins from the specified IP address range are permitted, using either X509 or Kerberos for authentication if the number of previous login attempts during the day does not exceed 3. If the request fails, the number of the failed logins for the user should be updated. The connection duration time must not exceed 8 hours.
Entry 4 means that anyone, without authentication, can check the status of the host if he connects from the specified IP address range.
Entry 5 specifies that host shut downs are permitted, using Kerberos
for authentication.
If the request succeeds, the user ID must be logged.
If the operation fails, the sysadmin must be notified by e-mail.
# EACL entry 1
neg_access_right test host_login
pre_cond_access_id KerberosV.5 tom@ORGB.EDU
# EACL entry 2
pos_access_right test host_login
pre_cond_location IPsec 10.1.1.0-10.1.200.255
pre_cond_access_id X509
"/C=US/O=Trusted/OU=orgb.edu/CN=partnerB"
pre_cond_threshold local 38#383failures/day/failed_log/
rr_cond_update_log local on:failure/failed_log/info:userID
mid_cond_duration local 38#388hrs
# EACL entry 3
pos_access_right test host_login
pre_cond_location IPsec 10.1.1.0-10.1.200.255
pre_cond_access_id KerberosV.5 partnerb@ORGB.EDU
pre_cond_threshold local 38#383failures/day/failed_log/
rr_cond_update_log local on:failure/failed_log/info:userID
mid_cond_duration local 38#388hrs
# EACL entry 4
pos_access_right test host_check_status
pre_cond_location IPsec 10.1.1.0-10.1.200.255
# EACL entry 5
pos_access_right test host_shut_down
pre_cond_access_id KerberosV.5 trusted@ORGA.EDU
rr_cond_audit local on:success/info:userID
post_cond_notify local email/to:sysadmin/on:failure