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 (hostn...@domain.com
<mailto:hostn...@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:
hostn...@be-70-ar01.area1.il.chicago.comcast.net
<mailto:hostn...@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.malew...@gmail.com <mailto:mark.malew...@gmail.com>> wrote:
On Mon, Feb 23, 2009 at 3:28 PM, Mark Malewski
<mark.malew...@gmail.com <mailto:mark.malew...@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/>\usern...@anotherdomain.com
<mailto:usern...@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
<ant...@kyperjokki.fi <mailto:ant...@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.kri...@osgrid.org
<mailto:charles.kri...@osgrid.org> is, indeed,
representing charles.kri...@osgrid.org
<mailto:charles.kri...@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@lists.berlios.de
<mailto:Opensim-dev@lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
------------------------------------------------------------------------
_______________________________________________
Opensim-dev mailing list
Opensim-dev@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/opensim-dev
