IAS + CRL Usage (PEAP/EAS etc)

I am having a weird problem but I am not sure if it is a fault or what it
is!??!

I have IAS authenticating an 802.11g AP using AES/PEAP.
I have installed Microsoft Certificate services on a 2000 machine, and
autoenrolled all machines..

Now I am testing revocation.
The CRL is set to publish every 5 hours..

I can establish a certificate and authenticate my session without fault.
However, now I revoke my certificate - it shows in the CRL - but I can still
authenticate???!!!

How can this be? I would expect that the IAS server would check against the
revocation list and see that my cert is revoked (listed as superseeded)..

how come I can still connect? Does IAS not check the CRL?

"=?Utf-8?B?TWljaGFlbFcgLSBNZWxiLkF1cy4=?="
<(E-Mail Removed)> wrote in
news:E2970912-A57D-4F4D-98D2-(E-Mail Removed):

> I am having a weird problem but I am not sure if it is a fault or what
> it is!??!
>
> I have IAS authenticating an 802.11g AP using AES/PEAP.
> I have installed Microsoft Certificate services on a 2000 machine, and
> autoenrolled all machines..
>
> Now I am testing revocation.
> The CRL is set to publish every 5 hours..
>
> I can establish a certificate and authenticate my session without
> fault. However, now I revoke my certificate - it shows in the CRL -
> but I can still authenticate???!!!
>
> How can this be? I would expect that the IAS server would check
> against the revocation list and see that my cert is revoked (listed as
> superseeded)..
>
> how come I can still connect? Does IAS not check the CRL?
>

You should not rely on certificate revokation to disable access. The CRL
is cached and will not be reloaded until it expires. Also, you're
generating a lot of extra traffic by setting your publication interval to 5
hours.

If you want to disable a users or computers access, disable the account or
adjust the dial-in properties. Certificates are for authentication, not
access control.

HTH,

Wayne Tilton

I'll take a traffic hit for an updated CRL - even 1Mb every 5 hours to our
remote sites is bugger all if it means that I can ensure systems security.

However, I disagree with your "authentication" comment "not for access
control".

Certificates are revoked for exactly this reason.. they are no longer trusted.
This is whole REASON for certificates - defining who we trust.
In this case, we trust the CA - if I have a certificate signed by the CA -
then I am a trusted person to others who trust it. I would like to be told if
I am NOT to trust someone - and that is EXACTLY what the CRL is for.

The way these certificates work is exactly as defined..
I have just proven, as a client I don't need to have a certificate to
authenticate against the certificate on the IAS server - I only need to TRUST
the certificate installed on the IAS server.

This means that anyone with a copy of the CA's certificate (in essence,
downloaded straight off the CA's website) can access the network.

What SHOULD occur, is that the ISA server should authenticate against the
clients CERTIFICATE - and if that cert is trusted - then allow in.
The trust is at least the wrong way around.. the client should be the one
that is authenticated.

the way it is right now - I trust anyone who can connect to my CA and
download the CA's certificate - isn't that just the same as "I trust you -
here is my password"??!!
What happens when I no longer trust that person? Ask them not to use the
password anymore? I don't think so..



"Wayne Tilton" wrote:

> "=?Utf-8?B?TWljaGFlbFcgLSBNZWxiLkF1cy4=?="
> <(E-Mail Removed)> wrote in
> news:E2970912-A57D-4F4D-98D2-(E-Mail Removed):
>
> > I am having a weird problem but I am not sure if it is a fault or what
> > it is!??!
> >
> > I have IAS authenticating an 802.11g AP using AES/PEAP.
> > I have installed Microsoft Certificate services on a 2000 machine, and
> > autoenrolled all machines..
> >
> > Now I am testing revocation.
> > The CRL is set to publish every 5 hours..
> >
> > I can establish a certificate and authenticate my session without
> > fault. However, now I revoke my certificate - it shows in the CRL -
> > but I can still authenticate???!!!
> >
> > How can this be? I would expect that the IAS server would check
> > against the revocation list and see that my cert is revoked (listed as
> > superseeded)..
> >
> > how come I can still connect? Does IAS not check the CRL?
> >
>
> You should not rely on certificate revokation to disable access. The CRL
> is cached and will not be reloaded until it expires. Also, you're
> generating a lot of extra traffic by setting your publication interval to 5
> hours.
>
> If you want to disable a users or computers access, disable the account or
> adjust the dial-in properties. Certificates are for authentication, not
> access control.
>
> HTH,
>
> Wayne Tilton
>

*minor* sucess...
For Thread integrity - I just thought others might be aware of what I found.

PEAP is only supports "server side" authentication.. In other words - if the
server has a valid certificate - and the client can confirm this (ie.. has a
root cert) then it will authenticate.

I want client authentication - so I simply changed from "PEAP" to "Smartcard
or Certifictae". Now I have client Authentication beyond simply having the
root certificate installed. If a client hasn't a cert signed by the CA and
attribute of "Client Authentication" then it will not be allowed.

I am just waiting for my CRL to update to see if my (now revoked)
certificate is picked up by the IAS server.
I'll update if it does.

"MichaelW - Melb.Aus." wrote:

> I am having a weird problem but I am not sure if it is a fault or what it
> is!??!
>
> I have IAS authenticating an 802.11g AP using AES/PEAP.
> I have installed Microsoft Certificate services on a 2000 machine, and
> autoenrolled all machines..
>
> Now I am testing revocation.
> The CRL is set to publish every 5 hours..
>
> I can establish a certificate and authenticate my session without fault.
> However, now I revoke my certificate - it shows in the CRL - but I can still
> authenticate???!!!
>
> How can this be? I would expect that the IAS server would check against the
> revocation list and see that my cert is revoked (listed as superseeded)..
>
> how come I can still connect? Does IAS not check the CRL?

"=?Utf-8?B?TWljaGFlbFcgLSBNZWxiLkF1cy4=?="
<(E-Mail Removed)> wrote in
news:9FF4407F-6CB5-4F81-936F-(E-Mail Removed):

I'm just telling you what Microsoft says. Quoting Sam Salhi (MSFT) from
a post made Feb 20, 2004, he says:

"IAS doesn't store the CRL, PKI does. This CRL is not flushable.
although, the metadata in a specific certificate can be modified to point
to a file IAS uses certificate to identify and validate the user
credentials. It doesn't use the certificate to authorize the user. It
needs an account in AD that the certificate maps to. I will say it again,
Restricting access based on certificate revocation IS NOT RECOMMENDED!
Disable/lock/expire/remove dial in the user account instead"

Here's the thread:

http://groups.google.com/group/micro...dius/browse_th
read/thread/a1c197f4f6da59e3/fea035b885a8700f?lnk=st&q=eap-
tls+crl+checking&rnum=4&hl=en#fea035b885a8700f

Or search Google groups for "eap-tls crl checking"

Wayne

> I'll take a traffic hit for an updated CRL - even 1Mb every 5 hours to
> our remote sites is bugger all if it means that I can ensure systems
> security.
>
> However, I disagree with your "authentication" comment "not for access
> control".
>
> Certificates are revoked for exactly this reason.. they are no longer
> trusted. This is whole REASON for certificates - defining who we
> trust. In this case, we trust the CA - if I have a certificate signed
> by the CA - then I am a trusted person to others who trust it. I would
> like to be told if I am NOT to trust someone - and that is EXACTLY
> what the CRL is for.
>
> The way these certificates work is exactly as defined..
> I have just proven, as a client I don't need to have a certificate to
> authenticate against the certificate on the IAS server - I only need
> to TRUST the certificate installed on the IAS server.
>
> This means that anyone with a copy of the CA's certificate (in
> essence, downloaded straight off the CA's website) can access the
> network.
>
> What SHOULD occur, is that the ISA server should authenticate against
> the clients CERTIFICATE - and if that cert is trusted - then allow in.
> The trust is at least the wrong way around.. the client should be the
> one that is authenticated.
>
> the way it is right now - I trust anyone who can connect to my CA and
> download the CA's certificate - isn't that just the same as "I trust
> you - here is my password"??!!
> What happens when I no longer trust that person? Ask them not to use
> the password anymore? I don't think so..
>
>
>
> "Wayne Tilton" wrote:
>
>> "=?Utf-8?B?TWljaGFlbFcgLSBNZWxiLkF1cy4=?="
>> <(E-Mail Removed)> wrote in
>> news:E2970912-A57D-4F4D-98D2-(E-Mail Removed):
>>
>> > I am having a weird problem but I am not sure if it is a fault or
>> > what it is!??!
>> >
>> > I have IAS authenticating an 802.11g AP using AES/PEAP.
>> > I have installed Microsoft Certificate services on a 2000 machine,
>> > and autoenrolled all machines..
>> >
>> > Now I am testing revocation.
>> > The CRL is set to publish every 5 hours..
>> >
>> > I can establish a certificate and authenticate my session without
>> > fault. However, now I revoke my certificate - it shows in the CRL -
>> > but I can still authenticate???!!!
>> >
>> > How can this be? I would expect that the IAS server would check
>> > against the revocation list and see that my cert is revoked (listed
>> > as superseeded)..
>> >
>> > how come I can still connect? Does IAS not check the CRL?
>> >
>>
>> You should not rely on certificate revokation to disable access. The
>> CRL is cached and will not be reloaded until it expires. Also,
>> you're generating a lot of extra traffic by setting your publication
>> interval to 5 hours.
>>
>> If you want to disable a users or computers access, disable the
>> account or adjust the dial-in properties. Certificates are for
>> authentication, not access control.
>>
>> HTH,
>>
>> Wayne Tilton
>>
>

Final Addendum:
With the current setup - CRL's are working correctly!

YAY!

It would seem that PEAP functions (as I now know) as advertised. It doesn't
care about a client certificate - only if the client trusts the CA.

To get the client authentication working - you need to use TLS..

AES + "Smartcard and Certificate" = AES+TLS and when you use THIS
combination - then the client certificate will be checked for revocation and
the Radius server will deny access... ie. work exactly like I want!

Thanks for everyone's input...

now I just need to get TLS + Terminal Server to accept client certificates
too and I am home-and-hosed!

Regards,
Michael
melbourne, australia.

"MichaelW - Melb.Aus." wrote:

> I am having a weird problem but I am not sure if it is a fault or what it
> is!??!
>
> I have IAS authenticating an 802.11g AP using AES/PEAP.
> I have installed Microsoft Certificate services on a 2000 machine, and
> autoenrolled all machines..
>
> Now I am testing revocation.
> The CRL is set to publish every 5 hours..
>
> I can establish a certificate and authenticate my session without fault.
> However, now I revoke my certificate - it shows in the CRL - but I can still
> authenticate???!!!
>
> How can this be? I would expect that the IAS server would check against the
> revocation list and see that my cert is revoked (listed as superseeded)..
>
> how come I can still connect? Does IAS not check the CRL?