EAP-TTLS/EAP-TLS with freeRADIUS

[Phil Mayers]

On 11/27/2011 12:51 AM, Mr Dash Four wrote:
>
>> No, the shared secret is not transmitted over the wire.
>> For additinal information see RFC2865, §2:
>>
>> "When a password is present, it is hidden using a method based on the
>> RSA Message Digest Algorithm MD5. (see RFC131).
> MD5 is broken.

Thanks for the public service announcement. Do you seriously think the 
IETF, and the people responsible for RADIUS protocol evolution, aren't 
aware of this?

Seriously, what would you like us to do exactly? Travel back in time to 
the mid 1990s and re-do the first RADIUS implementations with end-to-end 
pluggable crypto, and at the same time arrange for the Wassenaar 
agreement to be revoked?

If you want better security than that provided by the shared secret, 
you're free to arrange it between your NAS and your radius server. Some 
places use IPSec for this purpose, or things like OpenVPN.

HOWEVER - before you do that, and before you make any more announcements 
on how insecure RADIUS is, perhaps you could actually put some time and 
effort into understanding the protocol. You are missing two critical 
bits of info:

Firstly, all radius packets carrying EAP MUST carry a 
Message-Authenticator attribute. This provides secure integrity proof 
(and thus authentication) of the ENTIRE packet payload, using a HMAC and 
the shared secret as a key. Many NASes support this attribute on all 
packets (not just EAP), and FreeRADIUS supports a configuration option 
to MANDATE the presence of this attribute in requests from client NASes.

Secondly, although radius packets are not encrypted, the payload data in 
EAP methods is. Put another way - EAP confidentiality and integrity is 
provided *by the EAP mechanisms*, not by the radius layer. For pre-EAP 
mechanisms, the shared secret encryption will encrypt some fields (e.g. 
User-Password, in PAP), and the remaining mechanisms tend to be 
challenge/response, with their own security properties.

When using Message-Authenticator (which, as required by RFCs, is the 
case for ALL EAP-over-RADIUS) the only meaningful "security problem" is 
a mild information leak of some NAS-related metadata (NAS-Port, etc.) in 
the packet. The rest of the information (EAP payload, 
Calling/Called-Station-Id, outer User-Name) are all sent in the clear by 
the client anyway, often over Wi-Fi.

Is the shared secret ideal? No. Is RADSEC better? Yes. Do any NAS 
vendors support it? No. Can we afford to stop using RADIUS? No.

> The question is - how do I specify the CA, CA2, server certificate/key
> and server certificate/key second pair (for phase two) in RADIUS?


Specify two different instances of the eap module. There is an example 
of this in the default configs in recent 2.1.x versions - see 
raddb/modules/inner-eap. Once you've done that, use the 2nd module 
inside your inner-tunnel, like so:

eap {
   tls {
     ... cert setup
   }
   ttls {
     ...
     virtual-server = inner-tunne
   }
}

eap eap-inner {
   tls {
     ... 2nd ca setup
   }
}


...then:

sites-available/default:

authorize {
   ...
   eap
   ...
}
authenticate {
   ...
   eap
}

sites-available/inner-tunnel:

server inner-tunnel {

authorize {
   ...
   eap-inner
   ...
}
authenticate {
   ...
   eap-inner
}

}