<!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">
Rephrasing my question again: not "the" token but as the unforgeable
basis of "a" token. The token will have more information like the port
and user's identifiers that we are already using. But all those can be
stolen. The sender's IP address cannot be stolen, I've been told.<br>
<br>
OpenSim already gets the UDP EndPoint of the viewers; that's how it
sends packets back to the clients -- each individual client, even those
that are on the same network behind a NAT.<br>
<br>
I guess that if the man-in-the-middle sits behind that same NAT, the IP
address could be stolen too. But hey!<br>
<br>
Mark Malewski wrote:
<blockquote
cite="mid:f5f722b90902231504l3934995dm49ce8aae3dd15b3d@mail.gmail.com"
type="cite">
<div>Crista,</div>
<div> </div>
<div><strong><em>> The bottom line question in my email, phrased
in OpenID terminology, is whether we</em></strong></div>
<div><strong><em>> can use </em></strong><strong><em>the Viewer's
IP address as the token.<br>
</em></strong></div>
<div>My question is, would you really want to use the Viewer's IP
address as the token? What IP address would it specifically use?</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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?</div>
<div> </div>
<div>Keep in mind, that most users are using NAT behind their
firewall, so what IP address would you even use for the token?</div>
<div> </div>
<div>A better address would be the hostname address (<a
moz-do-not-send="true" 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:</div>
<div> </div>
<div><a moz-do-not-send="true"
href="mailto:hostname@be-70-ar01.area1.il.chicago.comcast.net">hostname@be-70-ar01.area1.il.chicago.comcast.net</a></div>
<div> </div>
<div>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?</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>We would probably need to create some type of "RADIUS" module
for OpenSim.</div>
<div> </div>
<div> Mark</div>
<div><br>
</div>
<div class="gmail_quote">On Mon, Feb 23, 2009 at 3:29 PM, Mark
Malewski <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mark.malewski@gmail.com">mark.malewski@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div>
<div class="Wj3C7c"><br>
<br>
<div class="gmail_quote">On Mon, Feb 23, 2009 at 3:28 PM, Mark
Malewski <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mark.malewski@gmail.com" target="_blank">mark.malewski@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div>Crista,</div>
<div> </div>
<div>Sounds like you are on the right track. Sounds like a very
"logical" process, but why not use something like 802.1x/EAP?<br>
</div>
<div><strong><em>> So, what can we do to detect the legitimacy
of agents?</em></strong></div>
<div> </div>
<div>Instead of a "Finnish Magic", why not use 802.1x and use a
RADIUS server for standard authentication? </div>
<div> </div>
<div>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).</div>
<div> </div>
<div>
<ol>
<li>The supplicant sends an "EAP-Response/Identity" packet to
the authenticator, which is then passed on to the authentication
(RADIUS) server.<br>
</li>
<li>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. <br>
</li>
<li>The supplicant responds to the challenge via the
authenticator and passes the response onto the authentication server. <br>
</li>
<li>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. </li>
</ol>
</div>
<div>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.</div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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. </div>
<div> </div>
<div>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]</div>
<div> </div>
<div>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).</div>
<div><br>
<a moz-do-not-send="true" href="http://freeradius.org/"
target="_blank">http://freeradius.org/</a></div>
<div> </div>
<div>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.</div>
<div> </div>
<div><a moz-do-not-send="true"
href="http://en.wikipedia.org/wiki/RADIUS" target="_blank">http://en.wikipedia.org/wiki/RADIUS</a></div>
<div> </div>
<div>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"). </div>
<div> </div>
<div>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.)</div>
<div> </div>
<div>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).</div>
<div> </div>
<div>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).</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.)</div>
<div> </div>
<div>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 <b>realms</b>, which identify where the RADIUS
server should forward the AAA requests for processing.</div>
<div> </div>
<div>
<p>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 <i>postfix</i> notation for the realm. Another common
usage is <i>prefix</i> 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.</p>
<p>Realms can also be compounded using both prefix and postfix
notation, to allow for complicated roaming scenarios; for example, <a
moz-do-not-send="true" href="http://somedomain.com/" target="_blank">somedomain.com</a>\<a
moz-do-not-send="true" href="mailto:username@anotherdomain.com"
target="_blank">username@anotherdomain.com</a> could be a valid
username with two realms.</p>
<p>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.</p>
<p>So users from different Grids could roam freely between
"partnering" Grid servers using realms.</p>
<p><a moz-do-not-send="true"
name="11fa50adabf65177_11fa50a37d93cf5f_Proxy_operations"></a></p>
<h3><span>Proxy operations</span></h3>
<p>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 <i>proxy</i> 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.</p>
</div>
<div>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".</div>
<div> </div>
<div>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.</div>
<div> </div>
<div>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.</div>
<div> </div>
<div> Mark</div>
<div> </div>
<div>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.</div>
<div> </div>
<div> </div>
<div> </div>
<div> </div>
<div class="gmail_quote">
<div>
<div>On Mon, Feb 23, 2009 at 2:19 PM, Toni Alatalo <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:antont@kyperjokki.fi" target="_blank">antont@kyperjokki.fi</a>></span>
wrote:<br>
</div>
</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<div>
<div>this kinda sounds like trying to achieve what rexauth
does, no?<br>
<br>
perhaps someone could write how it is w.r.t to that case? i might be<br>
able, but too tired now and probably busy tomorrow.<br>
<br>
also John Hurliman is planning new auth stuff with openid and some<br>
openid related token thing (i forgot the name) which is basically 'same<br>
as rexauth but standards instead of Finnish magic', like he said the<br>
other day :) .. so perhaps he replies his plan there, seems to be online<br>
at least.<br>
<br>
~Toni<br>
<br>
--~--~---------~--~----~------------~-------~--~----~<br>
this list: <a moz-do-not-send="true"
href="http://groups.google.com/group/realxtend" target="_blank">http://groups.google.com/group/realxtend</a><br>
realXtend home page: <a moz-do-not-send="true"
href="http://www.realxtend.org/" target="_blank">http://www.realxtend.org/</a><br>
-~----------~----~----~----~------~----~------~--~---<br>
<br>
<br>
</div>
</div>
Hi,<br>
<br>
I'm about to start tightening the ropes for the Hypergrid in order to<br>
make it safer, and also make safer some loose ends of OpenSim without<br>
HG, and I would appreciate feedback on this.<br>
<br>
The first issue that needs to be addressed is the issue of user<br>
authentication. The regions need to be able to verify that the agent<br>
that claims to be representing <a moz-do-not-send="true"
href="mailto:Charles.Krinke@osgrid.org" target="_blank">Charles.Krinke@osgrid.org</a>
is, indeed,<br>
representing <a moz-do-not-send="true"
href="mailto:Charles.Krinke@osgrid.org" target="_blank">Charles.Krinke@osgrid.org</a>.
(As you know, right now this<br>
is... err... a bit overlooked... *coughs*... and not just in the HG...<br>
*more coughs*).<br>
<br>
Having looked at OpenID, I came to the conclusion that it's not enough<br>
to know that <a moz-do-not-send="true" href="http://osgrid.org/"
target="_blank">osgrid.org</a> has a user named "Charles Krinke", and
we<br>
certainly don't want Charles to be constantly typing his password<br>
everytime he moves; the region needs to know that this user is already<br>
logged in to the system AND the region also needs to know that the agent<br>
that is representing this user is a legitimate agent.<br>
<br>
OK, so the part about being logged in is easy; the user server already<br>
knows that, to some approximation.<br>
<br>
However, the part about the agent being legitimate is a bit more tricky.<br>
Here's the bad thing that can happen: Charles logs in to OSgrid, and TPs<br>
to this intriguing region called "Sports Illuminated Swimming Suite<br>
Edition". That region happens to be up to no good. It grabs Charles<br>
current notion of identity (all the current identifiers we use), it<br>
crashes Charles' viewer so that the user server never knows about it,<br>
and proceeds to impersonate Charles using all those stolen identifiers;<br>
for example, it can go back to Charles's regions and erase them<br>
completely pretending to be Charles.<br>
<br>
So, what can we do to detect the legitimacy of agents?<br>
<br>
Having scratched my head over this, I came to the conclusion that the<br>
most promising element that can be used to identify agents is the<br>
Viewer's EndPoint. This is what happens down in the LLUDPServer (I'm<br>
sure something similar happens in other viewers' packet handlers):<br>
<br>
if (packet != null)<br>
{<br>
if (packet.Type == PacketType.UseCircuitCode)<br>
AddNewClient((UseCircuitCodePacket)packet, epSender,<br>
epProxy);<br>
else<br>
ProcessInPacket(packet, epSender);<br>
}<br>
<br>
The EndPoint epSender comes directly from the socket and I'm assuming it<br>
can't be faked, at least the IP part. Is this correct? This is a<br>
critical assumption.<br>
<br>
So, back to the "Sports Illuminated" scenario: that sim would then try<br>
to launch an agent at Charles' region. It can fake everything except<br>
being Charles' viewer machine. When Charles' region does that code<br>
above, it asks the User server for authentication of an agent with all<br>
those identifiers and the given EndPoint, and the User server tells back<br>
that Charles wasn't using that EndPoint to start with, so the<br>
authentication fails, and an alarm is rang.<br>
<br>
Thoughts?<br>
<br>
Crista<br>
<br>
Disclaimer: I'm not an expert in security, I'm just using my brain in<br>
context.<br>
<br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a moz-do-not-send="true"
href="https://lists.berlios.de/mailman/listinfo/opensim-dev"
target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br>
</blockquote>
</div>
<br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
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>