Security Protocols

Protocol

A protocol consists of a set of rules that determine the exchange of messages between two or more principals.

Link to original

Security protocol

Security protocols use cryptographic mechanisms to achieve security objectives.

Link to original

Building a key establishment protocol

Not examined, slides lec 1. 8-32.

Syntax for messages, communication, protocols

Message syntax (cryptography)

Messages

• Names: $A,B$ or Alice, Bob, etc
• Keys: $K$ and inverse keys $K^{-1}$
  • Encryption $\{M{\}}_K$, e.g. encryption with $A$‘s public key: $\{M{\}}_{K_A}$
  • Signing $\{M{\}}_K^{-1}$, e.g. signing with $A$‘s public key: $\{M{\}}_{K_A^{-1}}$
  • Symmetric keys $\{M{\}}_{K_{AB}}$
• Nonces: $NA,N1,\dots$ Fresh data items used for challenge / response.
• Timestamps: $T$ Denote time, e.g. used for key expiration.
• Message concatenation: $M_1,M_2$

Example of a message: $\{A,T_1,K_{AB}{\}}_{K_B}$

Link to original

Communication syntax (cryptography)

Communication is a fundamental event between principals.

$$A\to B:\{A,T_1,K_{AB}{\}}_{K_B}$$

• $A$ and $B$ name roles. Can be instantiated by any principal playing in the role.
• Communication is asynchronous (depends on semantic model).
• Sender / receiver names are not part of the message.
• Protocol specifies actions of principals.

Link to original

Protocol syntax (cryptography)

Protocols A typical protocol description combines prose, data type specifications, various diagrams, ad hoc notations, and message sequences like:

$$\begin{array}{rl}1.A\to B:& \{N1,A{\}}_{K_B}\\ 2.B\to A:& \{N1,N2{\}}_{K_A}\\ 3.A\to B:& \{N2{\}}_{K_B}\end{array}$$

Often includes informal statements concerning properties and why they should hold.

Link to original

Example: Needham-Schroeder Public Key (NSPK) protocol

Needham-Schroeder Public Key (NSPK) protocol

The goal of NSPK is for mutual authentication, in effect:

• Alice chooses a nonce ($NA$) and sends it to Bob.
• Bob sends the nonce back (and since he could read it he must be Bob), but be also adds a challenge nonce ($NB$) and sends it back.
• Alice sends back the challenge nonce, since only Alice can read it and he sent it back, it must be Alice that he is talking to.

$$\begin{array}{rl}1.A\to B:& \{NA,A{\}}_{K_B}\\ 2.B\to A:& \{NA,NB{\}}_{K_A}\\ 3.A\to B:& \{NB{\}}_{K_B}\end{array}$$Link to original

Each principal executes a "protocol automation", e.g. Alice in role A

• State $s_1$:
  • Generate nonce $NA$ pair with name and encrypt with $K_{\text{bob}}$.
  • Send $\{NA,Alice{\}}_{K_{\text{bob}}}$ to Bob.
  • Goto state $s_2$.
• State $s_2$:
  • Receive message $C$ and decrypt it: $M=D_{K_{\text{Alice}}^{-1}}(C)$
  • If $M$ is not of the form $\{NA,X\}$ for some nonce $X$, then goto reject state else goto state $s_3$.
• State $s_3$: …
• State reject: terminate with failure

NB. principals can be engaged in multiple runs => multiple automata

Assumptions

• Principals know their private keys.
• Principals know public keys of others.
• Principals can generate nonces.

Goals (what the protocol can achieve)

• Authenticate messages, binding them to their originator
• Ensure timeliness of messages (recent, fresh, etc)
• Guarantee secrecy of certain items

Dolev-Yao attacker model

The Dolev-Yao attacker (/ intruder) model is a standard list of strong assumptions about an attacker, which protocols shown secure in respect to means they would work in a large range of environments:

• Attacker can intercept and read all messages
• Attacker can decompose messages into their parts (cryptography is secure and decryption requires inverse keys)
• Attacker can build new messages with different constructors
• Attacker can send messages at any time

Link to original

MITM attack on NSPK

$C$ decrypts the initial message and re-encrypts it with $B$‘s public key. $B$ is led to believe he is speaking with $A$. The problem in step 2 is that agent $B$ should also provide his name.

NSL Protocol

Let’s suppose we include $B$‘s name in the second step: $A$ can now abort the protocol execution / ignore the message.

It is now secure against this attack but may still be vulnerable to replay attacks among other things.

Examples of protocols and possible vulnerabilities

Not examined, slides lec 1. 51-52, 57-83.

Prudent engineering of security protocols

Not examined, slides lec 1. 85-87.

The Kerberos Protocol

Kerberos Protocol

The Kerberos protocol is a network authentication protocol.

Link to original

Protocol requirements

Kerberos protocol requirements

• Secure: an eavesdropper should not be able to impersonate users
• Reliable: many services depend on Kerberos for access control, must be highly reliable and support a distributed architecture where one system can back up another
• Transparent: each user should enter a single password to obtain network services and should be unaware of underlying protocols. (these days referred to as single sign-on)
• Scalable: system should scale to support large numbers of users and servers; this suggests a modular, distributed architecture

Link to original

Kerberos (v4) Architecture

Kerberos (v4) architecture

Authentication using the Kerberos Authentication Server (KAS). Authorization using the Ticket Granting Server (TGS).

Link to original

Kerberos (v4) Operation

Kerberos (v4) operation

Link to original

Kerberos (v4) Protocol

Kerberos (v4) protocol

Authentication phase

1. $A\to \text{KAS}$: $A,\text{TGS}$
2. $\text{KAS}\to A:\{K_{A,\text{TGS}},\text{TGS},T_1,\underset{\text{AuthTicket}}{\underbrace{\{A,\text{TGS},K_{A,\text{TGS}},T_1{\}}_{K_{\text{KAS}},\text{TGS}}}}{\}}_{K_{\text{AS}}}$

• $A$ logs onto workstation and requests network resources.
• $\text{KAS}$ accesses database and sends $A$ a session key $A,\text{TGS}$ and an encrypted ticket $\text{AuthTicket}$.
• $K_{A,\text{TGS}}$ has lifetime of several hours (depending on application) as specified by timestamp $T_1$. $K_{\text{AS}}$ is derived from user’s password. Both user and server keys must be registered in database.
• $A$ types password on workstation to decrypt results, which are stored for session. $A$ is logged out when $K_{A,\text{TGS}}$ expires.

Authorization phase 3. $A\to \text{TGS}:\underset{\text{AuthTicket}}{\underbrace{\{A,\text{TGS},K_{A,\text{TGS}},T_1{\}}_{K_{\text{KAS}},\text{TGS}}}},\underset{\text{authenticator}}{\underbrace{\{A,T_2{\}}_{K_{A,\text{TGS}}}}},B$ 4. $\text{TGS}\to A:\{K_{AB},B,T_3,\underset{\text{ServTicket}}{\underbrace{\{A,B,K_{AB},T_3{\}}_{K_B,\text{TGS}}}}{\}}_{K_{A,\text{TGS}}}$

Before $A$‘s first access of resource managed by the server $B$:

• $A$ presents $\text{AuthTicket}$ from message $2$ to $\text{TGS}$ together with a new $\text{authenticator}$ with a short liftetime as specified by $T_2$.
  • The authenticator prevents replay attacks by having a short validity.
  • Servers store recent authenticators to prevent immediate replay attacks.
• $\text{TGS}$ issues $A$ a new session key $K_{\text{AB}}$ (with a lifetime of a few minutes as specified by $T_3$) and a new ticket $\text{ServTicket}$ where $K_{B,\text{TGS}}$ is a key shared between $\text{TGS}$ and $B$.

Service phase 5. $A\to B:\underset{\text{ServTicket}}{\underbrace{\{A,B,K_{AB},T_3{\}}_{K_B,\text{TGS}}}},\underset{\text{authenticator}}{\underbrace{\{A,T_4{\}}_{K_{A,\text{TGS}}}}}$ 6. $B\to A:\{T_4+1{\}}_{K_{AB}}$

For $A$ to access resources managed by $B$:

• $A$ presents a ticket from $4$ to $B$ along with a new authenticator.
• $B$ replies (optional), authenticating service.

Link to original

Scalability / Multiple Realms / Kerberi

Realm (Kerberos)

A realm is defined by a Kerberos server, it stores user and application server passwords for the realm.

A large network may be divided into administrative realms. Kerberos supports inter-realm protocols where servers register with each other. For $A$ to access $B$ in another realm, the TGS in $A$‘s realm receives a request and grants a ticket to access TGS in $B$‘s realm.

Link to original

Limitations of Kerberos (v4)

Kerberos (v4) limitations

• Encryption is not needed, but attacker can flood $\text{KAS}$ $A\to \text{KAS}:A,\text{TGS}$
• Double encryption is redundant (eliminated in Kerberos 5) $\text{KAS}\to A:\{K_{A,\text{TGS}},\text{TGS},{\mathcal{T}}_1,\{A,\text{TGS},K_{A,\text{TGS}},{\mathcal{T}}_1{\}}_{K_{\text{KAS,TGS}}}$
• Relies on synchronised and un-compromised clocks. If the host is compromised, clock can be manipulated for replay attacks.

Link to original