[RADIATOR] two factor authentication
Heikki Vatiainen
hvn at open.com.au
Wed Feb 1 15:37:44 CST 2012
On 02/01/2012 04:01 PM, Alexander Hartmaier wrote:
> should I use an AuthHook within the AuthBy INTERNAL?
> Documentation for the list of passed parameters for the hooks would be
> nice so you don't have to look in the source code, if you're a Perl
> developer :)
The hook parameters for INTERNAL are described in section "5.50 <AuthBy
INTERNAL>". The hooks themselves are mentioned in subsections, but they
all have the same parameters. Now that you mentioned, this seems to be
an exception to normal documentation where the parameters are described
together with the hook.
> That's what replaced the AuthBy HANDLER:
>
> <AuthBy INTERNAL>
> DefaultResult ACCEPT
>
> # clear the password to force AuthOTP to always generate a OTP
> AuthHook sub { \
> my $p = ${$_[0]}; \
> $p->{DecodedPassword} = ''; \
> return $main::ACCEPT; \
> }
> </AuthBy>
>
> AuthBy otp_sms
>
> I hope the ACCEPT doesn't trigger a hidden security problem, the handler
> is configured with ContinueUntilChallenge.
If you are worried about AuthBy INTERNAL's ACCEPT being used as the
return value from the Handler, use AuthByPolicy ContinueAlways. If there
are other AuthBys in the hook, you could put the above in an AuthBy
GROUP to make sure both are always executed without affecting any other
authbys.
Thanks!
Heikki
> Best regards, Alex
>
> Am 2012-01-19 00:28, schrieb Hugh Irvine:
>> Hello Alex -
>>
>> You can use an AuthBy INTERNAL between the other two clauses.
>>
>> See section 5.50 in the Radiator 4.9 reference manual ("doc/ref.pdf").
>>
>> regards
>>
>> Hugh
>>
>>
>> On 18 Jan 2012, at 21:16, Alexander Hartmaier wrote:
>>
>>> Hi Heikki and Mike,
>>> I'm already using AuthBy OTP with my own ChallengeHook.
>>> I've read RFC2865 yesterday but missed the State attribute, thanks for
>>> the great pointer!
>>>
>>> Thats the working config I came up with:
>>>
>>> <AuthLog FILE>
>>> Identifier tsa-otp-client-vpn
>>>
>>> Filename %L/tsa-otp-client-vpn.authlog
>>> LogSuccess 1
>>> LogFailure 1
>>> # log the Handler Identifier to be able to distinguish between AD
>>> and OTP auth failures
>>> SuccessFormat %l:%U:%{Request:Callback-Number}:%{Handler:Identifier}:OK
>>> FailureFormat
>>> %l:%U:%{Request:Callback-Number}:%{Handler:Identifier}:FAIL
>>> </AuthLog>
>>>
>>> <Handler Callback-Number=/.+/>
>>> Identifier otp_sms_challenge
>>>
>>> AuthByPolicy ContinueUntilChallenge
>>>
>>> #StripFromRequest Password
>>>
>>> # clear the password to force AuthOTP to always generate a OTP
>>> PreAuthHook sub { \
>>> my $p = ${$_[0]}; \
>>> my $rp = ${$_[1]}; \
>>> $p->{DecodedPassword} = ''; \
>>> }
>>> AuthBy otp_sms
>>> #AddToReply State="otp-challenge"
>>> </Handler>
>>>
>>> <Handler Client-Identifier="tsa-tc-flod|localhost"
>>> Request-Type="Access-Request" State="otp-challenge">
>>> Identifier tsa-otp-client-vpn-otp
>>>
>>> AuthLog tsa-otp-client-vpn
>>> # Show any rejection reason to the end user
>>> RejectHasReason
>>>
>>> AuthBy otp_sms
>>> </Handler>
>>>
>>> <Handler Client-Identifier="tsa-tc-flod|localhost"
>>> Request-Type="Access-Request">
>>> Identifier tsa-otp-client-vpn-ad
>>>
>>> AuthByPolicy ContinueUntilChallenge
>>>
>>> # Show any rejection reason to the end user
>>> RejectHasReason
>>>
>>> AuthLog tsa-otp-client-vpn
>>>
>>> <AuthBy LDAP2>
>>> # Save time by never looking for a default
>>> NoDefault
>>>
>>> Host ip1 ip2 ip3
>>> Port 389
>>> Version 3
>>>
>>> # request timeout in seconds
>>> Timeout 2
>>>
>>> # don't try to reach the ldap for this amount of seconds after
>>> failure
>>> FailureBackoffTime 0
>>>
>>> UsernameAttr samaccountname
>>> # don't check the password, just for phone number lookup
>>> #PasswordAttr
>>> ServerChecksPassword
>>>
>>> # store the users mobile phone number in the Callback-Number
>>> radius attribute
>>> AuthAttrDef mobile,Callback-Number,request
>>> </AuthBy>
>>>
>>> <AuthBy HANDLER>
>>> HandlerId otp_sms_challenge
>>> </AuthBy>
>>> </Handler>
>>>
>>> I had to use AuthBy HANDLER for forcing AuthBy OTP to generate the token
>>> by using PreAuthHook to delete the DecodedPassword.
>>> As you see I've tried StripFromRequest Password which didn't work.
>>> I was looking for a way to clear the password between the AuthBy LDAP
>>> and AuthBy OTP.
>>> Is there a way to do this?
>>>
>>> Cheers, Alex
>>>
>>> Am 2012-01-17 21:12, schrieb Mike McCauley:
>>>> Hi Heikki,
>>>>
>>>> I wonder if he should also look at AuthBy OTP?
>>>> Cheers.
>>>>
>>>> On Tuesday, January 17, 2012 09:39:27 PM Heikki Vatiainen wrote:
>>>>> On 01/17/2012 08:13 PM, Alexander Hartmaier wrote:
>>>>>
>>>>> Hello Alexander,
>>>>>
>>>>>> I'm trying to implement a two factor auth where the user has to enter
>>>>>> his Active Directory credentials.
>>>>>> Radiator checks those against the AD, if successful creates an OTP and
>>>>>> sends that to the mobile phone number fetched from the AD.
>>>>> Add State attribute to the challenge at this point.
>>>>>
>>>>>> A challenge is returned to the NAS.
>>>>> See this for how NAS should react to challenge.
>>>>> http://tools.ietf.org/html/rfc2865#section-5.24
>>>>>
>>>>>> My problem is that I can't distinguish the initial request and the
>>>>>> challenge response which should skip the AD auth because this time the
>>>>>> password field holds the OTP response.
>>>>> State should be echoed back in the challenge response unless the NAS is
>>>>> badly broken.
>>>>>
>>>>>> By looking at the radius packets with tcpdump I couldn't find a
>>>>>> difference in the radius attributes sent that let me write two different
>>>>>> handlers.
>>>>>>
>>>>>> Ideas?
>>>>> Try something like this. Note that I have used a fixed value for
>>>>> challenge, but you could make it generic to protect against replay
>>>>> attacks or some other information that might be useful for selecting the
>>>>> correct handler for verifying the challenge.
>>>>>
>>>>> <Handler attribute=value,...,State=whatever>
>>>>> # Check challenge here
>>>>> </Handler>
>>>>>
>>>>> <Handler attribute=value,...>
>>>>> # Generate OTP here and send challenge
>>>>> <AuthBy ...>
>>>>> # AD auth happens here
>>>>> AddToReply State=whatever
>>>>> </AuthBy>
>>>>> </Handler>
>>>>>
>>>>>
>>>>>
>>>>> Please let us know how it goes.
>>>>> Heikki
>>>
>>> *"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
>>> 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 at open.com.au
>>> http://www.open.com.au/mailman/listinfo/radiator
>>
>> --
>>
>> Hugh Irvine
>> hugh 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.
>>
> _______________________________________________
> radiator mailing list
> radiator at open.com.au
> http://www.open.com.au/mailman/listinfo/radiator
--
Heikki Vatiainen <hvn 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.
More information about the radiator
mailing list