[Opensim-dev] [REX] [Fwd: User Authentication]
Diva Canto
diva at metaverseink.com
Mon Feb 23 23:52:29 UTC 2009
"However, this would currently have to happen purely as communication
between backend services since we can't change the viewer."
This doesn't solve the man-in-the-middle problem in OSGrid itself, which
needs to be solved too, urgently.
I think my proposal does.
Crista
Hurliman, John wrote:
> 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
>>
>>
>>
>>
>>
>>
>
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090223/1d7fe3da/attachment-0001.html>
More information about the Opensim-dev
mailing list