A RADIUS server is a solution to the problem of authentication. OpenID is a solution for federated identity, and plays nicely with any authentication solution you want to use. I think the description of this particular problem is closer to identity verification across administrative domains than defining a common login protocol, so the OpenID + token systems sound like the right approach. However, this would currently have to happen purely as communication between backend services since we can't change the viewer. A possible flow might be:
(OSGrid)->(UCI) "User http://www.osgrid.org/users/Charles_Krinke is teleporting to you. His token is abcdef" (UCI)->(http://www.osgrid.org/users/Charles_Krinke) "I have the token abcdef, is that a valid session token for Charles?" (UCI)<-(http://www.osgrid.org/users/Charles_Krinke) "Yes it is" (OSGrid)<-(UCI) "That worked, thanks. Teleport is finished" Notice that Charles happens to have his identity at OSGrid, but that's not a requirement of the exchange. It could just as easily been an identity from another grid, which will be useful for teleporting from UCI to ScienceSim. John >-----Original Message----- >From: [email protected] [mailto:opensim-dev- >[email protected]] On Behalf Of Mark Malewski >Sent: Monday, February 23, 2009 3:04 PM >To: [email protected] >Subject: Re: [Opensim-dev] [REX] [Fwd: User Authentication] > >Crista, > >> The bottom line question in my email, phrased in OpenID terminology, >is whether we >> can use the Viewer's IP address as the token. > >My question is, would you really want to use the Viewer's IP address as >the token? What IP address would it specifically use? > >If a user were on an internal LAN, would it use the 192.168.1.x IP >address (local internal LAN address) or 10.x.x.x? or 172.x.x.x? > >Or would it use the external routable IP address (from the ISP)? If >that were the case, then wouldn't 2 viewers that are accessing a server >from the same location (for example a library, or school, or >work/office) where multiple computers on the same internal LAN would try >to connect to an external grid server, then wouldn't the viewer's all >have the same IP address? > >Keep in mind, that most users are using NAT behind their firewall, so >what IP address would you even use for the token? > >A better address would be the hostname address ([email protected]). >This way each and every machine would always hava a unique hostname, and >it's tied to a specifc domain (whether it's an internal domain, a LAN, >or even the WAN/ISP domain name given by your local ISP, such as a local >comcast user: > >[email protected] > >It might make more sense to use hostname instead of an IP address. So >maybe use the machine's full FQDN hostname as the token? > >I still think a RADIUS server would be the best bet (the solution I >described in the message below), as the best possible longterm solution >to this problem. > >We would probably need to create some type of "RADIUS" module for >OpenSim. > > Mark > > >On Mon, Feb 23, 2009 at 3:29 PM, Mark Malewski <[email protected]> >wrote: > > > > > On Mon, Feb 23, 2009 at 3:28 PM, Mark Malewski ><[email protected]> wrote: > > > Crista, > > Sounds like you are on the right track. Sounds like a very >"logical" process, but why not use something like 802.1x/EAP? > > > So, what can we do to detect the legitimacy of agents? > > Instead of a "Finnish Magic", why not use 802.1x and use a >RADIUS server for standard authentication? > > Using simple 802.1x, the authenticator sends an "EAP- >Request/Identity" packet to the supplicant as soon as it detects that >the link is active (the user has associated with the grid/radius >server). > > > 1. The supplicant sends an "EAP-Response/Identity" packet >to the authenticator, which is then passed on to the authentication >(RADIUS) server. > > 2. The authentication server sends back a challenge to >the authenticator, such as with a token password system. The >authenticator unpacks this from IP and repackages it into EAPOL and >sends it to the supplicant. Different authentication methods will vary >this message and the total number of messages. EAP supports client-only >authentication and strong mutual authentication. Only strong mutual >authentication is considered appropriate for the virtual world case. > > 3. The supplicant responds to the challenge via the >authenticator and passes the response onto the authentication server. > > 4. If the supplicant provides proper identity, the >authentication server responds with a success message, which is then >passed onto the supplicant. The authenticator now allows access to the >LAN- - possibly restricted based on attributes that came back from the >authentication server. For example, the authenticator might switch the >supplicant to a particular virtual LAN or install a set of firewall >rules. > > 802.1x is a standard, and many wireless LAN vendors have >latched onto 802.1x standard to help authenticate and secure both wired >and wireless LANs. The greatest feature of 802.1x is interoperability. > > It would seem to make sense to just use 802.1x >authentication, EAP is supposed to head off proprietary authentication >systems and let everything from passwords to challenge-response tokens >and public-key infrastructure certificates all work smoothly. > > Why not just use a standard RADIUS server as the >authentication server? With 802.1x, the user or client that wants to be >authenticated would be called a "supplicant". The actual server doing >the authentication (typically a RADIUS server) is called the >authentication server. The device in between (such as a wireless access >point, or any region/grid server) is called the "authenticator". One of >the key points is that the authenticator can be simple and dumb, all of >the "brains" have to be in the supplicant and the authentication server. > > Each Grid could run their own separate RADIUS server, and >user groups could be setup to allow users to "hypergrid" between grids >(securely). [By setting up REALMS between Grids] > > Each grid would be responsible for checking the "legitimacy" >of it's users (via E-mail confirmation, etc.) and if any user was "up to >no good" then their user ID can be disabled, and their IP address can be >blocked (by the RADIUS server). > > http://freeradius.org/ > > Using a standard FreeRADIUS server would make it extremely >easy for Grid Administrators to Administer User accounts. RADIUS would >provide centralized access, authentication and accounting management for >users of the Grid. > > http://en.wikipedia.org/wiki/RADIUS > > If someone attempted to "hijack" a secure session, the >RADIUS server checks that the information is correct using >authentication schemes like PAP, CHAP or EAP. The RADIUS server than >returns one of three responses ("Yea", "Nay", or "Challenge"). > > The "Access Challenge" requests additional information from >the user (such as a secondary password, or a PIN number, mother's maiden >name, secret password, or a token or even a secureID card, biometrics, >etc.) > > Similar to how a web-based online banking system (like Bank >of America) works. If you are using the same computer all the time, it >only asks for your username and password. If you attempt to login from >a new or different computer, then it kicks back an Access Challenge, and >asks you for additional information (like a secret password, or a PIN, >or to verify your mother's maiden name, or any of several challenge >passwords that only the actual user would know). > > If the Challenge is successful, then the secure tunnel is >established between the user machine and the RADIUS server (and access >credentials are completely hidden). > > By using RADIUS, we could also grant users access by groups. >There could be an "Administrators" groups setup, and "Moderator" groups, >and "Peace Keepers" groups, and various groups with certain permissions >setup. > > Also certain information is stored in the RADIUS server (IP >address of the user, maximum length that the user may remain connected, >an access list, priority queue or other restrictions on a user's access, >VLAN parameters, QoS parameters, etc.) > > RADIUS is commonly used to facilitate roaming between ISPs, >for example by companies which provide a single global set of >credentials that are usable on many public networks. RADIUS facilitates >this by the use of realms, which identify where the RADIUS server should >forward the AAA requests for processing. > > > A realm is commonly appended to a user's user name and >delimited with an '@' sign, resembling an email address domain name. >This is known a postfix notation for the realm. Another common usage is >prefix notation, which involves prepending the realm to the username and >using '\' as a delimiter. Modern RADIUS servers allow any character to >be used as a realm delimiter, although in practice '@' and '\' are >usually used. > > Realms can also be compounded using both prefix and postfix >notation, to allow for complicated roaming scenarios; for example, >somedomain.com <http://somedomain.com/> \[email protected] >could be a valid username with two realms. > > Although realms often resemble email domains, it is >important to note that realms are in fact arbitrary text and need not >contain real domain names. > > So users from different Grids could roam freely between >"partnering" Grid servers using realms. > > > > > Proxy operations > > > When a RADIUS server receives an AAA request for a user name >containing a realm, the server will reference a table of configured >realms. If the realm is known, the server will then proxy the request to >the configured home server for that domain. The behaviour of the >proxying server regarding the removal of the realm from the request >("stripping") is configuration-dependent on most servers. In addition, >the proxying server can be configured to add, remove or rewrite AAA >requests when they are proxied. > > I believe the first step would be to get a RADIUS server >setup and working, and then work on setting up two grids together (using >REALM between the two RADIUS servers) and then once this could be done, >then later additional grids could be "trusted" and allowed onto the >network. So users could roam freely between the "trusted grids". > > If a user was reported to the Grid Owner (as being an >"abusive user") then the Grid owner would suspend that user's account, >and send an "abuse notification" to the Grid Owner (that the user has >violated the Terms of Service for the Grid). Basically just "pull the >plug" on that user's account, and kick them off the grid, and ban their >computer & IP address. > > It would make it extremely easy for "policing" the Grid, and >any users that want "Secure Inter-Grid" handshakes would just join the >REALM network. > > Mark > > P.S. If you need some help with this, I'm sure we can sit >down and discuss it a bit, and set something up as a "demo" grid as to >how this could be done. Then later other Grids (like OS Grid, and >various others) could join the REALM grid network. > > > > > On Mon, Feb 23, 2009 at 2:19 PM, Toni Alatalo ><[email protected]> wrote: > > > this kinda sounds like trying to achieve what rexauth >does, no? > > perhaps someone could write how it is w.r.t to that >case? i might be > able, but too tired now and probably busy tomorrow. > > also John Hurliman is planning new auth stuff with >openid and some > openid related token thing (i forgot the name) which >is basically 'same > as rexauth but standards instead of Finnish magic', >like he said the > other day :) .. so perhaps he replies his plan there, >seems to be online > at least. > > ~Toni > > --~--~---------~--~----~------------~-------~--~----~ > this list: http://groups.google.com/group/realxtend > realXtend home page: http://www.realxtend.org/ > -~----------~----~----~----~------~----~------~--~--- > > > > Hi, > > I'm about to start tightening the ropes for the >Hypergrid in order to > make it safer, and also make safer some loose ends of >OpenSim without > HG, and I would appreciate feedback on this. > > The first issue that needs to be addressed is the >issue of user > authentication. The regions need to be able to verify >that the agent > that claims to be representing >[email protected] is, indeed, > representing [email protected]. (As you know, >right now this > is... err... a bit overlooked... *coughs*... and not >just in the HG... > *more coughs*). > > Having looked at OpenID, I came to the conclusion that >it's not enough > to know that osgrid.org <http://osgrid.org/> has a >user named "Charles Krinke", and we > certainly don't want Charles to be constantly typing >his password > everytime he moves; the region needs to know that this >user is already > logged in to the system AND the region also needs to >know that the agent > that is representing this user is a legitimate agent. > > OK, so the part about being logged in is easy; the >user server already > knows that, to some approximation. > > However, the part about the agent being legitimate is >a bit more tricky. > Here's the bad thing that can happen: Charles logs in >to OSgrid, and TPs > to this intriguing region called "Sports Illuminated >Swimming Suite > Edition". That region happens to be up to no good. It >grabs Charles > current notion of identity (all the current >identifiers we use), it > crashes Charles' viewer so that the user server never >knows about it, > and proceeds to impersonate Charles using all those >stolen identifiers; > for example, it can go back to Charles's regions and >erase them > completely pretending to be Charles. > > So, what can we do to detect the legitimacy of agents? > > Having scratched my head over this, I came to the >conclusion that the > most promising element that can be used to identify >agents is the > Viewer's EndPoint. This is what happens down in the >LLUDPServer (I'm > sure something similar happens in other viewers' >packet handlers): > > if (packet != null) > { > if (packet.Type == >PacketType.UseCircuitCode) > >AddNewClient((UseCircuitCodePacket)packet, epSender, > epProxy); > else > ProcessInPacket(packet, epSender); > } > > The EndPoint epSender comes directly from the socket >and I'm assuming it > can't be faked, at least the IP part. Is this correct? >This is a > critical assumption. > > So, back to the "Sports Illuminated" scenario: that >sim would then try > to launch an agent at Charles' region. It can fake >everything except > being Charles' viewer machine. When Charles' region >does that code > above, it asks the User server for authentication of >an agent with all > those identifiers and the given EndPoint, and the User >server tells back > that Charles wasn't using that EndPoint to start with, >so the > authentication fails, and an alarm is rang. > > Thoughts? > > Crista > > Disclaimer: I'm not an expert in security, I'm just >using my brain in > context. > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > > > _______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
