Shibboleth is an open source federated SAML implementation. It layers on the concept of a (optional) “discovery service” that is used to determine a user’s IdP across organizational boundaries. Apparently tricky to configure.
Kerberos uses symmetric keys for protocol encryption. Kerberos uses TCP/UDP 88, though UDP is preferred except for large tickets; UDP (?) 749 is used for administrative access.
Kerberos differs from protocols previously discussed in that the client initially sends authentication information directly to the KDC (“key distribution center”) server, rather than working through the actual resource server. A quick sketch of the Kerberos authentication process:
The client begins by contacting the “certificate authority” (CA… but not the same kind of CA as in PKI).
The CA provides a session key containing the issuing timestamp and expiration timestamp (typically 8 hours in the future) + information regarding user authorization. The first of these is encrypted with the client’s key, but the second of these is encrypted with a long-term secret known only to the KDC. The encrypted bit that the client can’t read is the “ticket granting ticket” (TGT).
The client submits the TGT to the “ticket granting server” (TGS), which decrypts it, verifies access, and then returns an actual service ticket (containing issued at and expires at timestamps) encrypted with the key of the service the client wishes to access. Again, the client cannot read the service ticket, but can read a separate message containing a key that will be used to communicate with the service (this key is contained within the service ticket as well).
The client sends the service the service ticket (which it can’t read) and an additional message encrypted with the service key provided by the TGS (that the service initially can’t read).
The service decrypts the service ticket, uses the information there to decrypt the client message, and then compares the client’s attested ID with the client ID in the service ticket, as well as the provided timestamps. If everything checks out, the service responds back with the same timestamp that the client provided in its message, encrypted with the TGS service key (which it now knows). Exam Cram notes that this timestamp information returned by the service is provided by the KDC, though I haven’t run into that wrinkle in my previous readings about the Kerberos authentication process.
The client verifies the timestamp returned by the service, confirming that the service knows the correct session key.
Client and service are now authenticated to each other.
A more detailed sketch is provided in my notes in “A Hacker’s Notes”.
The idea with Kerberos is to have a short enough ticket validity lifespan that cryptographic attacks are infeasible, and the entire process doesn’t require any direct exchange of passwords. The extensive use of timestamps effectively prevent replay attacks (Exam Cram notes the importance of time synchronization between all systems in an environment using Kerberos).
Unfortunately, the most common Kerberos implementation is Active Directory, which uses NTLM hashes as its secrets and allows for stored “pre-autheticated” tickets that bypass the KDC. This allows for serious side-channel attacks. Kerberos 5 tries to mitigate these attacks by having client and service authenticate each other with challenge codes (“mutual authentication”), but this only prevents on-the-wire MITM attacks, not attacks that harvest tickets from client machine directly (like Rubeus and Mimikatz).
ACCESS CONTROL: The process by which resources are made available only to those entities that should have access (and access is denied to all others).
Types of access controls:
MANDATORY ACCESS CONTROL (MAC): Entities and objects are labeled in some way (for example, “public”, “secret”, “top secret”, etc.), and access is only granted with the labels match. Sometimes called “multilevel access control”, since in theory multiple labels can be applied.
DISCRETIONARY ACCESS CONTROL (DAC): Has object owners assign access rights on an ad hoc basis based (but only for their objects). This is the model used in, for example, Google Drive.
RULE-BASED ACCESS CONTROL (RBAC): Entities are dynamically assigned access based upon rules defined by either the object owner or systems administrator. Typically these rules specify things like time of day, user location, etc. Think of Google Workspace’s “Context-Aware Access”.
ROLE-BASED ACCESS CONTROL (RBAC): Also known as RBAC, this involves assigning access based upon entity membership in a group/role. Google Workspace admins are managed in this way, and groups can be used to provide similar functionality at the user level. Role-based access control is easier to manage than rule-based or discretionary access control, but doesn’t offer the flexibility of rule-based controls.
ATTRIBUTE-BASED ACCESS CONTROL (ABAC): This is a specific access control definition used within the US federal government. Itis similar to rule-based access control in that it defines a set of attributes that an entity must match in order to access an object in an XML-derived format (the “Extensible Access Control Markup Language”, or XACML). However, the list of attributes can be quite detailed, which allows ABAC to also enforce DAC and MAC models.
If I read all of this right, ABAC is a way of implementing access control, rather than a type of access control.
Note that the “Trusted Computer System Evaluation Criteria” (TCSEC) specification (a.k.a., the “Orange Book”) only defines the use of MAC and DAC.