Come impongo Windows Smartcard per l'autenticazione AD in modo che "anyExtendedKeyUsage" non sia implicito?

2

Questo documento descrive come ci sono 3 modi per vincolare un certificato SmartCard

The Enhanced Key Usage field defines one or more purposes for which the public key may be used. RFC 5280 states “in general, [sic] the EKU extension will appear only in end entity certificates.” Certification authorities’ certificates may contain EKU entries. To allow smart card logon within an Active Directory domain the smart card’s chain of trust must support the Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2) application policies. Active Directory smart card logon is supported with the following EKU configurations:

  • All certificates in the chain of trust do not assert Enhanced Key Usage (except for the end entity certificate) the anyExtendedKeyUsage EKU is implied.
  • All certificates in the chain of trust do not assert Enhanced Key Usage except for the root trust point certificate. Root trust point EKU field asserts Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).
  • All certificates in the chain of trust Enhanced Key Usage field assert Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2) and Client Authentication (OID 1.3.6.1.5.5.7.3.2).

Best practice is for the root trust point certificate not to include an Enhanced Key Usage extension. The Federal Common Policy CA certificate does not assert an EKU; therefore all application policies are implied.

Questo significa che ho bisogno di una SmartCard PKI dedicata nel mio ambiente solo per vincolare le smartcard all'autenticazione?

C'è un modo in cui posso definire una CA root per tutti gli usi + smartcard, e ho anche un sub-ca dedicato alle smartcard in modo da poter ingannare il processo di validazione di AD?

    
posta random65537 02.06.2012 - 19:48
fonte

1 risposta

2

In generale, non è possibile applicare un vincolo come "dovrebbe essere usato solo per l'accesso con smartcard". Questo dovrebbe essere il ruolo dell'estensione del certificato Extended Key Usage ; vedi RFC 5280 , sezione 4.2.1.12:

If the extension is present, then the certificate MUST only be used for one of the purposes indicated.

Questo si basa su tutte le applicazioni che convalidano i certificati per controllare effettivamente l'EKU e imporre il suo contenuto (un'applicazione dovrebbe verificare se l'EKU è lì e contiene il proprio OID o la percentuale specialeanyEKU OID o, almeno, l'estensione EKU dovrebbe essere assente, se l'applicazione non ha un OID specifico per sé). In pratica, le applicazioni non eseguono tali controlli. Alcune applicazioni eseguiranno tale elaborazione, ma non puoi aspettarti affidabilmente che tutte le applicazioni lo facciano, anche se ti limiti al puro mondo Microsoft.

Per forzare la separazione dei ruoli, hai davvero bisogno di diversi PKI (l'EKU dovrebbe farlo, ma in pratica no, il che è triste). In una certa misura, potresti creare "una" PKI (cioè una radice) e usare una sub-CA distinta, e impostare la CA subordinata come root (es. Potresti spingere la CA secondaria specifica per emissione di smartcard come "root" nell'archivio NTAuth sul server Active Directory). Tali CA secondari sono CA radice nascosta, quindi è meglio gestirli come tali (ad esempio, renderli longevi).

In generale, far rispettare il mancato utilizzo dei certificati emessi è una ricerca infruttuosa. Per coprirti in modo legale, è sufficiente pubblicare una Dichiarazione sulla politica di certificazione , debitamente collegata dall'estensione Certificate Policies nel certificato, in cui si afferma in parole semplici che i certificati sono pensati per la smartcard solo accesso. Non è necessario (e non è realmente possibile neanche con un'affidabilità del 100%) che tu disponga che tutti gli altri software esistenti rifiutino i tuoi certificati. In definitiva, qualsiasi applicazione può convalidare i certificati nel modo che ritiene opportuno.

    
risposta data 07.01.2013 - 19:06
fonte