But there's this lovely new segment of lightly licensed spectrum in the U.S., the 3.65 GHz band. It's a non-exclusive licensed band available only in parts of the country that don't have pre-existing ground-to-satellite or radar uses that overlap. This omits most of the eastern seaboard and most major cities; Seattle is one exception.

The licensing mechanism allows any number of operators to obtain inexpensive licenses, and register the base stations they use by location. If interference arises among base stations, operators are required to work out the problems themselves. I wrote extensively about this band and its rules on 9-May-2008 in profiling Azulstar, formerly a metro-scale Wi-Fi firm, but now a big proponent of WiMax in 3.65 GHz. I also went over the rules for the band on 11-June-2007 when the FCC announced the arrangement.

Several firms offer base station and customer premises equipment for this band now, so close to the 3.5 GHz band more commonly exclusively licensed in Europe and elsewhere. WiMax equipment is available because the 3.65 GHz band can be used with WiMax without any modifications to that protocol, although limited to just 25 MHz of the 50 MHz that the FCC set aside.

Equipment that conforms to a more stringent set of rules about contention and other factors can use the whole 50 MHz, and that's where 802.11y comes in. It's an extension of Wi-Fi to cope with the specific needs--and to open Wi-Fi technology up to 20 W EIRP, a vastly higher power output. This could allow connections over 5 km, the group says.

The Wikipedia entry on 802.11y, clearly written by someone involved with the specification, notes that three specific additions are needed: a tweak to support the way in which the FCC wants contention among competing devices to work; a method for an access point to tell a station (a connecting radio) that it's about to switch its channel or its channel's bandwidth, and the station should do likewise; and a mechanism to handle a base station allowing or revoking permission to use the spectrum without uniquely identifying the user's system or broadcasting its precise GPS-based location.

The standard is near completion and initial approval. I don't have any knowledge about whether any mainstream Wi-Fi equipment makers or metro-scale equipment makers are looking into building 802.11y into their gear.

The fact is that this could be a great technology for the mostly sub-metropolitan markets that 3.65 GHz is available in, although it has the same pain as WiMax: all new gear on the towers and all new adapters for customers.

On the 27th episode of The Silver Bullet Security Podcast, Gary interviews software security expert Gunnar Peterson, a Managing Principal at Arctec Group. Gary and Gunnar begin with the age-old question, “What is security?” They go on to discuss how Web 2.0 and SOA security is progressing, the big idea behind “federated identity,” whether all market verticals can follow the software security lead of the financial services industry, and the inherent badness of the color purple.

• Build Security In column from IEEE S&P
• Gunnar’s Blog
• informIT (Securing Web 3.0)
• Metricon 3.0
• Butler Lampson on Security
• Federated Identity
• Ping Identity
• Gerald Weinberg
• Verizon Business Security: Patching Conundrum

At each of these opportunities, I like to ask ‘Why are you considering NAC?”

Here’s my Top 5 of Why Customers Consider NAC (or think they want NAC). This is not based on any other organization’s research or polls, nor is it based on analyst analysis. It’s not based on forethought or musings of an ‘expert’. It’s just my personal experience from my daily interactions.

#1: Endpoint Compliance
I put this one first, because I think it’s the most-hyped and possibly least significant. I know, that’s harsh, especially when endpoint compliance seems to be the big bat NAC carries around. Truth be told, it’s more of an ‘icing on the cake’ for the people I talk to. Until the auto-remediation features are a little more mature, the idea of checking for much beyond presence of anti-virus and possibly patches is unattractive. Frankly, endpoint compliance for LAN-based devices can be a Charlie Foxtrot except under the most ideal circumstances. There are many large organizations and DoD groups that need endpoint compliance, and that’s a primary driver for them. For the rest, one of the other reasons below is a primary compelling feature and endpoint checking is just another knob they can play with.

The lack of fervent interest in endpoint checking is why I had to disagree so strongly with Stiennon’s when he advises in his NWW article “Don’t even bother investing in NAC”. The entire premise of his issues with NAC center around various endpoing checking. (You can check out Shimel’s response  too Stiennon’s blog here.)

#2: Guest Access
Believe it or not, the most frequent response I get for “why are you considering NAC” is “guest access”. Guest access seems to be a thorn in every organization’s side. It’s a simple problem with impossibly complex solutions… or so they think. For years, we’ve been provisioning safe and secure guest access for customers with the use of clean and simple protocol-less VLANs and so, I know that about 82% of the time, there are much simpler ways to offer guest access than by rolling out a full NAC implementation. If guest access is your primary and only goal with a NAC solution, there’s probably a better, faster and less expensive solution. If money and time are no object, then NAC can be a good way to get from point A to B and give you a few fun technical trinkets to play with.

#3: Edge Port Security
After guest access, the next thing I hear most is interest in adding edge port security with a 802.1X NAC solution. (We call this Layer 2 NAC.) I tend to think for the time being, this is NAC’s sweet spot. Note I said ‘for the time being’, I think this may change in the next 18-24 months. But for now, the ability to lock down edge ports and secure switch-to-switch links is an extremely attractive feature. Outside of the 802.1X protocol, there aren’t really any other ways to skin this cat. I know what you’re thinking… you don’t have to do NAC to use 802.1X… and that’s certainly true, but for a network of any size, NAC makes an 802.1X implementation easier to manage and monitor centrally and gives you more of that NAC icing we all love.

When the 802.1X-REV comes out (probably early 2009) I think you’ll see organizations that have previously blown off 1X seriously considering it for all the added security and multi-user support it will bring to the table.

#4: User & Resource Accounting
Unless you have a 3rd party solution or want to dig through mounds of RADIUS syslogs, you probably don’t have a good way to account for user authentication and accountability of resource access throughout the network. Most vendors’ NAC solutions already have pretty good logging and reporting features built in today. Depending on the solution and integration of other devices, you may even get detailed accounts of which user viewed exactly what, when and from where. This is a great selling point to organizations that are trying to follow strict regulations for accountability of financial or extremely sensitive resources. The standards bodies (IEEE, TNC framework and IETF) are coming out with more and more ways to leverage 3rd party security devices within NAC. The IF-MAP is a great example and we’ll be seeing more I’m sure.

#5: Dynamic VLAN Assignment
Lastly, but not least, I hear a lot of customers that are looking for a good way to dynamically provision attributes, such as VLAN assignment and QoS to users or devices. It makes switch configuration and management much simpler, and eliminates the need to assign port-based VLANs. The ability to leverage your existing user directory and define both broad and very granular attributes is certainly a draw, and NAC is a great way to offer that.

That wraps up my Top 5. Of course, there are plenty more drivers, both business-based or technology-based, but these are the 5 I hear most.

# # #

The solution to the above problem is very useful in practice — in fact, so useful that it spawns a lot “fights” over patents. Many techniques were patented, including the well-known Encrypted Key Exchange (EKE) and Simple Password Exponential Key Exchange (SPEKE). A secondary problem is technical; both the EKE and SPEKE protocols have subtle but worrying technical limitations (see the paper for details).

At the 16th Workshop on Security Protocols held in April 2008, Cambridge, UK, I presented a new solution (joint work with Peter Ryan) called Password Authenticated Key Exchange by Juggling (or J-PAKE). The essence of the protocol design inherits from the earlier work on solving the Dining Cryptographers problem; we adapted the same juggling technique to the two-party case to solve the PAKE problem. To our best knowledge, this design is significantly different from all past PAKE solutions.

Intuitively, the J-PAKE protocol works like a juggling game between two people — if we regard a public key as a “ball”. In round one, each person throws two ephemeral public keys (”balls”) to each other. In round 2, each person combines the available public keys and the password to form a new public key, and throws the new “ball” to each other.

After round 2, the two parties can securely compute a common session key, if they supplied the same passwords. Otherwise, the protocol leaks nothing more than: “the supplied passwords at two sides are not the same”. In other words, one can prove his knowledge of the password without revealing it. A Java implementation of the protocol on a MacBook Pro laptop shows that the total computation time at each side is merely 75 ms.

We hope this protocol is of usefulness to security engineers. For example, compared with SSL/TLS, J-PAKE is potentially much more resistant against phishing attacks, not to mention that it is PKI-free. Since this protocol is the result of an academic research project, we didn’t — and have no intention to — patent it. As explained in the paper, J-PAKE even has technical advantages over the patented EKE and SPEKE in terms of security, with comparable efficiency. It has been submitted as a follow-up to the future extension of IEEE P1363.2.

We believe the PAKE research is important and has strong practical relevance. This post is to facilitate discussions on this subject. The paper can be viewed here. Any comments or questions are welcome.

Kapil Singh and Wenke Lee. On the Design of a Web Browser: Lessons learned from Operating Systems

Mike Ter Louw, Prithvi Bisht and V.N. Venkatakrishnan. Analysis of Hypertext Markup Isolation Techniques for XSS Prevention

Adrienne Felt and David Evans. Privacy Protection for Social Networking Platform

Monica Chew, Dirk Balfanz, and Ben Laurie. (Under)mining Privacy in Social Networks

D. K. Smetters. Building Secure Mashups

Tyler Close. Web-key: Mashing with Permission

Tyler's talk may have been the most entertaining of the day, if only because of his obvious frustration with what the web has become. Tyler's main claim was that we ought to be using capability URLs to handle our authentication and authorization concerns. URLs that encode both authentication and authorization data bring us back to the original intent of the web, where the link is everything.

It was nice to see someone railing against a bit of what the web has become, but it almost felt like an original internet user lamenting the end of the end-to-end internet. A decent architectural argument, and yet one that isn't likely to yield a lot of converts. I don't think I understood a few of Tyler's points about how to prevent these URLs from leaking out and/or how to revoke access should they happen to. There are a multitude of user acceptance, behavior, and expectation questions to be answered. It was a nice twist though on how to perhaps make access-controlled content more in keeping with the spirit of the web.

Mihai Christodorescu. Private Use of Untrusted Web Servers via Opportunistic Encryption

Mihai's presentation was about how to take advantage of networked services/web-applications while proividing them with only opaque data references created with cryptography. His main example was about how to use Google's Calendar product without ever sending them your real data, and sending them only client-side encrypted data instead.

While it seems like a nice idea, and while parts of his solution were technically elegant, I think again it was a solution looking for a problem. If you're so concerned about a networked service having your data that you're willing to reverse engineer the service to make it store your individual data elements encrypted, then perhaps a networked service isn't the one for you. TYhe architectural challenges in achieving what he was able to with Google's calendar are nearly impossible with a more complicated service. And, in order to make it work you have to give up many of the feature's you'd really like from a service - full text searching, etc.

I'm guessing there are a few places where's Mihai's ideas are feasible, but its hard for me to see the value prop in building what he proposed.

Some Final Thoughts:

• We haven't come close to solving the security problems in a Web-1.0 world
• We don't know what the security policies really ought to look like for the web, consequently we don't know what the architecture and implementation look like either.
• Browsers are lacking fundamental architecture and policy around security.
• Web-2.0 only makes things worse