# Real life security protocal
## SSH (Secure Shell)

$certificate_A$ = Alice's certificate
$certificate_B$ = Bob's certificate
CP = crypto proposed
CS = crypto selected
$H = h(Alice, Bob, CP, CS, R_A, R_B, g^a\ mod\ p, g^b\ mod\ p, g^{ab}\ mod\ p)$
$S_B = [H]_{Bob}$
$K = g^{ab}\ mod\ p$
$S_A=[H, Alice, certificate_A]_{Alice}$


## SSL
- Secure socket layer
- On-sided authentication

- Alice ***encrypts*** $E(h(msgs, CLNT, K), K)$ only for integrity check purposes. It adds no secrurity.
- If you really want **Mutual authentication**, the server could send a certificate request

## IPSec
- Lives on the network layer (part of the OS)
- Encryption, integrity, authentication, etc.
- Very complex

## Kerberos
- TTP: Trusted Third Party
- Authentication using public keys
- N users => N key pairs
- Authentication using symmetric keys
- N users => $O(N^2)$ keys
### Scalibility
- Symmetric key case **does not scale**!
- Kerberos based on symmetric keys but only requires N keys for N users
- SEcurity depends on TTP

### Key Distribution Center (KDC) acts as the TTP
- KDC share symmetric key $K_A$ with Alice, key $K_B$ with Bob, etc.
- Master key $K_{KDC}$ known ***only*** to KDC
- KDC enables authentication, session keys
- Session key for confidentiality and integrity

### Kerberos Tickets
- KDC issue **tickets** containing info needed to access network resources
- KDC also issues **Ticket-Granting Tickets*** or **TGTs** that are used to abotain tickets
- Each TGT contains
- Session key
- User's ID
- Expiration time
- Every TGT is encrypted with $K_{KDC}$
- The tickets make the server stateless (server doesn't have to store user's information)

### Kerberized Login
- Alice enters her password
- Then Alice's computer
- Derives $K_A$ from Alice's password
- Uses $K_A$ to get TGT for Alice from KDC
- Alice then uses her TGT(credentials) to securely access network resources
- Plus: Security is transparent to Alice
- Minus: KDC *must* be secure -- it's trusted!