[Opensim-dev] [REX] [Fwd: User Authentication]
Hurliman, John
john.hurliman at intel.com
Mon Feb 23 23:44:29 UTC 2009
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: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>bounces at lists.berlios.de] On Behalf Of Mark Malewski
>Sent: Monday, February 23, 2009 3:04 PM
>To: Opensim-dev at lists.berlios.de
>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 (hostname at domain.com).
>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:
>
>hostname at be-70-ar01.area1.il.chicago.comcast.net
>
>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 <mark.malewski at gmail.com>
>wrote:
>
>
>
>
> On Mon, Feb 23, 2009 at 3:28 PM, Mark Malewski
><mark.malewski at gmail.com> 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/> \username at anotherdomain.com
>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
><antont at kyperjokki.fi> 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
>Charles.Krinke at osgrid.org is, indeed,
> representing Charles.Krinke at osgrid.org. (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
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
>
>
>
>
More information about the Opensim-dev
mailing list