in che cosa differisce l'autenticazione in un sistema distribuito da quella tradizionale di un utente di un sistema operativo?

• il canale di comunicazione: non si può assumere che sia sicuro
• l'utente: non necessariamente una persona, più in generale un processo, soggetto di richieste di
  • accesso a oggetti per determinate operazioni su essi
  • comunicazione autenticata con altri soggetti

problemi di autenticazione che derivano da tali differenze:

• definizione di identità dei soggetti
• autenticazione basata solo su cosa conosce
• autenticazione come servizio, che fornisce meccanismi di identificazione protetti, possibilmente basato su trusted third-party (TTP)

la protezione crittografica è di largo impiego nelle diverse soluzioni realizzate per questi problemi, ma la sicurezza che ne consegue non dipende solo dalla sua (in)violabilità

l'autenticazione basata su password associata a un identificatore di utente è frequente nelle interazioni client-server anche in sistemi distribuiti

• ad es., accesso HTTP autorizzato a una risorsa protetta

vulnerabilità: la password è un segreto condiviso da client e server, la cui trasmissione in chiaro la espone al rischio di cattura da password sniffers

• Basic Access Authentication : trasmissione in chiaro (in codice base64)
• DigestAccess Authentication : uso di una funzione di hash crittografico h (e.g. MD5) in un protocollo challenge-response fra server e client in cui
  • il server reagisce alla richiesta di accesso a risorsa protetta inviando al client un identificatore di realm di protezione r e un nonce n (valore usato solo una volta)
  • il client risponde alla sfida inviando in chiaro l'identificatore di utente u, il nonce n e il digest della richiesta: h (h (u || r || p) || n || h (m || i)), dove
    • p è la password di u
    • m è il metodo HTTP di accesso
    • i è l'URI della risorsa protetta

l'autenticazione ha spesso luogo nella fase di formazione di una sessione di accesso del soggetto a un oggetto, o di comunicazione fra soggetti, come parte dello scambio di chiavi, tuttavia...

• autenticazione e scambio di chiavi sono concetti diversi, non sempre associati

terminologia:

• peer entity authentication (ISO 7498-2, 1989): concomitante alla formazione di una sessione
• entity authentication (ISO/IEC 9798-1, 1991): meccanismo svincolato dalla formazione di una sessione, permette la dead peer detection
• autenticazione unilaterale oppure mutua
• key establishment, responsabilità: key transport oppure key agreement
• key establishment, garanzie:
  • key authentication
  • key confirmation
  • explicit key authentication : entrambe le precedenti

un esempio di key agreement è il protocollo di Diffie-Hellman

• tuttavia esso non dà alcuna garanzia di autenticità del partner della comunicazione!
• un intruso che abbia accesso al canale di comunicazione può portare l'attacco detto man in the middle, presentandosi a ciascun partner come se fosse l'altro

il protocollo station-to-station (STS) (Diffie, van Oorschot & Wiener, 1992), estende quello di Diffie-Hellman con un meccanismo di mutua explicit key authentication, usando a tal fine (senza tuttavia prefissarli):

• un algoritmo di crittografia e
• un algoritmo di firma digitale s

sia K = g^ab mod p la chiave Diffie-Hellman che si stabilisce, e S_a, S_b le rispettive chiavi di firma dei partner A, B; lo scambio STS consta dei seguenti passi (exp. mod p è intesa):

1. A → B:       g^a
2. B → A:       g^b, e_K (s_Sb (g^b, g^a))
3. A → B:       e_K (s_Sa (g^a, g^b))

il sistema Kerberos (Miller, Neuman, Schiller & Saltzer, 1987) trae origine dal protocollo di (Needham & Schroeder, 1978), di key transport

• autenticazione di utenti a servizi in un sistema distribuito, fornita da un server centrale di autenticazione (KAS) che agisce da centro di distribuzione di chiavi di sessione (KDC)

il KAS condivide con ciascun utente A o servizio B un chiave segreta di lungo termine, risp. K_as, K_bs, ha un database che associa le identità di utenti e servizi a tali chiavi, e genera una chiave di sessione K_ab di durata limitata L per ciascuna sessione di A con B, alla quale associa un ticket t_B = e_Kbs (K_ab,A,L)

in prima approssimazione, lo schema del protocollo è il seguente, dove n_a è un nonce generato da A e T_a è un timestamp riferito al clock di A:

1. A → S:       A, B, n_a
2. S → A:       e_Kas (K_ab,n_a,L,B), t_B
3. A → B:       t_B, e_Kab (A,T_a)
4. B → A:       e_Kab (T_a)

una migliore approssimazione all'effettivo funzionamento del protocollo si ha considerando la distribuzione dei ticket di accesso ai servizi come un servizio essa stessa, fornito da appositi ticket-granting server (TGS), ai quali l'utente si autentica per il tramite del KAS centrale

in seconda approssimazione, il KAS genera:

• la chiave di sessione K_a,tgs fra A e TGS
• il ticket-granting ticket (TGT) t_A,TGS = e_Ktgs (K_a,tgs,A,L₂)

dove:   K_tgs è una chiave condivisa da KAS e TGS

• la durata L₂ della sessione da stabilirsi fra A e B è generalmente distinta dalla durata L₁ della sessione fra A e TGS
• A genera inoltre nonce distinti n_a, n'_a per le due sessioni in gioco,
• come distinti sono i rispettivi timestamp T_a, T'_a

lo schema del protocollo fra utente A, KAS, TGS e server B è il seguente:

1. A → KAS:       A, TGS, n_a
2. KAS → A:       e_Kas (K_a,tgs,n_a,L₁,TGS), t_A,TGS
3. A → TGS:       t_A,TGS, e_Ka,tgs (A,T_a), B, n'_a
4. TGS → A:       e_Ka,tgs (K_ab,n'_a,L₂,B), t_B
5. A → B:           t_B, e_Kab (A,T'_a)
6. B → A:           e_Kab (T'_a)