CSCE 465 Lecture 25

« previous | Tuesday, April 23, 2013 | next »

Key Distribution Center

Needham-Schroeder Protocol

Classic protocol for authentication with KDC

• Kerberos Modeled after it

nonce: number that is used only once (prevents replay attacks)

1. Alice wants to talk to Bob, so she sends a Nonce $N_{1}$ and request to KDC
2. KDC generates $K_{\text{Alice}}\{N_{1},{\text{``Bob''}},K_{AB},K_{\text{Bob}}\{K_{AB},{\text{``Alice''}}\}\}$
3. Alice sends ticket $K_{\text{Bob}}\{K_{AB},{\text{``Alice''}}\}$ and $K_{AB}\{N_{2}\}$ to Bob
4. Bob sends back $K_{AB}\{N_{2}-1,N_{3}\}$
5. Alice responds $K_{AB}\{N_{3}-1\}$

Expanded Needham-Shroeder Protocol

1. Alice contacts Bob first
2. Bob sends back an initiated nonce $N_{B}$ (Next time you talk to me, use this number; puts timestamp on Bob's Ticket so it cannot be reused by attacker if it is figured out)
3. Alice wants to talk to Bob, so sends a Nonce $N_{1}$ and request to KDC, supplying Bob's Nonce $K_{\text{Bob}}\{N_{B}\}$ as well
4. KDC generates $K_{\text{Alice}}\{N_{1},{\text{``Bob''}},K_{AB},K_{\text{Bob}}\{K_{AB},{\text{``Alice''}},N_{B}\}\}$
5. Alice sends ticket $K_{\text{Bob}}\{K_{AB},{\text{``Alice''}},N_{B}\}$ and $K_{AB}\{N_{2}\}$ to Bob
6. Bob sends back $K_{AB}\{N_{2}-1,N_{3}\}$
7. Alice responds $K_{AB}\{N_{3}-1\}$

This is a bit long, so there's shorter protocols that have been developed

SSL/TLS

Last Slides! But first, fill out course evaluations (already done)

What Layer are we talking about?

• IPSec between IP and TCP/UDP layers
• SSL is between TCP and Application layers

SSL Services

• Peer authentication
• Negotiation of security parameters
• generation/distribution of session keys
• Data confidentiality
• Data security

Exactly what we want in a web browser.

Connections vs. Sessions

SSL Session

An association between peers

created through a handshake, negotiates security parameters, and can be long-lasting

A single session could span multiple connections

SSL Connection

A type of service (i.e. an application)

Session Parameters:

• Session ID
• Public Key certificate of peer
• Compression algorithm
• Cipher specification (encryption, digest, etc.)
• Master (session) secret: 48 bytes

Connection Parameters:

• Nonces
• Auth Keys
• Enc. keys

SSL supports the following ciphers:

• DES, HMAC/SHA-1
• 3DES, HMAC/SHA-1
• MD5
• others

1. Application layer broken into fragments
2. Each fragment, called a record is (optionally) compressed
3. Add MAC code at end of data
4. encrypt whole block
5. add SSL header at beginning

Handshake Protocol

4 Phases:

1. Establish security capabilities: who supports what?
   • SSL version
   • Cipher and parameters to use
2. Authenticate Server (optional) and perform key exchange (make sure this is Google)
3. Authenticate Client (optional) and perform key exchange
4. Finish up

bold items are mandatory

Hello

• Client → Server: Client Hello (transmitted in plaintext)
  • highest SSL version understood by client
  • random nonce
  • session ID (0 for new)
• Server → Client: Server Hello
  • minimum of (highest SSL version supported by server, highest version supported by client)
  • random nonce
  • Encryption algorithms

Server Authentication

• Server → Client: certificate
  • server's public key in X.509 standard format
  • necessary for any key change method except anonymous Diffie-Hellman
  • Public key signed by trusted CA; contains expiration date and the official issued domain
  • Verified by Client's list of trusted CAs
  • Certificate Revocation List (CRL) used to revoke hacked certificates (browser automatically checks this)
• Key Exchange Methods
  • RSA
  • Fixed Diffie-Hellman
  • Anonymous Diffie-Hellman

Client Authentication

Similar to Server authentication, but reversed direction

Server usually doesn't care who you are, but there are some cases otherwise.

Finish Up

• Change_Cipher_Spec message
  • Confirms change of current state of session to newly-negotiated set of crypto params

Creating Master Secret

Master secret is one-time (per session) 48-byte value

generated from Client and Server Nonces

Cryptographic Parameters

Generated from master secret and nonces

Alert Protocol

1. Fatal_Alert
   • No certificate
2. Warning

Summary

SSL is de facto authentication/encryption protocol for HTTP

Allows negotiation of cryptographic methods and parameters