Notes - MCS
Identification, Authentication and Authorization
Notes - MCS
Identification, Authentication and Authorization
  • Identification, Authentication and Authorization
  • Access Control Models
    • Access types
    • Least privilege principle
    • Access control models
      • Access control kinds
    • Access control kinds
    • Separation of duties
    • Segregation of duties
    • Information flow models
    • Multilevel security
    • Windows mandatory integrity control
    • Clark-Wilson Integrity Model
  • OAuth 2.0 Authorization Framework
    • Goal
    • Roles (RFC 6749)
    • Communication endpoints
    • Application (client)
    • OAuth tokens
    • OAuth flows
      • Code flow
      • Implicit flow
      • Resource owner password flow
      • Client credentials flow
    • Proof Key for Code Exchange (PKCE, RFC 7636)
    • Device authorization grant (RFC 8628)
    • Actual protocol flow
  • Linux Security Mechanisms
    • Mechanisms
    • Linux management privileges
    • Privilege Elevation
    • Capabilities
    • Files extended attributes (xattr)
    • File capabilities
    • Capability transfer across exec
    • Control groups (cgroups)
    • Linux Security Modules (LSM)
    • AppArmor
    • Confinement
  • Authentication Protocols
    • Identity attributes
    • Authentication
    • Authentication interactions
    • Authentication of people
      • Biometrics
      • Token-based OTP generators
      • PAP & CHAP (RFC 1334, 1992, RFC 1994, 1996)
      • S/Key (RFC 2289, 1998)
      • GSM
    • Host authentication
    • Service/server authentication
    • TLS (Transport Layer Security, RFC 8446)
    • SSH (Secure Shell, RFC 4251)
    • Single Sign-On (SSO)
    • Authentication metaprotocols
    • Authentication services
    • Key distribution services
  • PAM (Pluggable Authentication Modules)
    • Motivation
    • PAM
    • PAM APIs
    • Orchestration of PAM actions
    • Module invocation
    • Configuration files
    • PAM orchestration files
    • Scenario 1 – Local authentication
    • Scenario 2 – LDAP auth with local backoff
    • Scenario 3 – MS AD auth with local backoff
  • FIDO and FIDO2 framework
    • FIDO (Fast Identity Online) Alliance
    • Universal 2nd Factor (U2F) protocol
    • WebAuthn
    • Client to Authenticator Protocol (CTAP)
    • Passkeys
  • Authentication with Trusted Third Parties / KDCs
    • Shared-key authentication
    • Key Distribution Center (KDC) concept
    • Kerberos
  • Identity Management
    • Digital Identity
    • Identity Manager (IdM)
    • Identity Provider (IdP)
    • Authoritative source
    • Identity claim
    • Approachs
    • Credential
    • Privacy issues
    • Verifiable credential (VC)
    • Self-Sovereign Identity (SSI)
    • Interoperability
    • eIDAS
  • Anonymity and Privacy
    • Privacy
    • IEEE Digital Privacy Model
    • Privacy with computing technology
    • Privacy and companies
    • Privacy and IAA
    • Identification
    • Authentication
    • Anonymity
    • Microdata privacy issues
    • Microdata privacy enhancing
    • L-Diversity
Powered by GitBook
On this page
  • Goals
  • Background: Needham-Schroeder (1978)
  • Architecture and base concepts
  • Two Kerberos KDC services
  • Entities (principals)
  • Authentication elements
  • Tickets and authenticators
  • Ticket
  • Authenticator
  • Overview of Kerberos SSO
  • 1º Step: Login
  • 2nd step: Authenticated access to servers
  • Protocol (of version V5)
  • Pre-authentication alternative
  • Scalability
  • Authentication scope
  • Inter-realm cooperation
  • Protocol
  • Security politics and mechanisms
  • Entity authentication
  • Validity periods
  • Replay protections
  • Protection against an excessive use of session keys
  • Delegation (proxying)
  • Inter-real authentication
  • Security issues
  • Actual availability
  1. Authentication with Trusted Third Parties / KDCs

Kerberos

Goals

Authenticate peers in a distributed environment.

  • Targeted for Athena (at MIT)

Distribute session keys for adding security to sessions between peers.

  • Authentication (the initial goal)

  • Confidentiality (optional)

Single Sign-On.

  • Only one password to remember

  • Daily use (typically)

Background: Needham-Schroeder (1978)

A and B trust on a common Key Distribution Center (KDC).

KDC shares a key with every A and B. Central authentication authority.

KDC generates good (random) KabK_{ab}Kab​ keys.

  • Directly imported by requesters

  • Indirectly obtained by targets

Architecture and base concepts

Two Kerberos KDC services

  • Authentication Service (AS)

  • Ticket Granting Server (TGS)

Entities (principals)

  • All have a secret shared with Kerberos (AS or TGS)

  • People: a key derived from a password:

    • KUK_UKU​ = hash(password)

    • Services/servers: key stored in some repository.

  • Requisites

    • Clocks (very well) synchronized.

Authentication elements

  • Ticket: required to request a service.

  • Authenticator: proof of the identity of a requester.

Tickets and authenticators

Ticket

Unforgeable piece of data.

It can only be interpreted by the target service.

Carries the identities of the client that can use it.

Carries a session key.

Carries a validity timestamp.

Authenticator

Carries a timestamp of the request.

Carries the identity of the client.

Proves that the client knows the session key.

Overview of Kerberos SSO

1º Step: Login

Location of the Kerberos servers of the realm.

Authentication of user U by Kerberos (AS).

  • The user gets a Ticket Granting Ticket (TGT) and a session key (KTGTK_{TGT}KTGT​) for interacting with another Kerberos service (TGS).

  • The TGT can be used to request other tickets needed by the user U to access every service S.

2nd step: Authenticated access to servers

U requests Kerberos (TGS) a ticket for accessing S.

  • U uses TGT in the request.

  • U must prove that he is the owner of TGT.

  • U gets a session key (KUS)(K_{US})(KUS​) and a ticket to S (TUS)(T_{US})(TUS​).

U uses (TUS)(T_{US})(TUS​) to make authenticated requests to S.

  • Server S uses TUST_{US}TUS​ to check the identity of U.

  • U must prove that he is the owner of TUST_{US}TUS​.

Protocol (of version V5)

Pre-authentication alternative

Vulnerable to proactive dictionary attacks! (Kerberoasting).

Scalability

Authentication scope

Realms.

A kerberos server per realm.

Inter-realm cooperation

Fundamental to allow a client from a realm to access a server in another realm.

Realms need to trust authentication performed by other realms.

Protocol

Secret keys are shared between TGS servers of different realms.

  • Inter-realm key.

  • Each inter-realm key is associated with a trust path.

A client (user) needs to jump from TGS to TGS to get a ticket.

  • Not particularly user-friendly.

Security politics and mechanisms

Entity authentication

Secret keys, names, and network addresses.

name/instance@realm (user@ua.pt, ftp/ftp.ua.pt@ua.pt).

Validity periods

Timestamps in tickets (hours).

Timestamps in authenticators (seconds, minutes).

Replay protections

Nonces (in ticket distributions).

Timestamps / sequence numbers (in authenticators).

Protection against an excessive use of session keys

Key distribution in authenticators.

Delegation (proxying)

Options and authorizations in tickets.

Inter-real authentication

Secret keys shared among TGS services, trust paths.

Ticket issuing from a TGS to another TGS.

Security issues

Kerberos KDC can impersonate anyone. Needs maximum security in its administration.

Kerberos KDC may be a single point of failure. Replication is an option since stored keys are seldom updated.

A stolen user password allows others to impersonate the victim in every service of the realm. Stolen TGS credentials are less risky, as their validity is shortly limited (one day, usually).

Actual availability

Windows versions

  • Windows 2000 adopted Kerberos for inter-domain authentication.

  • Kerberos was modified to accommodate Windows credentials.

Components

  • Kerberos servers/daemons.

  • Libraries for “kerberizing” applications.

  • Support applications.

    • klogin, kpasswd, kadmin.

  • Kerberized applications (clients and servers).

Last updated 1 year ago

MIT releases