[RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS

[Sami Keski-Kasari]

Hello Christian,

Answer to first question:
------------------------

We have used AuthBy INTERNAL between actual AuthBys to modify request
message (for example in OTP cases that is very often needed to separate
first and second factor). In AuthBy INTERNAL you can have for example
AuthHook.

Your TLS case could be something like this:

<AuthBy SQL>
  	Identifier SQLauthorize
  	# sql based authorisation
  	NoEAP
</AuthBy SQL>

<AuthBy INTERNAL>
	Identifier AddPeerCertInfo
        NoEAP
        DefaultResult ACCEPT
        AuthHook sub{ my $p = $_[0];\
         my $context = $p->{EAPContext};\
         my $cert = Net::SSLeay::get_peer_certificate($context->{ssl});\
         my $subject_name = Net::SSLeay::X509_get_subject_name($cert);\
         my $subject = Net::SSLeay::X509_NAME_oneline($subject_name);\
         my $issuer_name = Net::SSLeay::X509_get_issuer_name($cert);\
         my $issuer = Net::SSLeay::X509_NAME_oneline ($issuer_name);\
         $p->add_attr('X-OSC-Client-Cert-Subject', $subject);\
         $p->add_attr('X-OSC-Client-Cert-Issuer', $issuer);\
         return $main::ACCEPT }
</AuthBy>

# EAP TLS based host authentication
<Handler User-Name = /host/>
  	Identifier 	TLS
	AuthByPolicy ContinueWhileAccept
  	AuthBy		FILE
        AuthBy          AddPeerCertInfo
  	AuthBy		SQLauthorize
 </Handler>

If you are using MSCHAPv2 in PEAP or TTLS then there won't peer
certificate. If you are using TLS inside PEAP or TTLS you can use
preauthhook or modify the AuthHook in AuthBy INTERNAL so that it will
take outer request EAPContext.

Answer to second question:
-------------------------

There are special characters %x and %X that include user's EAP-Identity.
%x is The EAP Identity for PEAP and TTLS inner requests.
%X is the EAP identity, with any trailing @realm stripped off.

I hope this helps.

Best Regards,
 Sami

On 02/19/2015 09:31 AM, Christian Kratzer wrote:
> Hi,
> 
> I would like some advice on how to balance my options with a customer
> setup I have been building.
> 
> This setup has both tunneled EAP PEAP and TTLS and non tunneled TLS
> based host authentication.
> 
> There is both a mschap based EAP authentication followed by an SQL based
> authorisation clause.
> 
> The basic structure is as follows:
> 
>      <AuthBy SQL>
>  	Identifier SQLauthenticate
>  	# mschap2 authentication
>      </AuthBy SQL>
> 
>      <AuthBy SQL>
>  	Identifier SQLauthorize
>  	# sql based authorisation
>  	NoEAP
>      </AuthBy SQL>
> 
>      <Handler TunnelledByPEAP=1>
>  	Identifier 	PEAP
>  	AuthByPolicy	ContinueWhileAccept
>  	AuthBy		SQLauthenticate
>  	AuthBy		SQLauthorize
>      </Handler>
> 
>      <Handler TunnelledByTTLS=1>
>  	Identifier 	TTLS
>  	AuthByPolicy 	ContinueWhileAccept
>  	AuthBy		SQLauthenticate
>  	AuthBy		SQLauthorize
>      </Handler>
> 
>      # EAP TLS based host authentication
>      <Handler User-Name = /host/>
>  	Identifier 	TLS
>  	AuthBy		FILE
>  	AuthBy		SQLauthorize
>      </Handler>
> 
>      <Handler>
>  	Identifier 	Outer
>  	AuthBy		EAPouterHandler
>      </Handler>
> 
> First question:
> ---------------
> 
> The fun starts as the customer needs varius data from the client
> certificates that we can extract in various hooks.
> 
> We have used the handler postAuthHook to access the peer certificate
> in the eap context and subsequently extract the issuer name and
> certificate policy from it and stick the data into the request.
> 
> The dilemma ist that postAuthHook is too late to use the extracted
> data in the SQLauthorize clause.
> 
> We would also not like to delegate the authorisation logic to
> the postauthhook.  The authorisation is basically a psql stored
> procedure that encapsulates all the business logic.  I would like to
> keep it visible in the configuration and not hidden in a hook.
> 
> We were successfull in extracting the certificate in the inner handlers
> preauthhook as the certifcate has been extracted in the outer handler
> and is available at this point.
> 
> This does not work for EAP TLS though as TLS is not tunneled.
> 
> I could propably use one of the hooks in EAP_13 (TLS) like perhaps
> EAPTLS_CertificateVerifyHook to handle the TLS cass and the
> preHandlerHook for the tunneled methods.
> 
> On the other hand I could propably patch the EAP PEAP,TTLS,TLS handlers
> and provide a generic way to map certificate data into the request.
> 
> Do you have any advice on how to best handle this.
> 
> Second question:
> ----------------
> 
> We would also need the User and realm from the inner eap identity in
> above authorisation clauses.  How could those best be accessed.  The
> autorisation clauses use NoEAP in order to not interfere with the
> EAP challenge authentication.  So the usual variables seem to have the
> outer identity.
> 
> Greetings
> Christian
> 


-- 
Sami Keski-Kasari <samikk at open.com.au>

Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.