If you have no clue what 802.1X is, read my recent technology primer first. If you’re already familiar with 1X, you’ve probably heard about some of the 802.1X additions- the 802.1AE (MACSec) and possibly 802.1af (the key agreement for MACSec)… but that’s just the tip of the iceberg, and what’s hiding underneath will knock your socks off!

We’re currently at the 802.1X-2004 edition, with the group working on the REV and hoping for an early-2009 release. When IEEE makes additions (such as AE and af) they’re just afterthoughts and changes tacked on to the end of the standard. But when they do a revision , as they are now, they’re opening up the whole can of worms and all parts of the standard are opened for evaluation and modification. Yee-haw!

So, what’s in this new revision and what can we expect from 802.1X-REV? That’s what I wanted to know, and I’m sure you’re curious too. I was lucky enough to catch a quick call with Paul Condon earlier this week and get some of the inside scoop. Paul is ProCurve Networking’s CTO, but more importantly for our purposes today, he’s the Vice -Chair of the IEEE 802.1 working group and is intimately involved in 1X and a variety of other networking, security and authentication standards.

1) Encryption & Key Exchange : The first goal in updating 802.1X was to add security with encryption, specifically on switch-to-switch links. Of course, with encryption comes the need for fast, secure key exchange, so we ended up with 802.1AE and 802.1af as answers to the first set of goals. The encryption will require hardware refreshes, and vendors are already gearing up for that. The benefits of encryption are pretty obvious, so I won’t bore you with that. There are some fun little gems hidden in the AE/af set though. Even without using the encryption piece, we’ll be able to use the key exchange as a means of quickly (in ~4-5 packets) authenticating (or re-authenticating) switches to one another after a reboot. It will be a critical piece for maintaining availability and integrity in the network. And w e can do this piece without a hardware upgrade, which is pretty nifty.

2) Same-Port Multiuser Support: Here’s where the 1X-REV sauce starts tasting really good. The new revision is leveraging some of its security updates to support multi-user modes on a single port. And no, not by using multi-tagged VLANs, this is way cooler than that. In theory, multiple PCs, phones or other connected devices can connect through a single port, which would essentially be running multiple instances of 802.1X, letting each communicate securely. It’ll be similar in practice to how wireless APs segregate and encrypt traffic between the AP and the endpoint. I’m sure at first we’ll see software-based endpoint encryption support and of course, move towards hardware encryption and see NICs with the capability baked in. That’s still down the road, but the road is getting shorter.

3) Network Advertisement/Selection : Now the 1X-REV sauce is the best you’ve ever had- you’re gonna want to put this stuff on everything ! :) The 3rd goal of the revision is to add support for network advertisements on the wired side- which would be a similar experience to selecting the wireless SSID from a list of ones available on your laptop. But, it’s happening on your wired switch. Wild, right? They’re going to leverage the EAPOL types here to communicate from client to network. Imagine the possibilities…

All these new functions and features give 802.1X numerous new use cases. I think you’ll see parts of these technologies leveraged in various parts of critical networks everywhere. Sponsor ballots come at the end of the year, and they’re hoping to see something solid and released in early 2009.

You can see why I’m excited. The 802.1X-REV may be the evil stepchild for a while, but it’s coming. When it does, it’s going to rock our little network worlds and flip our thinking about wired security and network segregation upside down.

Of course, you’ll be seeing more on this from me, so hang in there!

# # #

Summary, Conclusions, and Future Work

This report has provided the motivation, philosophy, formalisms, representational requirements, architectural design criteria, recommendations, and test scenarios to design and construct an autonomous robotic system architecture capable of the ethical use of lethal force. These first steps toward that goal are very preliminary and subject to major revision, but at the very least they can be viewed as the beginnings of an ethical robotic warfighter. The primary goal remains to enforce the International Laws of War in the battlefield in a manner that is believed achievable, by creating a class of robots that not only conform to International Law but outperform human soldiers in their ethical capacity.

It is too early to tell whether this venture will be successful. There are daunting problems
remaining:

• The transformation of International Protocols and battlefield ethics into machine usable representations and real-time reasoning capabilities for bounded morality using modal logics.

• Mechanisms to ensure that the design of intelligent behaviors only provide responses within rigorously defined ethical boundaries.

• The creation of techniques to permit the adaptation of an ethical constraint set and underlying behavioral control parameters that will ensure moral performance, should those norms be violated in any way, involving reflective and affective processing.

• A means to make responsibility assignment clear and explicit for all concerned parties regarding the deployment of a machine with a lethal potential on its mission.

Over the next two years, this architecture will be slowly fleshed out in the context of the specific test scenarios outlined in this article. Hopefully the goals of this effort, will fuel other scientists’ interest to assist in ensuring that the machines that we as roboticists create fit within international and societal expectations and requirements.

My personal hope would be that they will never be needed in the present or the future. But mankind’s tendency toward war seems overwhelming and inevitable. At the very least, if we can reduce civilian casualties according to what the Geneva Conventions have promoted and the Just War tradition subscribes to, the result will have been a humanitarian effort, even while staring directly at the face of war.

So then I start messing around with it, and I narrow it down to one of the things that’s more legacy than anything, the now fixed, MS mhtml bug. Uh oh. Yup, the mhtml bug appears to crash mobile Opera instantly. So back to keeping JS turned off, I guess (I haven’t tested if there is another way to cause the crash using a redirection or an iframe, but it takes a long time to test, so I’ll leave that to another day).

Then I start messing with the other options, like the “Identify as” function. With it turned to “handheld device” the user agent reads, “MOT-Q9/01.04.35R Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; Smartphone; 320×240) Opera 8.65 UP.Link/6.3.1.17.0″. Eesh! It gives my actual device type! So then I turn the setting to “desktop computer” it turns to “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Opera 8.65 [en] UP.Link/6.3.1.17.0″. Okay, fair enough, that appears to be the more secure setting as at least it doesn’t say the revision and model number of the phone.

That is, of course, until you look at the rest of the headers:

HTTP_ACCEPT = application/xhtml+xml, application/vnd.wap.xhtml+xml, text/html, text/vnd.wap.wml, application/vnd.wap.wmlc, */*,text/x-hdml,image/mng,image/x-mng,video/mng,video/x-mng,image/bmp,text/html
HTTP_ACCEPT_CHARSET = iso-8859-1, utf-8, utf-16, *;q=0.1,*
HTTP_ACCEPT_ENCODING = deflate, gzip
HTTP_ACCEPT_LANGUAGE = en
HTTP_CACHE_CONTROL = no-cache
HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Opera 8.65 [en] UP.Link/6.3.1.17.0
HTTP_VIA = 1.1 alnmagr1fe09WAP2-mbl
HTTP_X_UP_DEVCAP_ACCEPT_LANGUAGE = en
HTTP_X_UP_DEVCAP_CHARSET = utf-8,ISO-8859-1,US-ASCII,UTF-16,GB2312,BIG5
HTTP_X_UP_DEVCAP_ISCOLOR = 1
HTTP_X_UP_DEVCAP_NUMSOFTKEYS = 2
HTTP_X_UP_DEVCAP_SCREENDEPTH = 16
HTTP_X_UP_DEVCAP_SCREENPIXELS = 320,240
HTTP_X_UP_DEVCAP_SMARTDIALING = 1
HTTP_X_UP_SUBNO = ppu_105cb54061e_vmag.mycingular.net
HTTP_X_WAP_PROFILE = “http://uaprof.motorola.com/phoneconfig/q-umts/Profile/mot-q9.rdf

Okay, so now we know my provider how big my screen is, that it’s a mobile device of course (the reference to wap), but more importantly we get the actual profile of the phone in the RDF file with all the settings, so you know exactly what may or may not work against the phone! Geez! Talk about giving up too much info! I hardly consider myself a cell phone hacker (for that you’ll need to talk with the Flexillis guys) but in 5 minutes I found all that - that’s not a good start. Whelp, so much for surfing from my phone!

Some conference highlights follow…

Bruce Schneier Keynote

The second day of the conference opened with a Keynote from Bruce Schneier. If you ever have a chance to hear a presentation by Bruce - Do Not Pass It Up ! In addition to being a really good presenter, Bruce invests a lot of time into really thinking about and researching the mechanics of security. His keynote was entitled “Reconceptualizing Security”. I have four pages of notes from his presentation. Here are a few of the topics he touched on:

• Great discussion of “feelings” vs “reality” of security
• Examination of the language and cognitive challenges regarding risk
• Discussion and some revision of Bruce’s ideas regarding “Security Theater”
• Explanation of Lemon’s Markets
• Are many security products sold in a Lemon’s Market ?

DEF-105: 12 Common Java Security Traps

Brian Chess gave two presentations at the conference. Unfortunately, I was only able to attend one. This presentation focused on common, and significant, security problems that must be addressed during development.

Brian referenced two resources in his presentation, both of which I plan on researching:

Fortify Taxonomy: Software Security Errors

• This is an attempt to partition the entire space of software security flaws…

Open Source Software Vulnerability Project

• Application of the Vulnerability scanning tools developed by Brian’s company to Open Source projects to aid in the discovery and remedy of software security errors.

HT-108: Revenge of the Rodent: Did Your Mouse Turn Evil?

Ronald Heil’s presentation about malicious things that can be done with trusted devices, such as the mouse, was brilliant. Ronald reengineers a common computer mouse, using off-the-shelf components, and turns it into one that can be used to:

• Load malicious code onto a target computer
• Store data stolen from the user (for later retrieval)
• Provide attacker with remote control and data access (via Bluetooth)

DEV-109: Is Web 2.0 a Hackers Dream?

This was the third Caleb Sima presentation I have attended. Each one has been fantastic and better than the previous one.

This presentation focused on some of the application security pitfalls that Web 2.0 technologies, such as AJAX, are vulnerable to. Caleb’s presentations always mix static information with actual demonstrations of concepts. During this presentation he demonstrated a number of JavaScript application security faux pas.

A key thesis in the presentation was that Web 2.0 programing techniques, like AJAX, are dramatically increasing the attack surface of applications though movement of code to the client, were it can be easily examined and manipulated. Several examples of ‘bad logic’ or code to move to the client were given, and included:

• Security code (coupon code validation logic, admin status flagging, etc.)
• Input validation
• Range control and boundary checking logic

Summary

The above summaries are highlights. I attended all of the sessions on days two and three, and found them all to be very valuable and high quality. I was particularly impressed by the great English language skills of the presenters from non-English speaking countries. I do not know if I will have the opportunity to attend the European event in the future, but I would certainly recommend it.

Cheers,

Erik

Art of Information Security would love your feedback !

RSA Europe 2007 Trip Summary