Le implicazioni di avere un account di servizio in AD usano RC4 piuttosto che AES per Kerberos?

7

Resta con me, so che questo è sciatto, ma qui c'è il retroscena:

Abbiamo un partner che utilizza Jira e utilizza spnego con un back-end di autenticazione personalizzato che prevede l'appartenenza a determinati gruppi nel token. Supponendo che il token presentato soddisfi i requisiti, all'utente viene concesso l'accesso SSO a Jira.

Abbiamo un trust esterno non transitivo a due vie da uno dei nostri domini figlio con questo partner. Poiché si tratta di un trust esterno vecchio e croccante e non di un trust forestale selettivo, AD non conserva le informazioni necessarie affinché Kerberos funzioni per altri scopi oltre agli accessi interattivi tra i domini.

Per questo servizio è stato registrato un SPN, ma i clienti al mio fianco non sono in grado di individuare questo SPN perché non è possibile effettuare un referral Kerberos. Questo è, ovviamente, un problema poiché fa sì che i client torni a NTLM e non SSO.

La soluzione proposta è di creare un account di servizio su nostro e registrare un SPN dalla nostra parte per lo stesso servizio identico al loro. Le password dovranno essere identiche su ciascun lato. Ciò annullerà la necessità di un referral per trovare il SPN appropriato dal momento che lo stiamo effettivamente rispecchiando dalla nostra parte e "ingannando" i clienti di nostro figlio nell'usarlo anziché da quello giusto dalla loro parte. Propongono inoltre di abbassare l'algoritmo di crittografia per questi account con mirroring su RC4 anziché su AES.

È qui che la mia conoscenza inizia a vacillare, non so perché sia necessario ridurre l'algoritmo di crittografia a RC4. Inoltre, non so quali potrebbero essere le implicazioni sulla sicurezza.

Quali sono le implicazioni e perché non possiamo limitarci ad utilizzare AES per fare in modo che funzioni?

    
posta MDMarra 17.01.2013 - 03:36
fonte

2 risposte

4

La più grande ragione per cui posso pensare a perché potrebbero voler usare RC4 è a causa della compatibilità con Jira (o con questo backend di autenticazione personalizzato che non possiamo controllare).

Il supporto AES128 è stato introdotto insieme a Server 2008 e Vista e AES256 con 2008 R2 e Win7. Tuttavia, il KDC negozierà automaticamente verso (per esempio) RC4 quando si parla, ad esempio, di un client Windows 2000, durante la pre-autenticazione. Quindi non dovrebbe essere necessario forzarlo.

Naturalmente, puoi anche configurare account utente e computer per supportare o non supportare DES, AES128, AES256, ecc.

Le implicazioni sono semplicemente che non è così strong come un tipo di crittografia come quelli AES più recenti. Ma non è neanche terribile.

Sarei certamente interessato a sentire il loro ragionamento sul perché vogliono usare RC4. Il trucco che stai proponendo con gli SPN con mirroring è un intero altro tipo di worm, ma il tipo di crittografia utilizzato tra client e KDC non dovrebbe avere essenzialmente nulla a che fare con il fatto che funzionerà.

    
risposta data 17.01.2013 - 17:12
fonte
2

Tu (o loro , quelli che propongono il cambiamento) non fornisci una ragione per passare a RC4, vero? RC4 è un codice di flusso, che è vulnerabile in alcuni casi particolari:

RC4 has weaknesses that argue against its use in new systems. It is especially vulnerable when the beginning of the output keystream is not discarded, or when nonrandom or related keys are used. (Wikipedia)

Quindi le implicazioni dell'uso di RC4 sono vulnerabilità (almeno) a quanto sopra. Non riesco a capire perché AES non regge, senza una ragione per il cambiamento ..

    
risposta data 17.01.2013 - 08:29
fonte

Leggi altre domande sui tag