Presentation is loading. Please wait.

Presentation is loading. Please wait.

 Authorization via symmetric crypto  Key exchange o Using asymmetric crypto o Using symmetric crypto with KDC  KDC shares a key with every participant.

Similar presentations


Presentation on theme: " Authorization via symmetric crypto  Key exchange o Using asymmetric crypto o Using symmetric crypto with KDC  KDC shares a key with every participant."— Presentation transcript:

1  Authorization via symmetric crypto  Key exchange o Using asymmetric crypto o Using symmetric crypto with KDC  KDC shares a key with every participant  Authenticates participants, generates session (shared) keys for them to talk to each other  Gives the requester a “ticket” – session key, requester’s ID and possibly expiration time, encrypted by the key that the server shares with KDC  Ticket and session key enrypted by the key that the requester shares with KDC  Needham-Schroeder, Kerberos

2 Third-party authentication service o Distributes session keys for authentication, confidentiality, and integrity KDC 1. C, S, N C 2. K C (N C, K CS, S, K S (K CS, C )) CS 3.K S (K CS, C ) 4.K CS (N S ) 5.K CS (N S -1) Problem: replay attack in step 3 Fix: use timestamps

3  Introduce Ticket Granting Server (TGS) o Issues timed keys to resources  Users log on to authentication server (AS)  AS+TGS = KDC  Uses timestamps with a lifetime instead of nonces o Fixes freshness problem from Needham- Schroeder

4 Third-party authentication service o Distributes session keys for authentication, confidentiality, and integrity TGS 4. K C,TGS (K C,S ), T CS 3. TGT, S, K C,TGS (C, t) AS 1.C2. K C (K C,TGS ), TGT C S 5. T CS, K C,S (C,t) K C =hash(pass(C)) TGT=K TGS (C,Tvalid,K C,TGS ) T CS =K S (C,Tvalid,K C,S ) 6. K C,S (t+1)

5  Public key is public but … o How does either side know who and what the key is for?  Does this solve key distribution problem? o No – while confidentiality is not required, integrity is  Still need trusted third party o Digital certificates – certificate authority (CA) signs identity+public key tuple with its private key o Problem is finding a CA that both client and server trust

6  Everyone has Trent’s public key  Trent signs both Alice’s and Bob’s public keys – he generates public-key certificate  When they receive keys, verify the signature  Mallory cannot impersonate Alice or Bob because her key is signed as Mallory’s  Certificate usually contains more than the public key o Name, network address, organization  Trent is known as Certificate Authority (CA)

7  Authentication steps o Verifier provides nonce, or a timestamp is used instead. o Principal selects session key and sends it to verifier with nonce, encrypted with principal’s private key and verifier’s public key, sends principal’s certificate too o Verifier validates certificate o Verifier checks signature on nonce

8  PGP (Pretty Good Privacy) o “ Web of Trust” o Source: Wikipedia  “As time goes on, you will accumulate keys from other people that you may want to designate as trusted introducers. Everyone else will each choose their own trusted introducers. And everyone will gradually accumulate and distribute with their key a collection of certifying signatures from other people, with the expectation that anyone receiving it will trust at least one or two of the signatures. This will cause the emergence of a decentralized fault-tolerant web of confidence for all public keys.“

9  X.509 standard o Hierarchical model o A handful of trusted CAs can issue certificates to others

10  SSH o User keys exchanged out of band o Weak assurance of server keys  Is this the same host you spoke with last time?

11  Revocation lists (CRL’s) o Long lists o Hard to propagate  Lifetime / Expiration o Short life allows assurance of validity at time of issue but increases cost of key distribution  Real-time validation o Online Certificate Status Protocol (OCSP) o Single source of the compromised key list o Clients check suspicious keys and hash replies

12  Group key vs. Individual key o Proves that one belongs to the group vs. proving an individual identity o E.g., used for multicast messages

13  Revoking access o Change keys, redistribute  Joining and leaving groups o Does one see old messages on join or is the key changed – backward secrecy o How to revoke access – forward secrecy  Robustness o Coping with network partitioning  Efficiency o Cost of use, verification, exchange

14  Centralized o Single entity issues keys o Optimization to reduce traffic for large groups o May utilize application specific knowledge  Decentralized o Employs sub managers  Distributed o Members do key generation o May involve group contributions


Download ppt " Authorization via symmetric crypto  Key exchange o Using asymmetric crypto o Using symmetric crypto with KDC  KDC shares a key with every participant."

Similar presentations


Ads by Google