Location Independent Naming

Currently, most users think of computers as associated with their desktop appliances or with a server located in a dungeon in some mysterious basement. However, many of those same users may be considered to be nomads, in that they own computers and communication devices that they carry about with them in their travels as they move between office, home, airplane, hotel, automobile, branch office, and so on. Moreover, even without portable computers or communications, there are many who travel to numerous locations in their business and personal lives and who require access to computers and communications when they arrive at their destinations.

Indeed, even a move from a desk to a conference table in the same office constitutes a nomadic move since the computing platforms and communications capability may be considerably different at the two locations. The variety of portable computers is impressive, ranging from laptop computers, notebook computers, and personal digital assistants (or personal information managers) to "smart" credit card devices and wristwatch computers. In addition, the communication capability of these portable computers is advancing at a dramatic pace from high-speed modems to PCMCIA modems, e-mail receivers on a card, spread-spectrum hand-held radios, CDPD transceivers, portable GPS receivers, and gigabit satellite access, and so on.

The combination of portable computing with portable communications is changing the way we think about information processing. We now recognize that access to computing and communications is necessary not only from "home base" but also while in transit and after reaching a destination.

These ideas form the essence of a major shift to nomadicity (nomadic computing and communications), which we address in this paper. The focus is on the system support needed to provide a rich set of capabilities and services, in a transparent and convenient form, to the nomad moving from place to place.

In this paper we propose location independent naming as a mechanism to support nomadic computing on the Internet. Nomadic computing is a limited, but common form of mobile computing.Nomadic users compute from different locations, but do not require network connectivity while they are moving. For example, a salesman will travel from customer to customer, using his laptop at each location but storing it while driving to the next location.

While Mobile IP was designed for continuously moving computers, it can also support nomadic users. Mobile IP allows users to maintain existing connections while traveling between networks by allowing machines to carry their IP address with them when they move to a new network. Unfortunately, preserving IP addresses across networks introduces several drawbacks, including the performance penalties of triangle routing; the security problems of IP tunneling through fire-walls, and the loss of connectivity due to packet loss from source address filters. The drawbacks are inherent to Mobile IP since it breaks the one-to-one mapping between IP address and network location that is used by the Internet to route packets to the correct destination.

Our approach, Location Independent Naming (LIN), allows a machine to keep the same name as it moves around the Internet by rebinding its name to its local address when it moves. Once this binding has been made, the machine can communicate with any other host on the Internet using standard IP routing, since the source address on its packets identifies the machine's actual location. Further, other machines on the Internet can communicate with this machine, since its host-name maps to its current address. While this machine remains at its current location, it behaves just like any other machine at that location - no special support is needed except to setup and teardown the name-to-address binding. Because LIN preserves the association between IP address and location, it avoids the performance and security drawbacks of Mobile IP for nomadic computers, as well as the complexities of optimizing Mobile IP.

LIN represents an advance of the state of the art as it allows correspondent hosts to communicate with a nomadic host using its well-known name without the performance penalties, security issues, or need for infrastructure support of Mobile IP. It leverages and extends existing and pro-posed functionality of DNS (Domain Name System) and DHCP (Dynamic Host Configuration Protocol) to allow a mobile host to keep its name while moving across security domains using existing trust relationships.

Authentication in ASP.NET

There are two closely interlinked concepts at the heart of security for distributed applications - authentication and authorization. Authentication is the process of obtaining some sort of credentials from the users and using those credentials to verify the user's identity. Authorization is the process of allowing an authenticated user access to resources. Authentication is always precedes to Authorization; even if your application lets anonymous users connect and use the application, it still authenticates them as being anonymous.
ASP.net provides flexible set of alternatives for authentication. You can perform authentication yourself in code or delegate authentication to other authorities (such as Microsoft Passport). In fact sometimes it seems ASP.net authentication is a bit too flexible; it can be difficult for a new developer to know just where to start. In this article, we review the settings in ASP.net and Internet Information Services (IIS) that control authentication and authorization in ASP.net applications.

An ASP.net application has two separate authentication layers. That is because ASP.net is not a standalone product. Rather it is a layer on top of IIS. All requests flow through IIS before they are handed to ASP.net. As a result, IIS can decide to deny access without the ASP.net process even knowing that someone requested a particular page. Here is an overview of the steps in the joint IIS and ASP.net authentication process.

1. IIS first checks to make sure the incoming request comes from an IP address that is allowed access to the domain. If not it denies the request.
2. Next IIS performs its own user authentication if it configured to do so. By default IIS allows anonymous access, so requests are automatically authenticated, but you can change this default on a per - application basis with in IIS.
3. If the request is passed to ASP.net with an authenticated user, ASP.net checks to see whether impersonation is enabled. If impersonation is enabled, ASP.net acts as though it were the authenticated user. If not ASP.net acts with its own configured account.
4. Finally the identity from step 3 is used to request resources from the operating system. If ASP.net authentication can obtain all the necessary resources it grants the users request otherwise it is denied. Resources can include much more than just the ASP.net page itself you can also use .Net's code access security features to extend this authorization step to disk files, Registry keys and other resources.

As you can see several security authorities interact when the user requests and ASP.net page. If things are not behaving the way you think they should, it can be helpful to review this list and make sure you have considered all the factors involved

Authentication providers

Assuming IIS passes a request to ASP.net, what happens next? The answer depends on the configuration of ASP.net itself. The ASP.net architecture includes the concept of and authentication provider a piece of code whose job is to verify credentials and decide whether a particular request should be considered authenticated. Out of the box ASP.net gives you a choice of three different authentication providers.

• The windows Authentication provider lets you authenticates users based on their windows accounts. This provider uses IIS to perform the authentication and then passes the authenticated identity to your code. This is the default provided for ASP.net.
• The passport authentication provider uses Microsoft's passport service to authenticate users.
• The forms authentication provider uses custom HTML forms to collect authentication information and lets you use your own logic to authenticate users. The user's credentials are stored in a cookie for use during the session.

Selecting an authentication provider is as simple as making an entry in the web.config file for the application. You can use one of these entries to select the corresponding built in authentication provider:

<authentication mode="windows">
authentication mode="passport">
<authentication mode="forms">

ASP.net also supports custom authentication providers. This simply means that you set the authentication mode for the application to none, then write your own custom code to perform authentication. For example, you might install an ISAPI filter in IIS that compares incoming requests to list of source IP addresses, and considers requests to be authenticated if they come from an acceptable address. In that case, you would set the authentication mode to none to prevent any of the .net authentication providers from being triggered.

Windows authentication and IIS

If you select windows authentication for your ASP.NET application, you also have to configure authentication within IIS. This is because IIS provides Windows authentication. IIS gives you a choice for four different authentication methods:

Anonymous, basic digest, and windows integrated

If you select anonymous authentication, IIS doesn't perform any authentication, Any one is allowed to access the ASP.NET application.

If you select basic authentication, users must provide a windows username and password to connect. How ever this information is sent over the network in clear text, which makes basic authentication very much insecure over the internet.

If you select digest authentication, users must still provide a windows user name and password to connect. However the password is hashed before it is sent across the network. Digest authentication requires that all users be running Internet Explorer 5 or later and that windows accounts to stored in active directory.

If you select windows integrated authentication, passwords never cross the network. Users must still have a username and password, but the application uses either the Kerberos or challenge/response protocols authenticate the user. Windows-integrated authentication requires that all users be running internet explorer 3.01 or later Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. Kerberos is a solution to network security problems. It provides the tools of authentication and strong cryptography over the network to help to secure information in systems across entire enterprise

Passport authentication

Passport authentication lets you to use Microsoft's passport service to authenticate users of your application. If your users have signed up with passport, and you configure the authentication mode of the application to the passport authentication, all authentication duties are offloaded to the passport servers.

Passport uses an encrypted cookie mechanism to indicate authenticated users. If users have already signed into passport when they visit your site, they'll be considered authenticated by ASP.NET. Otherwise they'll be redirected to the passport servers to log in. When they are successfully log in, they'll be redirected back to your site

To use passport authentication you have to download the Passport Software Development Kit (SDK) and install it on your server. The SDK can be found at http://msdn.microdoft.com/library/default.asp?url=/downloads/list/websrvpass.aps. It includes full details of implementing passport authentication in your own applications.

Forms authentication

Forms authentication provides you with a way to handle authentication using your own custom logic with in an ASP.NET application. The following applies if you choose forms authentication.

1. When a user requests a page for the application, ASP.NET checks for the presence of a special session cookie. If the cookie is present, ASP.NET assumes the user is authenticated and processes the request.
2. If the cookie isn't present, ASP.NET redirects the user to a web form you provide
3. You can carry out whatever authentication, checks you like in your form. When the user is authenticated, you indicate this to ASP.NET by setting a property, which creates the special cookie to handle subsequent requests.

Configuring Authorization

After your application has authenticated users, you can proceed to authorize their access to resources. But there is a question to answer first: Just who is the user to whom your are grating access? It turns out that there are different answers to that question, depending on whether you implement impersonation. Impersonation is a technique that allows the ASP.NET process to act as the authenticated user, or as an arbitrary specified user

ASP.NET impersonation is controlled by entries in the applications web.config file. The default setting is "no impersonation". You can explicitly specify that ASP.NET shouldn't use impersonation by including the following code in the file

<identity impersonate="false"/>

With this setting ASP.NET does not perform impersonation. It means that ASP.NET will runs with its own privileges. By default ASP.NET runs as an unprivileged account named ASPNET. You can change this by making a setting in the processModel section of the machine.config file. When you make this setting, it automatically applies to every site on the server. To user a high-privileged system account instead of a low-privileged, set the userName attribute of the processModel element to SYSTEM. Using this setting is a definite security risk, as it elevates the privileges of the ASP.NET process to a point where it can do bad things to the operating system.

When you disable impersonation, all the request will run in the context of the account running ASP.NET: either the ASPNET account or the system account. This is true when you are using anonymous access or authenticating users in some fashion. After the user has been authenticated, ASP.NET uses it own identity to request access to resources.

The second possible setting is to turn on impersonation.

<identity impersonate="true"/>

In this case, ASP.NET takes on the identity IIS passes to it. If you are allowing anonymous access in IIS, this means ASP.NET will impersonate the IUSR_ComputerName account that IIS itself uses. If you aren't allowing anonymous access,ASP.NET will take on the credentials of the authenticated user and make requests for resources as if it were that user. Thus by turning impersonation on and using a non-anonymous method of authentication in IIS, you can let users log on and use their identities within your ASP.NET application.

Finally, you can specify a particular identity to use for all authenticated requests

<identity impersonate="true" username="DOMAIN\username" password="password"/>

Self Defending Networks

The Next Generation of Network Security helps networking professionals understand how to deploy an end-to-end, integrated network security solution. It presents a clear view of the various components that can be used throughout the network to not only monitor traffic but to allow the network itself to become more proactive in preventing and mitigating network attacks. This security primer provides unique insight into the entire range of Cisco security solutions, showing what each element is capable of doing and how all of the pieces work together to form an end-to-end Self-Defending Network. While other books tend to focus on individual security components, providing in-depth configuration guidelines for various devices and technologies, Self-Defending Networks instead presents a high-level overview of the entire range of technologies and techniques that comprise the latest thinking in proactive network security defenses. This book arms network security professionals with the latest information on the comprehensive suite of Cisco security tools and techniques. Network Admission Control, Network Infection Containment, Dynamic Attack Mitigation, DDoS Mitigation, Host Intrusion Prevention, and Integrated Security Management are all covered, providing the most complete overview of various security systems. It focuses on leveraging integrated management, rather than including a device-by-device manual to implement self-defending networks.

Browser Capabilities - Using the Browser Object in C#

This tutorial will show how to reference the Browser object to retrieve information about what your client can display. C# version.
The text attribute of each label in the ASPX page will be dynamically changed upon runtime, depending upon the user configuration / browser.
First, let's create a layout to display the information:

Browser Capabilities:

ActiveX Controls:
AOL:
Background Sounds:
CDF:
.NET Framework:
Cookies:
ECMA:
HTML Frames:
Java Applets:
Browser Version:
Broswer Platform:

The following code checks for values for specific properties of the Browser Object.
We are able to output these values to the user to notify them, but we are also able to use these values in the code to display our page differently to different users. For example, not using ActiveX Controls if the user's browser does not support ActiveX.

using System;
using System.Data;
using System.Configuration;
using System.Web;
using System.Web.Security;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using System.Web.UI.HtmlControls;

public partial class _Default : System.Web.UI.Page
{

protected void Page_Load(object sender, EventArgs e)
{

if (Request.Browser.ActiveXControls == true)
{

Label1.Text = "This browser supports ActiveX Controls.";

}
else
{

Label1.Text = "This browser does not support ActiveX controls.";

}

if (Request.Browser.AOL == true)
{

Label2.Text = "This browser is AOL.";

}
else
{

Label2.Text = "This browser is not AOL.";

}

if (Request.Browser.BackgroundSounds == true)
{

Label3.Text = "This browser supports Background Sounds.";

}
else
{

Label3.Text = "This browser does not support Background Sounds.";

}

if (Request.Browser.CDF == true)
{

Label4.Text = "This browser supports Channel Definition Format.";

}
else
{

Label4.Text = "This browser does not support Channel Definition Format.";

}

if (Request.Browser.ClrVersion.ToString() != "0.0")
{

Label5.Text = "This client supports the .NET Framework! You are running version " + Request.Browser.ClrVersion.ToString();

}
else
{

Label5.Text = "You do not have the .NET Framework installed on your machine.";

}

if (Request.Browser.Cookies == true)
{

Label6.Text = "This browser supports Cookies.";

}
else
{

Label6.Text = "This browser does not currently support Cookies.";

}

Label7.Text = "You are running version " + Request.Browser.EcmaScriptVersion.ToString() + " of ECMA Script.";

if (Request.Browser.Frames == true)
{

Label8.Text = "This browser supports HTML Frames.";

}
else
{

Label8.Text = "This browser does not support HTML Frames.";

}

if (Request.Browser.JavaApplets == true)
{

Label9.Text = "This browser supports Java Applets.";

}
else
{

Label9.Text = "This browser does not support Java Applets.";

}

Label10.Text = Request.Browser.Type.ToString() + "." + Request.Browser.MinorVersion.ToString();

Label11.Text = Request.Browser.Platform;

}

}

Firefox 4 beta 5 beefs up video, audio, security features

Tuesday evening, Mozilla pushed out the fifth beta of its Firefox 4 Web browser. With this update, improvements to the browser's audio, video, and security have been added.
Two weeks ago, the Beta 4 release of Firefox 4 included new features to help users get organized, Firefox ,Sync and Panorama. This release focuses less on giving users new features, and more on providing the tools for a better experience down the road.

First, Firefox 4 now features hardware acceleration in Windows Vista and Windows 7 machines with DirectX10-compatible hardware. This feature has existed since the very early builds of FF4, but only now is it included by default. What it does is Utilize the Direct2D Rendering System so the graphics hardware can speed up rendering of page content, such as text and images. Eventually, this will also be able to speed up compositing as well, but that is not ready in Beta 5. Secondly, the new Audio API cuts open the HTML5 audio and video elements, so the raw audio data can be viewed and accessed. Developers will be able to use this data to create new in-browser audio experiences, some of which Mozilla showed off in an impressive demonstration today.

Finally, Firefox 4 Beta 5 now supports HSTS, or HTTP Strict Transport Security. This feature makes FF4 remember which sites utilize SSL, to prevent the vulnerability that occurs when users access an encrypted site through a non-encrypted version.

"If a web page provide has an https version but you access it through http, what happens? The http version of the Website re-direct you to the https, but you firsttalked to the non-encrypted version of the website. These behaviors can be exploited to run a man-in-the-middle attack."
So now, sites that support HSTS can automatically redirect any request to their secure site.

Wireless LAN Security

Wireless LAN Security

One issue with corporate Wireless networks in general, and WLANs in particular, involves the need for security. Many early access points could not discern whether or not a particular user had authorization to access the network. Although this problem reflects issues that have long troubled many types of wired networks (it has been possible in the past for individuals to plug computers into randomly available Ethernet Jacks and get access to a local network), this did not usually pose a significant problem, since many organizations had reasonably good physical security. However, the fact that radio signals bleed outside of buildings and across property lines makes physical security largely irrelevant Piggybackers. Such corporate issues are covered in Wireless security

The approval of the IEEE 802.11 standard for wireless local area networks
(WLANs) and the subsequent fall in prices for wireless network interface cards
(NICs) and wireless access points (APs) has caused an explosion in demand for
wireless LAN capability. Because of this demand, network administrators have had
to deal with two conflicting issues. Network administrators want to provide users
with the flexibility and convenience that wireless network access offers while
maintaining network security and integrity.

Benefits of Wireless LANs

A traditionally wired 10/100 BaseT Ethernet LAN infrastructure for 100 people costs about US$15,000 and requires several days to install (see Figure 1). Enterprises that use such an arrangement also incur additional costs and disruptions with every change to the physical office. (Expenses vary according to the physical layout and the quality of the equipment used.) Conversely, wireless LANs are less expensive and less intrusive to implement and maintain, as user needs change.

SIMPLIFIED IMPLEMENTATION AND MAINTENANCE

Wireless APs can be placed in the ceiling, where they can accommodate a virtually endless

variety of office configurations (see Figure 2). Wired LANs, in contrast, consume time and

resources to run cables from a network closet to user’s desktops and to difficult-to-service areas

such as conference room tables and common areas. With a wired LAN, each additional user or

modification to the floor plan necessitates adjustments to the cabling system.

SECURITY FEATURES

The 802.11 standard provides for two primary security features that, unfortunately,
fall short of a truly secure solution. Both of the solutions operate on the data link
layer of the network.

The DataView and DataViewManager

Data binding depends on two classes in the System.Data namespace: DataView and DataViewManager. These classes provide an important layer of indirection between your data and its display format, allowing you to apply sorts and filter rows without modifying the underlying information—that is, to have different views on the same data. ADO.NET binding is always provided through one of these objects.
Both ASP.NET and Windows Forms allow you to bind other types of objects to controls, including custom classes, arrays, and some collection types. However, ADO.NET binding always uses DataView and DataViewManager, so this chapter focuses on these two classes.
The DataView class acts as a view onto a single DataTable. When creating a DataView object, you specify the underlying DataTable in the constructor:

DataView view = new DataView(ds.Tables["Customers"]);

Every DataTable also provides a default DataView through the DataTable. DefaultView property:

DataView view = ds.Tables["Customers"].DefaultView;

The DataViewManager represents a view of an entire DataSet. As with the DataView, you can create a DataViewManager manually, passing in a reference to a DataSet as a constructor argument, or you can use the default DataViewManager provided through the DataSet.DefaultViewManager property.

The DataView and DataViewManager provide three key features:

• Sorting based on any column criteria

• Filtering based on any combination of column values

• Filtering based on the row state (such as deleted, inserted, and unchanged)