[Opensim-dev] [REX] [Fwd: User Authentication]
Hurliman, John
john.hurliman at intel.com
Tue Feb 24 01:08:23 UTC 2009
Yes, with UDP that is easy to do (and has been used in multiple attacks against SL). Just don't expect any of the response data, since it will be routed to the correct owner of that IP endpoint.
John
>-----Original Message-----
>From: opensim-dev-bounces at lists.berlios.de [mailto:opensim-dev-
>bounces at lists.berlios.de] On Behalf Of Diva Canto
>Sent: Monday, February 23, 2009 4:56 PM
>To: opensim-dev at lists.berlios.de
>Subject: Re: [Opensim-dev] [REX] [Fwd: User Authentication]
>
>OK, so this is what I want to make sure.
>Can I, sitting here on my home network in California, send a UDP packet
>to an OpenSim region in France, pretending to be coming from some IP
>address other than mine? Can this be done using raw sockets?
>
>If so, then yes, this is not reliable and we need to think more. I'll
>think more about the CAPs follow up that you suggest.
>
>Teravus Ovares wrote:
>
> The only thing that concerns me about using the endpoint for
> authentication, is it's UDP. Anyone with access to raw sockets
>your
> IP address, UUID and circuit code, session ID, and SecureSessionId
> could pretend to be you. I would suggest a better way to
>validate
> the endpoint would be to verify the IP address on the Seed caps
>call
> parhaps. In theory, the initial seed cap would be gotten by the
>user
> server from the appropriate sim and forwarded to the user over
>SSL.
> There may also be some checking potential in that the user server
> could post the IP address that the simulator should expect a
> connection from. Then when the seed cap is requested, the
>simulator
> could check the IP with the User Server. The other aspect of
>this is
> securely ensuring that an avatar can only be in one
>place(simulator)
> at the same time. This could be done with some careful session
> locking.
>
> Best Regards
>
> Teravus
>
> On 2/23/09, Charles Krinke <cfk at pacbell.net>
><mailto:cfk at pacbell.net> wrote:
>
>
> Well, I suppose that since we can discern which viewer logs
>in via the
> UserServer, we can allow additional features for some
>viewers that dont
> exist for others.
>
> Dont know if that simplifies or complicates the problem,
>however.
>
> Charles
>
> ________________________________
> From: Diva Canto <diva at metaverseink.com>
><mailto:diva at metaverseink.com>
> To: opensim-dev at lists.berlios.de
> Sent: Monday, February 23, 2009 3:52:29 PM
>
> Subject: Re: [Opensim-dev] [REX] [Fwd: User Authentication]
>
> "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>
><mailto:mark.malewski at gmail.com>
>
>
> wrote:
>
>
>
>
> On Mon,
>
>
> Feb 23, 2009 at 3:28 PM, Mark Malewski
>
>
> <mark.malewski at gmail.com> <mailto: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/> <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> <mailto: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/>
><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
>
>
>
>
> _______________________________________________
> 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
>
>
>
>
More information about the Opensim-dev
mailing list