(RADIATOR) Digipass, PPTP and MSCHAPV2

[Clem Colman]

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.

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,
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.