(RADIATOR) Digipass, PPTP and MSCHAPV2

[Mike McCauley]

Hello Clem,


On Saturday 13 August 2005 06:44, Clem Colman wrote:
> Mike/Hugh,
>
> Thanks for your responses and confirming my suspicions.  Unfortunately
> it means Radiator can't do what I want in this particular application.
> The radius-pap authentication works just fine but unfortunately without
> at least MSCHAP authentication the Microsoft implementation of pptp
> cant negotiate mppe (Microsoft Point to Point Encryption), and hence no
> data encryption.  I'm far from an expert, but my understanding is the
> key negotiation and exchange is somehow tied up in password exchange.
> Whilst I know Bruce Schnier doesn't think much of mppe and the MS
> implementation of pptp, I'm sure he would think even less of pptp
> without any encryption at all.
>
> So, at the risk of seeming impertinent I was going to ask is the authby
> digipass module something provided to OSC as is, or it it something you
> maintain?  If it is something you maintain is there any prospect of
> getting MSCHAPV2 authentication added to it.  Provided that you have a
> mechanism for knowing the value on a digipass token (the simple
> non-challenge ones) at any particular point in time (or a handful of
> values within a certain tolerable time drift) there doesn't seem to be
> any reason you couldn't simply compute the MS Hash of the pin+current
> token display, apply the challenge provided by the MSCHAPV2 to the
> client, and see if the value provided by the client matches any of the
> values you compute as legitimate.

We build and maintain the AuthBy DIGIPASS module, which uses a binary library 
provided by Vasco. There seem to be some undocumented methods in that library 
that might be useful, and we are checking with Vasco now whether they can be 
used.

>
> I guess the first authentication will need to be done via pap-radius or
> some such, as the token needs to be synced with the database, for which
> you will need the actual token display, but it seems that after that
> the digipass code must have some ability to predict what will be on the
> display.
>
> I'm assuming of course that the GO3 digipass tokens operate in a
> similar manner to the old RSA SecureID, which had a temporal rotation.
> The security mechanism might be different here and may mean you can't
> know the token display ahead of time (although I wonder how you
> authenticate if you don't).  Also, if you are using some proprietary
> non-OSC api it may not allow you to precompute token displays, and
> hence the MS Hash of such a value.
>
> So from this lay person's perspective it seems like the problem is
> solvable, albeit with certain assumptions.  Any chance that you folks
> would consider implementing MSCHAPV2 into authby digipass?


Cheers.


>
> Cheers,
> Clem.
>
> On 12/08/2005, at 3:47 PM, Hugh Irvine wrote:
> > Hello Clem -
> >
> > It really is most helpful if you post a copy of your configuration
> > file and a trace 4 debug from Radiator showing what is happening.
> >
> > You are correct however when you say that PAP is required - from
> > section 6.55 of the Radiator manual ("doc/ref.html"):
> >
> > ......
> >
> > AuthBy DIGIPASS supports for Response Only (RO) and Challenge/Response
> > (CR) tokens. It supports Radius PAP, TTLS-PAP, EAP-GTC and EAP-OTP
> > authentication methods. When using Challenge/Response tokens with PAP
> > or TTLS-PAP, when the user enters an empty password, AuthBy DIGIPASS
> > will generate the Challenge to enter into the Digipass token. The
> > token will then generate a Response which the users enters as their
> > real password.
> >
> > .....
> >
> > Note that PAP is only relevant for the authentication.
> >
> > regards
> >
> > Hugh
>
> --
> Archive at http://www.open.com.au/archives/radiator/
> Announcements on radiator-announce at open.com.au
> To unsubscribe, email 'majordomo at open.com.au' with
> 'unsubscribe radiator' in the body of the message.

-- 
Mike McCauley                               mikem at open.com.au
Open System Consultants Pty. Ltd            Unix, Perl, Motif, C++, WWW
9 Bulbul Place Currumbin Waters QLD 4223 Australia   http://www.open.com.au
Phone +61 7 5598-7474                       Fax   +61 7 5598-7070

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 etc on Unix, Windows, MacOS etc.

--
Archive at http://www.open.com.au/archives/radiator/
Announcements on radiator-announce at open.com.au
To unsubscribe, email 'majordomo at open.com.au' with
'unsubscribe radiator' in the body of the message.