Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Valentina Casola » 8.Authentication Protocols in distributed system


Identification and Authentication


Identification and Authentication (cont’d)


Authentication


Authentication: yet another try


Authentication: Challenge Response

How to avoid the playback attack?
Use a challenge resposnse protocol:
to prove Alice “live”, Bob sends Alice nonce, R.
Alice must return R, encrypted with shared secret key.

Nonce: number (R) used only once-in-a-lifetime.


Authentication: Challenge Response v2

Can we authenticate using public key techniques?
YES + use nonce AND public key cryptography
Bob computes:
(KA+ (KA-(R)) = R
he knows only Alice
has the private

key, that encrypted R


Main in the middle attack


Man in the middle attack (cont’d)

Man in the middle attack: Trudy poses as Alice (to Bob) and as Bob (to Alice).

Difficult to detect:

  • Bob receives everything that Alice sends, and vice versa. (e.g., so Bob, Alice can meet one week later and recall conversation);
  • problem is that Trudy receives all messages as well!

Authentication Based on a Shared Secret Key


Mutual Authentication Using a public key criptography


Problems on Key Distribution and Trusted Intermediaries

Symmetric key problem:

  • How do two entities establish shared secret key over network?

Solution:

  • trusted key distribution center (KDC) acting as intermediary between entities.

Public key problem:

  • When Alice obtains Bob’s public key (from web site, e-mail, diskette), how does she know it is Bob’s public key, not Trudy’s?

Solution:

  • trusted certification authority (CA).

Key Distribution Center (KDC)

  • Alice, Bob need shared symmetric key.
  • KDC: server shares different secret key with each registered user (many users).
  • Alice, Bob know own symmetric keys, KA-KDC KB-KDC , for communicating with KDC.

Key Distribution Center (KDC)

How does KDC allow Bob, Alice to determine shared symmetric secret key to communicate with each other?


Certification Authorities

  • When Alice wants Bob’s public key:
    • gets Bob’s certificate (Bob or elsewhere);
    • apply CA’s public key to Bob’s certificate, get Bob’s public key.

Authentication Based on a Shared Secret Key  - using three instead of five messages


Authentication Based on a Shared Secret Key


Authentication Using a Key Distribution Center


Authentication Using a Key Distribution Center (cont’d)


Authentication Using a Key Distribution Center (cont’d)

The Needham-Schroeder authentication protocol.

The Needham-Schroeder authentication protocol.


Authentication Using a Key Distribution Center (cont’d)

Protection against malicious reuse of a previously generated session key in the Needham-Schroeder protocol.

Protection against malicious reuse of a previously generated session key in the Needham-Schroeder protocol.


Example:  Authentication Kerberos


Example: Setting up a secure channel in Kerberos


Kerberos

  • The user and a Key Distribution Center (KDC) share a secret key; the service and the KDC share a different secret key.
  • The user and the requested service do not share a symmetric key in the beginning.
  • The user trusts the KDC because they share a secret key. They can encrypt and decrypt data they pass between each other, and thus have a protected communication path.
  • Once the user authenticates to the service, they too will share a symmetric key (session key) that will enable them to encrypt and decrypt the information they need to pass to each other.

Kerberos at a glimpse


Symmetric Keys in Kerberos

  • Kc is long-term key of client C
    • Derived from user’s password.
    • Known to client and key distribution center (KDC).
  • KTGS is long-term key of TGS
    • Known to KDC and ticket granting service (TGS).
  • Kv is long-term key of network service V
    • Known to V and TGS; separate key for each service.
  • Kc,TGS is short-term key between C and TGS
    • Created by KDC, known to C and TGS.
  • Kc,v is short-term key betwen C and V
    • Created by TGS, known to C and V.

“Single Logon” Authentication


Obtaining a Service Ticket


Obtaining Service

For each service request, client uses the short-term key for that service and the ticket he received from TGS.

For each service request, client uses the short-term key for that service and the ticket he received from TGS.


Important Ideas in Kerberos

  • Short-term session keys
    • Long-term secrets used only to derive short-term keys.
    • Separate session key for each user-server pair
      • … but multiple user-server sessions re-use the same key.
  • Proofs of identity are based on authenticators
    • Client encrypts his identity, address and current time using a short-term session key
      • Also prevents replays (if clocks are globally synchronized).
    • Server learns this key separately (via encrypted ticket that client can’t decrypt) and verifies user’s identity.
  • Symmetric cryptography only.

Problematic Issues

  • Password dictionary attacks on client master keys.
  • Replay of authenticators
    • 5-minute lifetimes long enough for replay.
    • Timestamps assume global, secure synchronized clocks.
    • Challenge-response would have been better.
  • Same user-server key used for all sessions.
  • Extraneous double encryption of tickets.
  • No ticket delegation
    • Printer can’t fetch email from server on your behalf.

Kerberos Version 5

  • Better user-server authentication
    • Separate subkey for each user-server session instead of re-using the session key contained in the ticket.
    • Authentication via subkeys, not timestamp increments.
  • Authentication forwarding
    • Servers can access other servers on user’s behalf.
  • Realm hierarchies for inter-realm authentication.
  • Richer ticket functionality.
  • Explicit integrity checking + standard CBC mode.
  • Multiple encryption schemes, not just DES.

Practical Uses of Kerberos

  • Email, FTP, network file systems and many other applications have been kerberized
    • Use of Kerberos is transparent for the end user.
    • Transparency is important for usability!
  • Local authentication
    • login and su in OpenBSD.
  • Authentication for network protocols
    • rlogin, rsh, telnet.

Single Sign On

  • Employees need to access many different computers, servers, databases, and other resources in the course of a day to complete their tasks.
  • Because of the proliferation of client/server technologies, networks have migrated from centrally controlled networks to heterogeneous, distributed environments.
  • This often requires the employees to remember multiple user IDs and passwords for these different computers.
  • Although the different IDs and passwords are supposed to provide a greater level of security, they often end up compromising security (because users write them down) and causing more effort and overhead for the staff that manages and maintains the network.

Single Sign On (cont’d)

  • The increased cost of managing a diverse environment, security concerns, and user habits, coupled with the users’ overwhelming desire to remember one set of credentials, has brought about the idea of single sign-on (SSO) capabilities.
  • These capabilities would allow a user to enter credentials one time and be able to access all resources in primary and secondary network domains.
  • This reduces the amount of time users spend authenticating to resources and it enables the administrator to streamline user accounts and better control access rights.

Single Sign On (cont’d)

  • So that is the goal: log on once and you are good to go.
  • The main problems are related to interoperability issues.
  • For SSO to actually work, every platform, application, and resource needs to accept the same type of credentials, in the same format, and interpret their meanings the same.
  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion