is CRL " certificate revocation list" checked by hostapd or openssl in eap-tls?

[thomas schorpp]

Jouni Malinen wrote:
> On Thu, May 19, 2005 at 09:50:30AM +0200, thomas schorpp wrote:
> 
> 
>># CA certificate (PEM or DER file) for EAP-TLS/PEAP/TTLS
>>ca_cert=/etc/hostapd/wpaca/ca/CAcert.pem
>>
>># Server certificate (PEM or DER file) for EAP-TLS/PEAP/TTLS
>>server_cert=/etc/hostapd/wpaca/certs/tom3-cert.pem
>>
>>no entry for the crl.
> 
> 
> The current CVS snapshot has a new configuration variable, check_crl.
> This can be used to enable CRL verification. However, the implementation
> is still quite minimal and the CRL data needs to be added into the
> ca_cert file with something external (e.g., 'wget crlurl' and 'cat
> ca.pem crl.pem > cafile.pem). In addition, hostapd needs to be restarted
> when CRL is changed.

thx. ok i'll pull the newest HEAD and take a good look.

i'm courios, since the openssl.org docs state crl functionality on cert
verify functions "unused"... if not outdated.

> 
> 
>>i would like to implement this then, to deauthenticate users just simply
>>by revoking their certs ;)
> 
> 
> Deauthenticating users automatically based on certificate revocation
> would require storing certificate information for each associated client
> and going through this data whenever the CRL is updated. If rejecting
> the next authentication is enough, the current hostapd snapshot should
> be able to do this.

yes. maybe an uneconomically effort if i'm the only one who wants it...
last is sufficent for me.

and deauthentication without stating reason to the client user is not
customer friendly. stating a reason in revocation makes crl's
automatically version 2 as the openssl.org docs state. analysis of
handling by current implementations should apply before.

then supplicants must implement a more comprehensive user notification
of cert revocation reason before disconnecting the last valid session,
i've not seen such yet, only manual validation check in d-link software.
at lower level it looks like hostapd and clients supplicant would enter
endless auth trying loops if theres no notification of revoked cert at
least by accessing servers crl over http what is no more possible after
disconnect then since the client cant authenticate and connect again to
the crl server.
many revoked clients could flood the ap then with fast repeated auth reqs.

so a automatic solution should rather be on the clients side.
and all platforms and manufacturers client-sw is not in hostapd projects
control...

there should be a standard draft then. or it is and i've missed it.

and deauth for the next client attempt could be done easier just by
deleting the client in the eap_user database after notyfing the user
manually or automatically with external services without the need for
complex cryptography handling...

> However, it would be nice to add support for
> automatically downloading (at least HTTP and LDAP) and updating CRL
> based on CDP from the user certificates..

unclear target yet, since all os platforms may have no such CDP comms
running by default even if have implemented it.

pls correct, if i understood something wrong here.

> At least, making it easier to
> update CRL without having to restart hostapd would be a good start.
> 

i'll check if i can afford this and consider implementation after
further analysis and hostapd administrators demand on this list.

quick view on the code looks like all is non-trivial encapsulated in
state machine objects. need some time to rev engineer this.

theres very nice dev documentation for wpasupplicant on the site, is
there something for hostapd?

thx
y
tom