<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
OK, so this is what I want to make sure.<br>
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?<br>
<br>
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.<br>
<br>
Teravus Ovares wrote:
<blockquote
cite="mid:34cc66250902231619x3d8b67dcla2e73f16924300cf@mail.gmail.com"
type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:cfk@pacbell.net"><cfk@pacbell.net></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:diva@metaverseink.com"><diva@metaverseink.com></a>
To: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev@lists.berlios.de">opensim-dev@lists.berlios.de</a>
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
<a class="moz-txt-link-freetext" href="http://www.osgrid.org/users/Charles_Krinke">http://www.osgrid.org/users/Charles_Krinke</a> is teleporting
to you. His token is abcdef"
(UCI)->(<a class="moz-txt-link-freetext" href="http://www.osgrid.org/users/Charles_Krinke">http://www.osgrid.org/users/Charles_Krinke</a>) "I
have the token abcdef, is that a valid session token for Charles?"
(UCI)<-(<a class="moz-txt-link-freetext" href="http://www.osgrid.org/users/Charles_Krinke">http://www.osgrid.org/users/Charles_Krinke</a>) "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: <a class="moz-txt-link-abbreviated" href="mailto:opensim-dev-bounces@lists.berlios.de">opensim-dev-bounces@lists.berlios.de</a>
[<a class="moz-txt-link-freetext" href="mailto:opensim-dev">mailto:opensim-dev</a>-
<a class="moz-txt-link-abbreviated" href="mailto:bounces@lists.berlios.de">bounces@lists.berlios.de</a>] On Behalf Of Mark Malewski
Sent: Monday, February 23, 2009 3:04 PM
To: <a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
</pre>
</blockquote>
<pre wrap=""><!---->Subject: Re: [Opensim-dev] [REX] [Fwd: User
</pre>
<blockquote type="cite">
<pre wrap="">Authentication]
</pre>
</blockquote>
<pre wrap=""><!---->
Crista,
</pre>
<blockquote type="cite">
<pre wrap="">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 (<a class="moz-txt-link-abbreviated" href="mailto:hostname@domain.com">hostname@domain.com</a>).
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:
<a class="moz-txt-link-abbreviated" href="mailto:hostname@be-70-ar01.area1.il.chicago.comcast.net">hostname@be-70-ar01.area1.il.chicago.comcast.net</a>
</pre>
</blockquote>
<pre wrap=""><!---->
It might
</pre>
<blockquote type="cite">
<pre wrap="">make more sense to use hostname instead of an IP address. So
</pre>
</blockquote>
<pre wrap=""><!---->maybe use the
</pre>
<blockquote type="cite">
<pre wrap="">machine's full FQDN hostname as the token?
</pre>
</blockquote>
<pre wrap=""><!---->
I still think a RADIUS server
</pre>
<blockquote type="cite">
<pre wrap="">would be the best bet (the solution I
</pre>
</blockquote>
<pre wrap=""><!---->described in the message below), as
</pre>
<blockquote type="cite">
<pre wrap="">the best possible longterm solution
</pre>
</blockquote>
<pre wrap=""><!---->to this problem.
We would probably need
</pre>
<blockquote type="cite">
<pre wrap="">to create some type of "RADIUS" module for
</pre>
</blockquote>
<pre wrap=""><!---->OpenSim.
Mark
On Mon, Feb 23,
</pre>
<blockquote type="cite">
<pre wrap="">2009 at 3:29 PM, Mark Malewski <a class="moz-txt-link-rfc2396E" href="mailto:mark.malewski@gmail.com"><mark.malewski@gmail.com></a>
</pre>
</blockquote>
<pre wrap=""><!---->wrote:
On Mon,
</pre>
<blockquote type="cite">
<pre wrap="">Feb 23, 2009 at 3:28 PM, Mark Malewski
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-rfc2396E" href="mailto:mark.malewski@gmail.com"><mark.malewski@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<pre wrap=""><!----> authentication
</pre>
<blockquote type="cite">
<pre wrap="">(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
</pre>
</blockquote>
<pre wrap=""><!----> that came back from the
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!----> the
</pre>
<blockquote type="cite">
<pre wrap="">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).
<a class="moz-txt-link-freetext" href="http://freeradius.org/">http://freeradius.org/</a>
</pre>
</blockquote>
<pre wrap=""><!---->
Using a standard FreeRADIUS server would make it
</pre>
<blockquote type="cite">
<pre wrap="">extremely
</pre>
</blockquote>
<pre wrap=""><!---->easy for Grid Administrators to Administer User accounts. RADIUS
</pre>
<blockquote type="cite">
<pre wrap="">would
</pre>
</blockquote>
<pre wrap=""><!---->provide centralized access, authentication and accounting management
</pre>
<blockquote type="cite">
<pre wrap="">for
</pre>
</blockquote>
<pre wrap=""><!---->users of the Grid.
</pre>
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/RADIUS">http://en.wikipedia.org/wiki/RADIUS</a>
</pre>
</blockquote>
<pre wrap=""><!---->
If someone attempted
</pre>
<blockquote type="cite">
<pre wrap="">to "hijack" a secure session, the
</pre>
</blockquote>
<pre wrap=""><!---->RADIUS server checks that the information
</pre>
<blockquote type="cite">
<pre wrap="">is correct using
</pre>
</blockquote>
<pre wrap=""><!---->authentication schemes like PAP, CHAP or EAP. The RADIUS
</pre>
<blockquote type="cite">
<pre wrap="">server than
</pre>
</blockquote>
<pre wrap=""><!---->returns one of three responses ("Yea", "Nay", or "Challenge").
</pre>
<blockquote type="cite">
<pre wrap="">The "Access Challenge" requests additional information from
</pre>
</blockquote>
<pre wrap=""><!---->the user (such
</pre>
<blockquote type="cite">
<pre wrap="">as a secondary password, or a PIN number, mother's maiden
</pre>
</blockquote>
<pre wrap=""><!---->name, secret
</pre>
<blockquote type="cite">
<pre wrap="">password, or a token or even a secureID card, biometrics,
</pre>
</blockquote>
<pre wrap=""><!---->etc.)
Similar to
</pre>
<blockquote type="cite">
<pre wrap="">how a web-based online banking system (like Bank
</pre>
</blockquote>
<pre wrap=""><!---->of America) works. If you
</pre>
<blockquote type="cite">
<pre wrap="">are using the same computer all the time, it
</pre>
</blockquote>
<pre wrap=""><!---->only asks for your username and
</pre>
<blockquote type="cite">
<pre wrap="">password. If you attempt to login from
</pre>
</blockquote>
<pre wrap=""><!---->a new or different computer, then it
</pre>
<blockquote type="cite">
<pre wrap="">kicks back an Access Challenge, and
</pre>
</blockquote>
<pre wrap=""><!---->asks you for additional information
</pre>
<blockquote type="cite">
<pre wrap="">(like a secret password, or a PIN,
</pre>
</blockquote>
<pre wrap=""><!---->or to verify your mother's maiden name,
</pre>
<blockquote type="cite">
<pre wrap="">or any of several challenge
</pre>
</blockquote>
<pre wrap=""><!---->passwords that only the actual user would
</pre>
<blockquote type="cite">
<pre wrap="">know).
</pre>
</blockquote>
<pre wrap=""><!---->
If the Challenge is successful, then the secure tunnel
</pre>
<blockquote type="cite">
<pre wrap="">is
</pre>
</blockquote>
<pre wrap=""><!---->established between the user machine and the RADIUS server (and
</pre>
<blockquote type="cite">
<pre wrap="">access
</pre>
</blockquote>
<pre wrap=""><!---->credentials are completely hidden).
By using RADIUS, we could also
</pre>
<blockquote type="cite">
<pre wrap="">grant users access by groups.
</pre>
</blockquote>
<pre wrap=""><!---->There could be an "Administrators" groups
</pre>
<blockquote type="cite">
<pre wrap="">setup, and "Moderator" groups,
</pre>
</blockquote>
<pre wrap=""><!---->and "Peace Keepers" groups, and various
</pre>
<blockquote type="cite">
<pre wrap="">groups with certain permissions
</pre>
</blockquote>
<pre wrap=""><!---->setup.
Also certain information is stored
</pre>
<blockquote type="cite">
<pre wrap="">in the RADIUS server (IP
</pre>
</blockquote>
<pre wrap=""><!---->address of the user, maximum length that the user
</pre>
<blockquote type="cite">
<pre wrap="">may remain connected,
</pre>
</blockquote>
<pre wrap=""><!---->an access list, priority queue or other restrictions
</pre>
<blockquote type="cite">
<pre wrap="">on a user's access,
</pre>
</blockquote>
<pre wrap=""><!---->VLAN parameters, QoS parameters, etc.)
RADIUS is
</pre>
<blockquote type="cite">
<pre wrap="">commonly used to facilitate roaming between ISPs,
</pre>
</blockquote>
<pre wrap=""><!---->for example by companies
</pre>
<blockquote type="cite">
<pre wrap="">which provide a single global set of
</pre>
</blockquote>
<pre wrap=""><!---->credentials that are usable on many
</pre>
<blockquote type="cite">
<pre wrap="">public networks. RADIUS facilitates
</pre>
</blockquote>
<pre wrap=""><!---->this by the use of realms, which
</pre>
<blockquote type="cite">
<pre wrap="">identify where the RADIUS server should
</pre>
</blockquote>
<pre wrap=""><!---->forward the AAA requests for
</pre>
<blockquote type="cite">
<pre wrap="">processing.
</pre>
</blockquote>
<pre wrap=""><!---->
A realm is commonly appended to a user's user name
</pre>
<blockquote type="cite">
<pre wrap="">and
</pre>
</blockquote>
<pre wrap=""><!---->delimited with an '@' sign, resembling an email address domain
</pre>
<blockquote type="cite">
<pre wrap="">name.
</pre>
</blockquote>
<pre wrap=""><!---->This is known a postfix notation for the realm. Another common usage
</pre>
<blockquote type="cite">
<pre wrap="">is
</pre>
</blockquote>
<pre wrap=""><!---->prefix notation, which involves prepending the realm to the username
</pre>
<blockquote type="cite">
<pre wrap="">and
</pre>
</blockquote>
<pre wrap=""><!---->using '\' as a delimiter. Modern RADIUS servers allow any character
</pre>
<blockquote type="cite">
<pre wrap="">to
</pre>
</blockquote>
<pre wrap=""><!---->be used as a realm delimiter, although in practice '@' and '\'
</pre>
<blockquote type="cite">
<pre wrap="">are
</pre>
</blockquote>
<pre wrap=""><!---->usually used.
Realms can also be compounded using both prefix and
</pre>
<blockquote type="cite">
<pre wrap="">postfix
</pre>
</blockquote>
<pre wrap=""><!---->notation, to allow for complicated roaming scenarios; for
</pre>
<blockquote type="cite">
<pre wrap="">example,
</pre>
</blockquote>
<pre wrap=""><!---->somedomain.com <a class="moz-txt-link-rfc2396E" href="http://somedomain.com/"><http://somedomain.com/></a>
</pre>
<blockquote type="cite">
<pre wrap="">\<a class="moz-txt-link-abbreviated" href="mailto:username@anotherdomain.com">username@anotherdomain.com</a>
</pre>
</blockquote>
<pre wrap=""><!---->could be a valid username with two realms.
</pre>
<blockquote type="cite">
<pre wrap="">Although realms often resemble email domains, it is
</pre>
</blockquote>
<pre wrap=""><!---->important to note that
</pre>
<blockquote type="cite">
<pre wrap="">realms are in fact arbitrary text and need not
</pre>
</blockquote>
<pre wrap=""><!---->contain real domain names.
</pre>
<blockquote type="cite">
<pre wrap="">So users from different Grids could roam freely between
</pre>
</blockquote>
<pre wrap=""><!---->"partnering" Grid
</pre>
<blockquote type="cite">
<pre wrap="">servers using realms.
</pre>
</blockquote>
<pre wrap=""><!---->
Proxy operations
When a RADIUS server receives
</pre>
<blockquote type="cite">
<pre wrap="">an AAA request for a user name
</pre>
</blockquote>
<pre wrap=""><!---->containing a realm, the server will reference
</pre>
<blockquote type="cite">
<pre wrap="">a table of configured
</pre>
</blockquote>
<pre wrap=""><!---->realms. If the realm is known, the server will then
</pre>
<blockquote type="cite">
<pre wrap="">proxy the request to
</pre>
</blockquote>
<pre wrap=""><!---->the configured home server for that domain. The
</pre>
<blockquote type="cite">
<pre wrap="">behaviour of the
</pre>
</blockquote>
<pre wrap=""><!---->proxying server regarding the removal of the realm from the
</pre>
<blockquote type="cite">
<pre wrap="">request
</pre>
</blockquote>
<pre wrap=""><!---->("stripping") is configuration-dependent on most servers. In
</pre>
<blockquote type="cite">
<pre wrap="">addition,
</pre>
</blockquote>
<pre wrap=""><!---->the proxying server can be configured to add, remove or rewrite
</pre>
<blockquote type="cite">
<pre wrap="">AAA
</pre>
</blockquote>
<pre wrap=""><!---->requests when they are proxied.
I believe the first step would be to
</pre>
<blockquote type="cite">
<pre wrap="">get a RADIUS server
</pre>
</blockquote>
<pre wrap=""><!---->setup and working, and then work on setting up two grids
</pre>
<blockquote type="cite">
<pre wrap="">together (using
</pre>
</blockquote>
<pre wrap=""><!---->REALM between the two RADIUS servers) and then once this
</pre>
<blockquote type="cite">
<pre wrap="">could be done,
</pre>
</blockquote>
<pre wrap=""><!---->then later additional grids could be "trusted" and allowed
</pre>
<blockquote type="cite">
<pre wrap="">onto the
</pre>
</blockquote>
<pre wrap=""><!---->network. So users could roam freely between the "trusted grids".
</pre>
<blockquote type="cite">
<pre wrap="">If a user was reported to the Grid Owner (as being an
</pre>
</blockquote>
<pre wrap=""><!---->"abusive user") then
</pre>
<blockquote type="cite">
<pre wrap="">the Grid owner would suspend that user's account,
</pre>
</blockquote>
<pre wrap=""><!---->and send an "abuse
</pre>
<blockquote type="cite">
<pre wrap="">notification" to the Grid Owner (that the user has
</pre>
</blockquote>
<pre wrap=""><!---->violated the Terms of
</pre>
<blockquote type="cite">
<pre wrap="">Service for the Grid). Basically just "pull the
</pre>
</blockquote>
<pre wrap=""><!---->plug" on that user's
</pre>
<blockquote type="cite">
<pre wrap="">account, and kick them off the grid, and ban their
</pre>
</blockquote>
<pre wrap=""><!---->computer & IP address.
</pre>
<blockquote type="cite">
<pre wrap="">It would make it extremely easy for "policing" the Grid, and
</pre>
</blockquote>
<pre wrap=""><!---->any users that
</pre>
<blockquote type="cite">
<pre wrap="">want "Secure Inter-Grid" handshakes would just join the
</pre>
</blockquote>
<pre wrap=""><!---->REALM network.
</pre>
<blockquote type="cite">
<pre wrap="">Mark
</pre>
</blockquote>
<pre wrap=""><!---->
P.S. If you need some help with this, I'm sure we can sit
down and
</pre>
<blockquote type="cite">
<pre wrap="">discuss it a bit, and set something up as a "demo" grid as to
</pre>
</blockquote>
<pre wrap=""><!---->how this could
</pre>
<blockquote type="cite">
<pre wrap="">be done. Then later other Grids (like OS Grid, and
</pre>
</blockquote>
<pre wrap=""><!---->various others) could
</pre>
<blockquote type="cite">
<pre wrap="">join the REALM grid network.
</pre>
</blockquote>
<pre wrap=""><!---->
On Mon, Feb 23, 2009 at 2:19 PM, Toni
</pre>
<blockquote type="cite">
<pre wrap="">Alatalo
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-rfc2396E" href="mailto:antont@kyperjokki.fi"><antont@kyperjokki.fi></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
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
</pre>
</blockquote>
<pre wrap=""><!----> --~--~---------~--~----~------------~-------~--~----~
</pre>
<blockquote type="cite">
<pre wrap=""> this list: <a class="moz-txt-link-freetext" href="http://groups.google.com/group/realxtend">http://groups.google.com/group/realxtend</a>
realXtend home page: <a class="moz-txt-link-freetext" href="http://www.realxtend.org/">http://www.realxtend.org/</a>
-~----------~----~----~----~------~----~------~--~---
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
</pre>
</blockquote>
<pre wrap=""><!---->
I'm about to start tightening the ropes for the
Hypergrid in order to
</pre>
<blockquote type="cite">
<pre wrap="">make it safer, and also make safer some loose ends of
</pre>
</blockquote>
<pre wrap=""><!---->OpenSim without
HG,
</pre>
<blockquote type="cite">
<pre wrap="">and I would appreciate feedback on this.
</pre>
</blockquote>
<pre wrap=""><!---->
The first issue that needs to be
</pre>
<blockquote type="cite">
<pre wrap="">addressed is the
</pre>
</blockquote>
<pre wrap=""><!---->issue of user
authentication. The regions need to be able
</pre>
<blockquote type="cite">
<pre wrap="">to verify
</pre>
</blockquote>
<pre wrap=""><!---->that the agent
that claims to be
</pre>
<blockquote type="cite">
<pre wrap="">representing
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-abbreviated" href="mailto:Charles.Krinke@osgrid.org">Charles.Krinke@osgrid.org</a> is, indeed,
</pre>
<blockquote type="cite">
<pre wrap=""> representing <a class="moz-txt-link-abbreviated" href="mailto:Charles.Krinke@osgrid.org">Charles.Krinke@osgrid.org</a>. (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 <a class="moz-txt-link-rfc2396E" href="http://osgrid.org/"><http://osgrid.org/></a> has a
user named "Charles Krinke", and we
</pre>
</blockquote>
<pre wrap=""><!----> certainly don't want Charles to be constantly typing
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!----> (all the current
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap=""><!----> {
</pre>
<blockquote type="cite">
<pre wrap=""> 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
</pre>
</blockquote>
<pre wrap=""><!----> of
</pre>
<blockquote type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
<blockquote type="cite">
<pre wrap="">_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
</pre>
</blockquote>
<pre wrap=""><!----><a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
<blockquote type="cite">
<pre wrap="">
_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
Opensim-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a>
<a class="moz-txt-link-freetext" href="https://lists.berlios.de/mailman/listinfo/opensim-dev">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>