Freeradius and EAP_TLS Problem:

[John Dennis]

On 01/23/2013 12:24 PM, John Dennis wrote:
> On 01/23/2013 04:32 AM, Armin Maier wrote:
>> Hello!
>> I have been using Windows 7, Freeradius 2.1.10 from Debian Squeeze, HP
>> MSM710 WLAN controller and EAP_TLS Computer Certificate Authentication
>> for a log time and worked perfect. I used Certificates created on the
>> Debian server by openssl including the extensions for Client
>> Authentication and Server Authentication.
>> Now we want to activate port security on our physical switches and use
>> the same radius server, so we installed a Windows Enterprise Root CA for
>> autoenrollment of the Client and server certificates. I also created an
>> RAS IAS Certificate for the Radius Server and installed them, they are
>> loaded without any problems, but authentication of the Windows 7 client
>> do not work anymore.
>>
>> I searched the internet for a compareable setup but i cannot find any
>> hints for using Microsoft Enterprise CA with freeradius server, may
>> everywhere else it works like a charm :) , but cannot believe it!
>>
>> So my first question, does someone use Microsoft Enterprise CA
>> Certificates with freeradius in a working environment, and o i have to
>> regard something special?
>>
>> Running "freeradius -X" gives me the following errors:
>>
>> ...
>> Found Auth-Type = EAP
>> # Executing group from file /etc/freeradius/sites-enabled/default
>> +- entering group authenticate {...}
>> [eap] Request found, released from the list
>> [eap] EAP/tls
>> [eap] processing type tls
>> [tls] Authenticate
>> [tls] processing EAP-TLS
>>      TLS Length 95
>> [tls] Length Included
>> [tls] eaptls_verify returned 11
>> [tls]     (other): before/accept initialization
>> [tls]     TLS_accept: before/accept initialization
>> [tls] <<< TLS 1.0 Handshake [length 005a], ClientHello
>> [tls]     TLS_accept: SSLv3 read client hello A
>> [tls] >>> TLS 1.0 Handshake [length 0031], ServerHello
>> [tls]     TLS_accept: SSLv3 write server hello A
>> [tls] >>> TLS 1.0 Handshake [length 08d7], Certificate
>> [tls]     TLS_accept: SSLv3 write certificate A
>> [tls] >>> TLS 1.0 Handshake [length 0062], CertificateRequest
>> [tls]     TLS_accept: SSLv3 write certificate request A
>> [tls]     TLS_accept: SSLv3 flush data
>> [tls]     TLS_accept: Need to read more data: SSLv3 read client
>> certificate A
>> In SSL Handshake Phase
>> In SSL Accept mode
>> [tls] eaptls_process returned 13
>> ++[eap] returns handled
>> ...
>>
>>
>> I updated to Debian wheezy to get a newer freeradius version, but
>> nothing changed.
>
> It's not likely related to FreeRADIUS, the FreeRADIUS server for the
> most part hands off the SSL processing to the openssl library.
>
>> The Radius Server Certificate include the following Attribute (output of
>> "openssl x509 -text -in <cert> -noout"):
>>
>
> It's not likely related to the server cert either, the debug shows the
> problem is occurring reading the client cert during the ssl handshake.
>
>> The Client Certificates include the following Attributes:
>>
>> Key usage:    Digital Signature, Key Encipherment (a0)
>> Enhanded Key Usage:    Client Authentication (1.3.6.1.5.5.7.3.2)
>>
>> The client attributes also include
>> - Authority Information Access
>> - CRL Distribution Points
>> - Certificate Template Information
>> which have very long values with special caracters like _%/=:?, may this
>> be a problem?
>
> Here is what I think is going on. First observe that openssl is
> complaining it needs to read more data from the client cert. That means
> it's confused about the contents of the client cert. It appears as if
> you had trouble dumping the contents of the client cert using the
> openssl x509 command as well. That suggests there are two possibilities.
> Recall that certs are binary encoded data (ASN.1 DER), that encoding
> includes information about the length of the data items in the binary
> data stream. The first possibility is that openssl is not decoding the
> cert correctly and is getting confused over length of items in the cert
> and what they represent. This is supported by the fact it was expecting
> more data and your attempt at dumping the cert seemed to produce
> garbage. The second possibility is that the cert itself is corrupt.
>
> Did you upgrade your openssl library recently?
>
> I would try using an alternate crypto implementation to dump the cleint
> cert and see if you get more reasonable output. The two other popular
> crypto implementations are NSS and GnuTLS. If those implementations
> correctly decode the cert then your problem is almost certainly your
> openssl version. If those other tools can not decode the cert then it's
> likely the cert is corrupt. Note also the problem seems to be decoding
> an cert extension and extension decoders get less testing so it wouldn't
> surprise me if there was a decoding bug.
>
> I have the tools readily available if you don't and would like me try
> reading the cert if you send it to me privately (without the matching CA
> cert used to sign it it's of no value to me so as long as it's not a
> public CA it's a safe thing to do)

Just to follow up, I received the cert privately and decoded it with 
NSS, it looks fine. It had two Microsoft extensions

Certificate template extension (v2)
         szOID_CERTIFICATE_TEMPLATE              1.3.6.1.4.1.311.21.7

Application Policies extension -- same encoding as szOID_CERT_POLICIES
         szOID_APPLICATION_CERT_POLICIES         1.3.6.1.4.1.311.21.10

whose contents were unknown to NSS but NSS was still able to fully 
process the entire cert. The same held true for openssl (version 
openssl-1.0.0j) on my system. I think the funny characters from the 
openssl dump are just openssl's silly way of displaying unrecognized 
data (printable ascii).

So, cert seems fine. My best guess at this point is some malformed ASN.1 
encode/decode somewhere in the SSL handshake which wraps the cert 
exchange, could be happening on either side.

-- 
John Dennis <jdennis at redhat.com>

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/