Authentication Protocols

• Registration phase
  • grant new access priviledge
  • within a organisation
• Authentication phase
• Credential renewing phase
• De-Registration phase

• Passive Attacken
  • Offline guessing, Dictionary attacks
• Active Attack Resistance
  • Impersonation attacks on Prover or Verifier
  • Man-in-the-Middle and replay attacks
  • Hijacking attacks
  • Online guessing attacks
• Verifier Impersonation Resistance
  • Privileged Insider attack
• Verifier Compromise Resistance
  • Stolen Verifier Database
  • Endpoint Compromise

An attacker captures an authentication protocol run and analyzes the messages to identify the correct shared secret.

Man-In-The-Middle

• Man-In-The-Middle with ARP or DNS Spoofing

Replay

• Authentication protocol messages are captured and retransmitted to gain access to a service as a legitimate subscriber

Hijacking

• Übernehmen einer Session nach erfolgreichem Login (Authentication)

Online guessing

• Online dictionary attacks used to guess memorized secrets

If a privileged-insider of V1 has the knowledge of the pw and the ID of the prover, he may try to access other verifiers V2, V3, . . . , Vn by using the same pw and ID.

Stolen-verifier database

• The attacker applies an off-line guessing attack on the stolen user credential database to get User ID and password and hence impersonate as a legitimate subscriber of interest.

Endpoint compromise

• Malicious code proxies authentication or exports authenticator keys from the endpoint.

• Easy to sniff
• If use with TLS, vulnarable against replay attacks

To avoid replay attacks we need a dynamic components, the two main methods are none or time-stamps

time-stamps allows to check it for freshness

• Long Term Key only with KDC, that gives a session key to communicate
• Single Sign-On
• Authenticated session key
• Secrecy of a session key
• Freshness of a sessioj key

KDC

• AS (Authentication Server)
  • Use Long term Key to Authenticate and get a short term TGS-ticket (TGT)
  • The TGT is valid for multiple requests to the TGS
• TGS (Ticket granting Server)
  • Use the TGS-ticket to get a Ticket from TGS to get access to the Server

Server

• Access the Server with the Ticket from TGS

Realm

• The domain of the authority of the Kerberos server, Clients and Servers

Principal

• A user or service participating in a Kerberos realm
• principal has format: name[/instance]@REALM
• All participants in a Kerberos realm have a long-term key which they define or receive during initial registration

Ticket

• Temporal digital certificate, which represents the identity of a principal for a given time

Kerberos Authentication Process

• Authenticate and get TGT

Ticket Granting Service Request

• Get Ticket from TGS with using TGT

Client Service Request

• Request to Service/Server using Ticket from TGS

• KDC security:
  • The KDC has access to the keys of all principals and thus is critical for the security of Kerberos. The KDC must be kept secure, both from a physical and network point of view.
• Ticket revocation:
  • Ticket granting tickets stay valid until they expire, typically 10 hours. What if compromised in meantime?
• Clock synchronization:
  • Timestamps are needed to protect against replay attacks. Recent messages will becached for a certain time (e.g. 5 min).
• Key storage:
  • Session keys and ticket granting tickets must not be located in unprotected host environments.

The "initial" flag:

• indicates that a ticket was issued using the AS protocol, rather than issued based on a ticket-granting ticket. Important for a password-changing program.

The "pre-authent" flag:

• indicates that some sort of preauthentication was used during the AS exchange.

The "hw-authent" flag:

• indicates that some sort of hardware-based preauthentication occurred during the AS exchange.

The "invalid" flag:

• indicates that a ticket is invalid. Application servers MUST reject tickets which have this flag set. A postdated ticket will be issued in this form.

The "renewable" flag:

• indicates whether the ticket may be renewed. A client must periodically present an unexpired renewable ticket to the KDC, setting the "renew" option in the KDC request. The KDC will issue a new ticket with a new session key and a later expiration time. The "renewable" flag in a ticket is normally only interpreted by the ticket-granting service. If a renewable ticket is not renewed by its expiration time, the KDC will not renew the ticket. The "renewable" flag is clear by default, but a client can request it be set by setting the "renewable" option in the AS-REQ message. If it is set, then the "renew-till" field in the ticket contains the time after which the ticket may not be renewed.

The "postdated" flag:

• indicates that this ticket is intended for later use. Applications may occasionally need to obtain tickets for use much later

The “proxy” flag:

• allows a client to pass a proxy to a server to perform a remote request on its behalf (e.g. a print service client can give the print server a proxy to access the client's files on a particular file server in order to satisfy a print request). tem would need tickets to be valid at the time the batch job is serviced.

The “forwardable” flag:

• indicates that forwarded tickets may be issued based on this ticket. It has an interpretation similar to that of the "proxiable" flag, except ticketgranting tickets may also be issued with different network addresses. This flag allows for authentication forwarding without requiring the user to enter a password again.

• output ih highly dependant of the specific cryptographic device
• In general is a kind of "signed" messages
• The cryptographic device have to do a challenge with signing something and response this

• shared-secret based
  • Hash algorithm
  • Symmetric cipher
  • HMAC
• private/public key based
  • Digital Signature

This protocol is vulnerable against an 'adaptive chosen plaintext attack'!!!

Thus, a key-pair used for Non Repudiation SHALL NOT be used for authentication purpose.

• Instead of a symmetric cipher, we may use asymmetric cryptography for authentication purposes.
• Rather than a shared secret key, the Verifier needs to have an authenticated version of Peggy’s public key only.
• In private/public-key based authentication protocols there is no need to store or transmit shared secrets on/to server side.
• A CSP may issue a credential in form of a certificate. The subscriber may present the credential during the authentication process together with the provable authenticator output. The credential may also be stored in the user database at verifier side.

may be implemented for mutual authentication, but vulnerable to Reflection Attacks and increased sensitivity to ‘Denial of Service’ attacks

CRAM standard for start a session can be hijacked at this point

What if a secure session is needed after authentication?

• We have to bind a session key to the CRAM.

Establishing a private and authenticated channel on top of an insecure network solely based on a shared password

• No need of trusted third party (e.g. KDC) to establish a session key tied to an authentication protocol.
• No user-specific credentials are passed over the network open to attacks. Someone who tries to tamper or just eavesdrop a protocol run cannot gain useful information (e.g. for dictionary attack).
• The lack of DH-Exchange missing authentication of entities can be solved.
• Potentially weak passwords get expanded to a fresh random session key.

• Often called Zero Knowledge Password Proof (ZKPP).
• Amplifies weak passwords into strong session keys.
• Enables Authenticated DHKE based on shared secret.
• Resistant against:
  • Offline dictionary attacks: Does NOT leak any information for passive/active attackers to allow offline-exhaustive search to find private secrets.
  • On-line dictionary attacks: It gives an active attacker only one chance to test the private secret per protocol.
  • Known-session key and forward secrecy: keeps session keys of already established sessions secure, even the shared secret shall be leaked some day.

1. Alice and Bob agree to use an appropriately large and randomly selected safe prime p, as well as a hash function H().
2. Alice and Bob agree on a shared password π.
3. Alice and Bob both construct g = H(π)² mod p. (Squaring makes g a generator of the prime order subgroup of the multiplicative group of integers modulo p.)
4. Alice chooses a secret random integer a, then sends Bob g^a mod p.
5. Bob chooses a secret random integer b, then sends Alice g^b mod p.
6. Alice and Bob each abort if their received values are not in the range [2,p-2], to prevent small subgroup confinement attack.
7. Alice computes K = (g^b mod p)^a mod p.
8. Bob computes K = (g^a mod p)^b mod p.

The difference between balanced and augmented PAKE is that augmented PAKE does not store password-equivalent data

VPAKE is a variation in which the server does not store password-equivalent data. A VPAKE protocol provides extra protection for server compromise in the sense that an attacker, who obtains a password verifier from a server, cannot impersonate the corresponding user without performing a cryptographical effort on the password verifier database. This additional security is known as "resistance to server compromise". This means that an attacker that may has stolen the server data still cannot masquerade as the client unless it performs at least a brute force search for all possible passwords.

SRP (TLS, EAP, SAML)

With a ZKP you can convince another party of the fact that a (usually mathematical) statement is true, without revealing anything other than the correctness of the statement.