Scenario. Roadmap. ! The simplified architecture! The complete architecture Pre-authentication Delegation. Realms

Transcription

1 erberos' erberos! erberos is based on the Needham-Schroeder protocol (1978)! erberos was developed at MIT in1980! erberos V4 and erberos V5 (RFC 1510)! erberos if part of OSF DCE and Windows 2 (e later)! In Windows 2000, erberos has replaced the Windows NT domain authentication mechanism 2

2 Roadmap! The simplified architecture! The complete architecture Pre-authentication Delegation proxiable tickets forwardable tickets Realms 3 Scenario Client Alice Server Bob! Server only allows authorized accesses! Server authenticates service requests 4

3 Client authentication 1. Server trust workstation for user authentication. The server applies a policy base on UID (closed system) 2. Similar to point 1 but the server authenticates the WSs (closed system) 3. Server requires the user to provide a proof of idenity for each service request, and vice versa (open system) 5 Objectives! Security Eavesdropping and spoofing must be non possible for an outsider! Availability If erberos is unavailable all the services become unavailable! Transparency The authentication process must be transparent but password typing! Scalability erberos must handle a large number of servers and users 6

4 erberos: architettura di base c Authentication Server s c e s (master key) sono segreti condivisi tra AS e client e server, rispettivamente (ad esempio derivati da password) Alice (client)? Bob (server) Obiettivo primario: autenticazione mutua di client e server Obiettivi secondari: Stabilire una chiave condivisa tra client e server Provare al server che il client è attivo e viceversa 7 The basic idea AS Alice Bob credentials ticket a, ticket b authenticator ab, ticket b!cket a "="E a (A ab );""!cket b "="E b (A ab );"" authen!cator ab "="E ab (t a )" 8

5 erberos V (simpl.) RB_AS_REQ RB_AS_RESP RB_AP_REQ RB_AP_RESP M1 A AS : A,B,t,L,N a,ws { } b { } b { } ab M2 AS A: A,B,t,L, ab,ws M3 A B : A,B,t,L, ab,ws M4 B A: t a, { } a { } ab, B,t,L,N a, ab, A,t a, ticket b authenticator ab ticket a 9 RB_AS_REQ RB_AS_RESP RB_AP_REQ RB_AP_RESP erberos V M1 A AS : A, B, t, L, N, WS { ab } { } a ab b { } { } M2 AS A: A, B, t, L,, WS, B, t, L, N, M3 A B : A, B, t, L,, WS, A, t, subkey { a } M4 B A : t, subkey a ab a a b ab b a ab L"Validity'interval'of'the'3cket."Alice"reuses"the"4cket"for"mul4ple"authen4ca4ons" to"bob"without"interac4ng"with"as"so"avoiding"messages"m1"and"m2" The"3mestamp"t a 'is"generated"by"alice."bob"verifies"the"freshness."for"each" authen4ca4on,"alice"generates"a"new"authen4cator"using"the"same" ab "but"a" different"t a' The"work"sta4on"iden4fier"WS"allows"the"server"to"control"which"computers"can" use"the"4cket" The"subkey a 'e'subkey b 'can"be"used"for"the"service"fulfillment.' 10

6 Assumptions a A A AS B B AS a AS A AS AS B AS ab AS A B Analysis ab ab A AS A B B AS A B Idealized protocol b b ab ab M2 AS A: t, Na, A B, t, A B ab ab M3 A B: t, A B, ta, A B from A ab M4 B A: ta, A B from B 11 b A # ab a ( t) ( ) ( ) B # t B # t a ab b dopo il messaggio M2 ab A A B Analysis dopo il messaggio M3 key authentication ab B A B ab B A A B dopo il messaggio M4 key confirmation ab A B A B 12

7 Lifetime and authenticator Trent t Alice ticket B L (ticket lifetime) = 1 day t a Bob ticket B, authenticator AB t b t b t a <= λ(authenticator lifetime) authenticator lifetime clock skew (λ= 5 minuti) 13 Comments! erberos requires synchronized clocks! In erberos 5, λ= 5 minutes: Authenticator may be replayed in that window! If a and b derive from a pwd, then they are as secure as the pawd 14

8 Complete architecture! A user uses quite a few services! The user has to authenticate to each service! Two approaches The user inputs the pwd for each new authentication and then deleted soon (little usable) The WS stores the pwd for a long period (little secure) 15 TGS and TGT Once per-session erberos AS TGS "Every problem in computer science can be solved by adding a level of indirection" (D. Wheelar, Cambridge) (1) Alice (2) (3) uno per servizio 1. AS releases the ticket granting ticket (TGT) to interact with the Ticket Granting Server (TGS) Once for service request Bob 2. TGS releases a service ticket (ST B ) to interact with Bob 16

9 Phase 1 Ticket Granting Service Alice inteacts with AS and receives a TGT, ticket granting ticket, a ticket for server TGS Phase 2 Alice interacts with TGS and receives ST b, service ticket, a ticket for server B Phase 3 Alice uses ST b to authenticate and to get authenticated to Bob 17 Interacting with TGS Phase 2: msg RB_TGS_REQ Alice asks TGS a service ticket for B { A, t }, B, t, L, N,{ A, TGS, t, L, T, WS} a T a TGS Phase 2: msg RB_TGS_RESP TGS releases Alice a service ticket for B { A,B, t, L, ab,ws}, B, t b, L, ab,ws,n a { } T 18

10 Messaggio RB_TGS_REQ { A, t }, B, t, L, N,{ A, TGS, t, L, T, WS} a T a TGS Authenticator Sent by Alice to TGS Ticket Granting Ticket T: Ticketing ey (temporary key) (t, L) durata del TGT Service Ticket Request Alice asks TGS a service ticket for B 19 Messaggio RB_TGS_RESP Service ticket for Bob released by TGS to Alice { A,B, t, L, ab,ws}, B, t b, L, ab,ws,n a { } T Service Ticket for Bob Service Ticket for Alice 20

11 Authentication! erberos authenticates users w.r.t. network services! erberos does not authenticate users w.r.t. AS Anyone may ask for a ticket on Alice behalf erberos guarantees that nobody but Alice can use that ticket An adversary may use this to launch a pwd attack Guess a pwd and verify the guess by decrypting a ticket! erberos does not help WS to authenticate users (indirect authentication) WS is just a means through which users access services WS are uniform, interchangeable, thin client; 21 Normal authentication user WS erberos login name prompt Alice password prompt P A WS does not authenticate Alice but the ticket is encrypted. However, an adversary can collect tickets (on demand) and use them to launch a pwd attack (known plaintext attack) 22

12 erberos 5 pre-authentication user WS erberos <A, P A > A = f(p A ) { ( )} Ticket Request : ABN,,, t, h ABN,, A W A A Verification of the ticket request msg Upon receiving the TICET REQUEST, erberos believes that Alice ha recently originated the message confirmation of user's identity The adversary can still launch a password attack using ticket requests collected on the network but know is more difficult. 23 Delegation ticket A,MS? A MS FS Example. Mail Server MS has to interact with File System FS on the iser behalf according to the minimum privilege principle erberos provides two mechanisms that allow Alice to delegate MS proxy tickets forwardable TGT 24

13 Proxy ticket PT allows us to request a service ticket linked to an address (WS) different from the requesting one AS Proxy Ticket: { A,FS,N A,t,L,FS}, T { A,FS,MS,t,L} fs { session key for FS} session key for MS {, A,FS, } a,ms Proxy ticket for FS required by A, released to MS 25 Proxy ticket: cons! Problem. This solution requires that Alice knows in advance all the proxy tickets she needs or, She is able to negotiate them with MS as needed! Forwardable tickets make it possible to solve this problem and allow the delegated server MS to ask the necessary tickets 26

14 Forwardable ticket 1. f-tgt AS f-tgt: forwardable TGT ST: service ticket TGT(MS): TGT requested by A on behalf of MS * 2. f-tgt A 3. ST for MS, TGT(MS) TGS 5. TGT(MS) 6. ST for FS 4. ST for MS, TGT(MS), {session key for TGT(MS)} session key for MS 7. ST for FS MS * The ticket specifies identifier MS instead of A FS 27 Forwardable ticket [ ] Step 3. TGS returns Alice 1. A service ticket for MS {, a,ms, } T, {, a,ms, } ms 2. A TGT containing the ticketing key associated to MS instead of Alice {, T, } a, {, T, MS, } tgs. Step 4. Alice forwards the two tickets to MS together with the ticketing key T encrypted by means of con a,ms [ ] The ticketing key is associated to MS instead of A 28

15 Proxy vs forwardable ticket Proxy ticket! (PRO) The user controls which rights to delegate the server! (CON) The user needs to know which tickets will be necessary Forwardable ticket! (PRO) The server determines which ticket it needs! (CON) A compromised servers can abuse of all rights 29 Limitations to delegations! A ticket has a maximum lifetime! A ticket specifies a maximum number of access rights (capability) 30

16 Realms e referral tickets Users and servers may belong to different administrative domains (realms) erberos authenticates principals in its realm Problem. Alice has to authenticate a foreign server Bob (in another realm) Alice asks erberos A a referral TGT for realm B (1). erberos A generates a referral TGT using an inter-realm key ( RA,RB ) Alice uses the referral TGT to request erberos B a service ticket to Bob (2). Alice uses the service ticket to interact to Bob (3) Alice (3) (2) Bob Realm A (1) AS AS TGS Realm B TGS erberos erberos RA,RB 31 Hierarchy of realms erb Alice needs a service ticket for a foreign server Bob erb erb Every erberos gives Alice a un referral ticket for the next node (parent or child) until Alice gets Bob s realm This process requires O(log n) operations erb erb Alice Bob 32

17 Intrusion tolerance! Pragmatic approach. erberos is subject to intrusions but limits their effects Workstation. Damages are limited to the work station and its users Server. Damages are extended to all server s users A good practice is to distribute servers over multiple machines DC. The system is complettely broken 33 Clock synchronization Adversary has an old key and the related ticket Time server NTP Possible objectives If the adversary succeeds in turning back the clock, then it can reuse the key Server 34

18 Public-key encryption Certificates remove the need of shared secrets based on reusable passwords ( ) ( ( )) M1. A T S A, B, N, certificate A A A M 2. T A ticket, E S, N, L, B Alice holds certificate T Procedure PINIT B e T A A W2 encapsulates PINIT in its erberos-based authentication environment 35