Dinesh

The basic mechanism is quite simple really, here is a brief description of the 
protocol:

The captive portal knows of:
1.  URL for the authentication server
2.  Its own 'location' (by default the system name)
3.  Shared secret.

When the user comes along and attempts an HTTP GET he is snagged by the portal 
in the normal way.  He then gets redirected to the authentication server with 
a GET and some embedded variables in the URL.  (These are the initial URL he 
was trying to get to, the user MAC address, the location and a security 
token).

The Authentication server pops up a page asking for username/password.  If 
these are correct, and match the MAC address recorded for this user, then the 
authentication server responds with a redirect back to the portal.  

This is a GET with embedded variables (MAC address, original URL, security 
token, expiry time).  The Portal checks the MAC address against the one 
currently being used, if it is the same the portal is opened for this MAC 
address up to the expiry time.  The user is then redirected to his originally 
requested site as normal.

The communication between the user and the authentication server (when the 
username/password is exchanged) goes over HTTPS so it cannot be sniffed.  

The outgoing request contains a token that is an md5($mac . $location . 
$secret) and the returned token is md5($origtoken . $expirytime . $secret).

So if somebody replays the original token they would get access (because the 
reply has no unique characteristics).  The solution lies in digital 
signatures on the server side and I am working on a protocol for this.  (I 
think that all that is needed is for the server to sign the original token 
and send back the sig, which can then be verified against a known public 
key).

If you can see any holes in this, please let me know because fraud protection 
is an important requirement for this system.

Cheers

Peter

On Thursday 10 June 2004 02:10, Dinesh Nair wrote:
> On Wed, 9 Jun 2004, Peter Curran wrote:
> > important (or relevant).  Having authenticated via the external service,
> > the user is redirected back to the portal with some embedded values in a
> > GET request.
>
> isnt this method susceptible to a man-in-the-middle replay attack ? a
> traffic snooper could read the redirected http request from the client,
> and replay this packet to the m0n0wall in order to get access.
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.