Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hi Sami, We made progress with our setup thanks to your previous tips. We now have following setup simplyfied a bit: Handler TunnelledByPEAP=1 Identifier TunnelledByPEAP=1 AuthByPolicy ContinueWhileAccept AuthBy SQLauthenticate AuthBy INTERNALextractFunnyStuffFromRequest AuthBy SQLauthorize /Handler Handler Identifier Outer AuthBy FILE /Handler the issue we are currently chasing is that the customer also wants failed authentications to proceed into SQLauthorize so he can possible put people into a walled garden with specific reply attributes. The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it seems to kill the EAP session and authentication terminates. Subsequent packets are not forwarded to the tunneled handler by the outer handler. Do you have a suggestion how to accomplish authorization after failed chap authentication. Terveisin Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hello Christian,
MSCHAPv2 is mutual authentication protocol where client requires
response from server. If the server doesn't send correct response client
will terminate connection.
So server can not just decide to accept authentication like in PAP case.
I think that it is not possible to build walled garden solution with
that protocol.
If you use for example PEAP/GTC or EAP-TTLS/PAP you can use AuthBy GROUP
to group sequences and use different policy inside them.
for example like this:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy GROUP
AuthByPolicy ContinueWhileReject
AuthBy SQLauthenticate
AuthBy INTERNAL
AuthHook sub {my $p = $_[0];\
$p-add_attr('X-OSC-Auth-Status', 'Rejected');\
return $main::ACCEPT}
/AuthBy
/AuthBy
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
In this example the inner AuthBy INTERNAL will change reject to accept
and mark it with vendor specific attribute that you can use in later
INTERNAL to determine if authentication was successful or not.
Best Regards,
Sami
On 02/24/2015 01:12 PM, Christian Kratzer wrote:
Hi Sami,
We made progress with our setup thanks to your previous tips.
We now have following setup simplyfied a bit:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy SQLauthenticate
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
Handler
Identifier Outer
AuthBy FILE
/Handler
the issue we are currently chasing is that the customer also wants
failed authentications to proceed into SQLauthorize so he can possible
put people into a walled garden with specific reply attributes.
The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it
seems to kill the EAP session and authentication terminates.
Subsequent packets are not forwarded to the tunneled handler by the
outer handler.
Do you have a suggestion how to accomplish authorization after failed
chap authentication.
Terveisin
Christian
--
Sami Keski-Kasari sam...@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.
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
What we've seen is that if a Windows client does EAP authentication, regardless which one, and it fails it doesn't try to do a DHCP request even if you reply a radius success and vlan attributes to the switch. On 2015-02-24 12:12, Christian Kratzer wrote: Hi Sami, We made progress with our setup thanks to your previous tips. We now have following setup simplyfied a bit: Handler TunnelledByPEAP=1 Identifier TunnelledByPEAP=1 AuthByPolicy ContinueWhileAccept AuthBy SQLauthenticate AuthBy INTERNALextractFunnyStuffFromRequest AuthBy SQLauthorize /Handler Handler Identifier Outer AuthBy FILE /Handler the issue we are currently chasing is that the customer also wants failed authentications to proceed into SQLauthorize so he can possible put people into a walled garden with specific reply attributes. The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it seems to kill the EAP session and authentication terminates. Subsequent packets are not forwarded to the tunneled handler by the outer handler. Do you have a suggestion how to accomplish authorization after failed chap authentication. Terveisin Christian *** T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien Handelsgericht Wien, FN 79340b *** Notice: This e-mail contains information that is confidential and may be privileged. If you are not the intended recipient, please notify the sender and then delete this e-mail immediately. *** ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hi Sami,
On Tue, 24 Feb 2015, Sami Keski-Kasari wrote:
Hello Christian,
MSCHAPv2 is mutual authentication protocol where client requires
response from server. If the server doesn't send correct response client
will terminate connection.
So server can not just decide to accept authentication like in PAP case.
I think that it is not possible to build walled garden solution with
that protocol.
Thanks. That makes sense. I forgot about the mutality in CHAP.
Greetings
Christian
If you use for example PEAP/GTC or EAP-TTLS/PAP you can use AuthBy GROUP
to group sequences and use different policy inside them.
for example like this:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy GROUP
AuthByPolicy ContinueWhileReject
AuthBy SQLauthenticate
AuthBy INTERNAL
AuthHook sub {my $p = $_[0];\
$p-add_attr('X-OSC-Auth-Status', 'Rejected');\
return $main::ACCEPT}
/AuthBy
/AuthBy
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
In this example the inner AuthBy INTERNAL will change reject to accept
and mark it with vendor specific attribute that you can use in later
INTERNAL to determine if authentication was successful or not.
Best Regards,
Sami
On 02/24/2015 01:12 PM, Christian Kratzer wrote:
Hi Sami,
We made progress with our setup thanks to your previous tips.
We now have following setup simplyfied a bit:
Handler TunnelledByPEAP=1
Identifier TunnelledByPEAP=1
AuthByPolicy ContinueWhileAccept
AuthBy SQLauthenticate
AuthBy INTERNALextractFunnyStuffFromRequest
AuthBy SQLauthorize
/Handler
Handler
Identifier Outer
AuthBy FILE
/Handler
the issue we are currently chasing is that the customer also wants
failed authentications to proceed into SQLauthorize so he can possible
put people into a walled garden with specific reply attributes.
The issue seems to be that when MS-CHAP2 fails in TunneledByPeap it
seems to kill the EAP session and authentication terminates.
Subsequent packets are not forwarded to the tunneled handler by the
outer handler.
Do you have a suggestion how to accomplish authorization after failed
chap authentication.
Terveisin
Christian
--
Christian Kratzer CK Software GmbH
Email: c...@cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer
Web: http://www.cksoft.de/
___
radiator mailing list
radiator@open.com.au
http://www.open.com.au/mailman/listinfo/radiator
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
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
AuthByPolicyContinueWhileAccept
AuthBy SQLauthenticate
AuthBy SQLauthorize
/Handler
Handler TunnelledByTTLS=1
Identifier TTLS
AuthByPolicyContinueWhileAccept
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 sam...@open.com.au
Radiator: the most portable, flexible and configurable RADIUS
Re: [RADIATOR] Extracting certificates info for EAP PEAP,TTLS,TLS
Hei Sami, On Thu, 19 Feb 2015, Sami Keski-Kasari wrote: 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. Thanks. That looks much simpler and fits nicely into the setup. Your TLS case could be something like this: 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. Thanks again. Did not see those options. I hope this helps. Yes it does a lot. I will proceed with building the setup. Kiitos ja Terveisin Christian -- Christian Kratzer CK Software GmbH Email: c...@cksoft.de Wildberger Weg 24/2 Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart Mobile: +49 171 1947 843 Geschaeftsfuehrer: Christian Kratzer Web: http://www.cksoft.de/ ___ radiator mailing list radiator@open.com.au http://www.open.com.au/mailman/listinfo/radiator
