Sean Convery

Part two of a two-part article titled Network Authentication, Authorization, and Accounting was just published in the Internet Protocol Journal. I wrote the article to be a survey of the entire AAA space and so it covers a lot of ground without spending too much time in one place. If you are new to AAA or are looking for a conceptual model of AAA to help others grasp its concepts, please take a look. Here’s a snippet:

Network Authentication, Authorization, and Accounting has been used since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And finally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. The first part of this two-part series focused on the overall concepts of AAA, the elements involved in AAA communications, and high-level approaches to achieving specific AAA goals. It was published in IPJ Volume 10, No. 1. This second part of the series discusses the protocols involved, specific applications of AAA, and considerations for the future of AAA.

Although AAA is often thought of as the exclusive province of the Remote Authentication Dial-In User Service (RADIUS) protocol, in reality a range of protocols is involved at various stages of the AAA conversation. This section introduces these AAA protocols, organized according to the parties involved in the communication. We divide AAA communications into the following categories: Client to Policy Enforcement Point (PEP), PEP to Policy Decision Point (PDP), Client to PDP, and PDP to Policy Information Point (PIP).

You can get the HTML or the PDF.

Technorati Tags: 802.1X, AAA, IPJ

The IETF draft I’ve been tracking that defines a common format to communicate IP ACLs via RADIUS is now an official RFC. 4849 has a nice ring to it, hopefully it will become part of the networking and security vernacular like 1918 or 2827. Remember the RFC doesn’t mean anything until the industry builds support into its products. If you are a customer of Cisco, Juniper, Nortel or any other networking vendor I encourage you to ask for RFC 4849 support as soon as possible. Supporting it makes sense in almost all access devices: firewalls, wired switches, WLAN APs, and VPN gateways. Enabling role-based access control throughout your network is becoming less of a dream each day; RFC 4849 gets us one big step closer by defining a mechanism to support ACLs in heterogeneous network infrastructure. Here’s the abstract, scary that I get excited by this stuff:

While RFC 2865 defines the Filter-Id attribute, it requires that the Network Access Server (NAS) be pre-populated with the desired filters. However, in situations where the server operator does not know which filters have been pre-populated, it is useful to specify filter rules explicitly. This document defines the NAS-Filter-Rule attribute within the Remote Authentication Dial In User Service (RADIUS). This attribute is based on the Diameter NAS-Filter-Rule Attribute Value Pair (AVP) described in RFC 4005, and the IPFilterRule syntax defined in RFC 3588.

Technorati Tags: AAA, NAC

While normally I would shy away from mentioning Identity Engines’ online events here, I’ll make an exception this time. I’m presenting the IdM-N talk on May 10th at 11:00 AM PDT via the web. If you’d like to hear me talk through some of the concepts live and ask questions (though you’ve always got the comments field on this blog) feel free to register. I can’t guarantee one of our friendly sales guys won’t call you, so consider yourself warned. I’ve got a few slides at the end on what Identity Engines does but the bulk of the talk is vendor neutral. The talk will be nearly identical to what I delivered to Secure IT, NYMISSA, and the NAC so if you are familiar with the material in those presentations you can safely skip this one.

Technorati Tags: AAA, Identity Management

I presented Identity Management for Networks to the Network Applications Consortium (NAC) late last week. The presentation is very similar to others I’ve posted recently so no need to download it if you’ve looked at anything I’ve done recently. What is new is my answers to the presenter questions the NAC posed to everyone at the conference. As the questions are fairly interesting, here they are complete with my answers in italics.

1. Do you see any differences in how the authorization policies of networks vs. applications should be engineered, managed, and provisioned? Network policies are broader today due to limitations of the technology and understanding of the business roles. Eventually network policies will be merged with application policies.
2. Are there any advantages or drawbacks in the flow of the access request being sent to the PDP first or the PEP first? PDP first requires basic authorization to route the request from the network edge which may be suboptimal.
3. Do you see declarative authorization interpreting and enforcing more finely grained authorization policies than they support today? Yes though this is as much a challenge for enterprises to understand their roles as it is a technical challenge to support the fine-grained authorization.
4. Should SAML authorization assertions, and requests for authorization assertion, be used in the communication between PDPs and PEPs? If not, what should be used? For networks, SAML will be used in the future but perhaps more for PDP to PDP communication in a federated model than for PDP to PEP communication. In the network space RADIUS has traction simply because it is so ubiquitous.
5. How can we meet our need for flexibility to deploy centralized and/or de- centralized approaches within an enterprise and across enterprise customer, supplier, or channel partners using different platforms? Policy portability through XACML and authorization assertions through SAML can address much of this, challenges here are more at the organizational level.
6. Comment on the NAC’s best practice of locating the PEP as close to the resource as possible. For networks, it may make more sense to locate the PEP as close to the point of network access as possible to reduce exposure to threats. If you consider the network the resource then our best practices are aligned.
7. Comment on the NAC’s best practice of balancing between availability and performance when selecting the location of the PDP. This makes perfect sense, distribution of the PDP may be key depending on the application.
8. Comment on the NAC’s best practice of having platform agnostic PAPs and PDPs, loosely coupled with access management product offerings (e.g., WAM products). This allows for the independent evolution of PAP, PDP, and PEP technology, without disrupting the other components. This is the only way this can scale long term, particularly the vendor neutrality between the PDP and the PEP. Standards for access control formats need more attention.

Technorati Tags: AAA, Identity Management

In case you have an aversion to the PDF format my article was originally posted in, it is now up in HTML form. I haven’t seen the print version in the mail yet, but hopefully that will be soon.

Technorati Tags: AAA, Identity Management

Part one of a two-part article titled Network Authentication, Authorization, and Accounting was just published in the Internet Protocol Journal. I wrote the article as a survey of the entire AAA space and so it covers a lot of ground without spending too much time in one place. If you are new to AAA or are looking for a conceptual model of AAA to help others grasp its concepts, please take a look. Here’s the opening couple of paragraphs:

Network Authentication, Authorization, and Accounting (AAA, pronounced “triple-A”) is a technology that has been in use since before the days of the Internet as we know it today. Authentication asks the question, “Who or what are you?” Authorization asks, “What are you allowed to do?” And finally, accounting wants to know, “What did you do?” These fundamental security building blocks are being used in expanded ways today. This article, the first in a two-part series, focuses on the overall concepts of AAA, defines the elements involved in AAA communications, and discusses high-level approaches to achieving specific AAA goals. Part two of the article, to be published in a future issue of IPJ, will discuss the protocols involved, specific AAA applications, and considerations for the future of AAA.

AAA, at its core, is all about enabling mobility and dynamic security. Without AAA, a network must be statically configured to control access; IP addresses must be fixed, systems cannot move, and connectivity options should be well defined. Even the earliest days of dialup access broke this static model, thereby requiring AAA. Today, the proliferation of mobile devices, diverse network consumers, and varied network access methods combine to create an environment that places greater demands on AAA.

AAA has a part to play in almost all the ways we access a network today. Emerging technologies such as Network Access Control (NAC) extend AAA even into corporate Ethernet access (historically the “trusted” network that set the benchmark level of security that all other types of access had to match). Today, wireless hotspots need AAA for security, partitioned networks require AAA to enforce segmentation, and remote access of every kind uses AAA to authorize remote users. Continue to IPJ

Technorati Tags: AAA, IPJ

Yesterday I presented at the Secure IT Conference in Sacramento, CA. I did a presentation on identity management applied to networking called “RADIUS Grows Up: Identity Management for Networks.” If you are new to the space, this presentation should give you some good background on what problems need to be solved, and what some possible approaches are. In other news, my cast is off and the arm splint should be gone next week!

Technorati Tags: NAC, Identity Management

Back in June I wrote about a new draft in the IETF RADEXT working group concerning access control lists (ACLs). The draft specified a way to generically format and transmit IP ACLs using RADIUS. The draft is now in its sixth revision and left the working group headed towards a proposed standard in the IETF. If approved, we will finally have a common technique for passing ACLs to a network enforcement device from a AAA server. The approach taken in this draft is to reuse the filter format defined within Diameter (scroll down to page 44 to see the format). To date, enforcement vendors have either relied on proprietary techniques for formatting these ACLs or have simply not supported them. It is very common today to see no support for the specific ACL but a more general support for the RADIUS Filter-Id attribute (attribute 11, page 35). The Filter-Id attribute is nice but it only allows the AAA server to point to a pre-existing filter on the enforcement device, not to create one on the AAA server.

The key, if approved, will be getting the enforcement vendors to support the new standard. Since HP authored the draft It seems quite likely that HP will support the capability. If Cisco and Juniper follow suit it would be great news for customers struggling with network level authorizations throughout a heterogeneous network. My guess is customer pressure will be instrumental in getting the big guys on board. Pairing this functionality with network-wide authentication and some basic NAC checks and you’ve suddenly got a heterogeneous solution which hangs together quite nicely. Heck, toss in RFC 3576 support and you’ll really be onto something.

Technorati Tags: 802.1X, NAC, RADIUS

-Special thanks to Roy Chua for taking notes on this session I participated in on Tuesday-

Panel

ESG
- Jon Oltsik – introducing

ConSentry – Jeff Prince

- Secure internal LAN, not rip replace
- Full user visibility and mitigation
- Here – identity key to their closing of businessSanjay Uppal – CEO of Caymas- Identity control appliances
- Have been doing for some time now
- How it all comes together, two important categories coming togetherSean Convery – CTO of Identity Engines- Network identity management platform
- User is center of identity in enterprise
- Bring user directories to the network – to make meaningful decisions
- Works with new devices as well as existing equipmentPaul Sangster – Chief standards officer at Symantec- Security and integrity protection for enterprises
- Co-chair of TNC group
- Working on NAC open standards

Definition of Network Identity

Paul Sangster

- establishing set of attributes with regard to things on network
- From NIC card to laptop to human
- And authorized to get on network
- Identity – ties into integrity and event managementSean Convery- Network ID used to be MAC and IP addresses
- Talked about spreadsheets and IP = user
- Mobility has made MAC and IP more difficult
- Seeing prevalence of user-centric identity
- From simple auth to 802.1XSanjay - Practical and then future
- 2-factor, client certs – one aspect
- Other aspect – integrity of device – combination of multiple ID
- Practical – integrity of device
- User – username, password, token
- Future – combination of twoJeff Prince- Knowing users and machines connecting to network
- Trick (as Sean put) – bind users to IP and MAC
- How to make user-readable, and location-based – bob, using machine X in office 12
- Location is important as wellCisco and MSFT were invited to participate but declined

Jon: implementation is difficult
Many supplicants, devices, EAP strategies

What to help people ease into solution

Jeff Prince

- Been in networking long time
- Things that become pervasive on network – easy to deploy, cost effective, high performance
- Cisco NAC – good vision, impossible to implement
- ConSentry want to execute that vision – e.g. rip out L2 switchesSean Convery- Cisco not quick to release NAC specifications
- Seeing lots of interest in preserving infrastructure built out
- Seeing disparity in making enforcement technologies
- From enterprise – deploying 6, 8, 10 different things – hard
- Need central authoring and policy point
- Trying to put all eggs in one technology basket is troublesome long term
- Particularly due to lack of standardsPaul Sangster- See difficulty in deploying – e.g. AV, desktop FWs – people turning it off
- IT needs centralized point of control – and when joining, want to make sure that the machine is healthy and to do so periodically
- Customers tell them this is very difficult but customers don’t want to take the wrong step – don’t want to step up until see long term future of spaceSanjay Raja- Agree that Cisco and MSFT is not open enough
- Don’t agree with vision of NAC – network admission control
- Customers are asking, after you get admitted, where can you go
- Shouldn’t be limited to just network, but applications as well
- NAC should be access control done in the network, as opposed to, to the networkJon: who supports TNC, and why hasn’t everyone in audience heard of it

Paul Sangster

- Communication – Cisco and MSFT have large PR budget and voices
- TNC – many large companies, focused message is hardJeff Prince- Biggest frustration – CSCO not member
- Own 80% not adhere to standard, neuter standard
- User community put pressure on CSCO to join
- Best way is to drive standards between endpoint and networkSean Convery - Not failure of TNC
- But failure of any architecture for NAC overall
- Have had problems deploying NAC framework at Cisco
- Customers are coming and saying NAC with AV, and firewall and .dat files are good
- Want to know who’s coming on network first, and then along with everything elseSanjay Uppal- Agreed, how to integrate client with network
- Should have defined protocol for not 802.1X but others
- Captive portal and web-based login first, and then do bells and whistles
- Need an open supplicantJon: trying to rally around the open supplicant- MSFT, CSCO, Juniper – proprietary – how to drive open supplicants
- Good grassroots support to date – www.enterprisestrategygroup.com
Question from audience:- Why won’t people stay with MSFT and CSCO and wait until they are done rolling outSanjay Uppal- Most of their customers (e.g. Hormel), waiting for Longhorn or CSCO, a lot to ask for from people with problems today
- Already have problems with identity theft and guest users
- Products on panel will solve that today and don’t have to wait till giants learn to dance
- For entire infrastructure though, advice is to waitPaul Sangster- Normal enterprise risk analysis decision
- Lots of data on cost for enterprise for not being able to enforce decisions about posture (worms, malware etc)
- Don’t want to make bad decision, need future proofing
- Nature of attacks over last 12 months, more focused on enterprises
- Without integrity checking, lots of enterprises have user auth, nothing to stop malware
- Need to have no malware stealing credentialsSean Convery- Agree that solving acute problems today
- Biggest people deploying our product have short-term access problems
- When talking about NAC and are people ready to deploy NAC
- NAC is AAA
- Dialing into POP over SLIP – using AAA NAC back then
- Principle reason we exist – authenticate people on network
- Repository of user identity and not treated as a critical resource on network
- AAA down – lose VPN and wireless
- Moving forward, how do you authorize users to get on networkSanjay Uppal- On aspects of what customers should do from a practical standpoint
- Non-employees getting on network – biggest risk
- Yesterday – SLIP connection – had today, but need combination of identity of user and device as well (e.g. folks in India and Philippines doing contract programming)Jon:- How much marketing money CSCO has? LotsAudience: where’s the vision for centralizing policies throughout the company . Don’t have the people – geeks on parade. Don’t want to call someone to make change in some device. How to go I to a central policy store to make these changes across enterprise-wide.

Jon – paraphrase – centralized policy instead of policy everywhere

Sean:

- Think we have won’t have centralized policy today, and may never, but some day
- Trying to embrace standards around this area – e.g. XACML around that, SOAP-based interface
- Work on networking problems first, and then start doing it for the applications-side, assert it to the futureJeff:- See solution boiling down to three basic components:
o End point, control piece in switching infrastructure, and IdM infrastructure
o Defining standards – is critical
- Today, ConSentry built controller behind the switches, can’t rip and replace everything
- As people do switch replacement, will see it coming in
- Announced secure switch, embeds full function into wire-speed switchSanjay Uppal- From enterprise, have concern about adding more layers
- Don’t want new policy in AD, RADIUS etc
- There are standards for asking about Identity – not rich, but can work
- No standard way to ask for policy yet
- Also need standards to federate health
- Once standards set – one place to set policy to get management policy (not appliance), and enforcement can be switch or not, think appliance is still important, need client piece as well for integrityPaul Sangster- Centralized place for policies
- Everyone has that, but then you still end up with many centralized stores
- Need MetaDirectory
- Need a PDP that can talk to other PDPs or network
- Can express PDP in some form and push it out (e.g. XACML)Jon:- See standards – e.g. Federation, users have to drive big vendors on TCG and 802.1X
- Will have more IP devices, no vendor at all, including CSCO, MSFT, that will give us what we needAudience:
Qn: focus on LAN and enterprise network, WiFi LANs, services networks etc
Federated model with common security model, tying in all the items, e.g. DS_69 on DSL forum, is important. Standards from wide area, to LAN to core etc.

Is there integrated architecture, for LAN, WAN, Service Provider etc?

Paul Sangster

- Don’t want different infrastructure for all – how to come up with extensible portion across all networks
- Access points for WiFi to talk to RADIUS
- Maybe not needed for LAN over cable
- Backends need common infrastructure – TNC identity all common areas
- Have laid down protocols for bottom layer for some areas already
- Pushing that TNC can cover it all as a high-level infrastructureSean Convery - When we say appliance, means different things to different people
- Goal of IDE is to work with different types of devices
- E.g. FW, switch etc
- Aggregation to get all these things talking
- RADIUS got us on 99% of access decision today
- Some disagreement – position – rich decision made in one place is good, but also want consistent set of entitlements in terms of what you’re allowed on
- But can only do that with standards - so there is limitation
- Even insertion of a device everywhere is close to rip and replaceSanjay Uppal- NAC is not limited to LAN
- Disagreement – their device can check local area network and wide area
- Perimeter is disappearing but they are appearing elsewhere
- It is not just LAN, but also where users are coming in from Jeff Prince- No reason why they can’t span LAN and WAN
- Once solve problems for LAN, then can solve problems for WAN and other places as wellAudience – TNT - Practitioners here – don’t wait. Even TCG/TNC will take time
- There are problems now, and people are buying equipment that the vendors are buying
- Forward thinking folks don’t care and will solve the problem now
- ‘Who is buying the stuff now’
- What position, what problem solvingJeff:- Customers are driven by compliance – PCI compliance in 3 weeks
- Passed audit within 3 weeks
- Regulated folks – HIPAA, PCI, SOX – folks with corporate assets on LAN
- Prove have clamped data need now
- Compliance is not done yet (still real today)Sanjay:- 1. There is a compliance push out there
- No one is making be-all and end-all of compliance solution
- Have one, pass all, no compliance in a box today
- Can implement these much quicker
- 2. Business enablement – e.g. outsourcing, make sure people only get access to specific areas. Not security value-prop, but business value-prop
- 3. Risk management – ID theft, laptops getting stolen, CIOs want to lock down sensitive information, criminal or other records
- Identity-based NAC to deal with thatSean:- Biggest problem – contractors, guests, visitors – that we are solving right now
- Keeps customer excited longer term
- Flexibility of policy
- Organizations have directories all over – really useful information – meaningful access decision
- E.g. Library at university that wanted low QoS for overdue customersPaul:- Apply political approach
- He is a standards person
- TNC – no standard, but people have standards-compliant products?
- Going out and taking RADIUS and using it
- Using EAP and if doing 802.1X, already have it
- TLS, IPsec, doing standards over
- Have to have a common way do the same thing, protocol standards already existJon: 7 minutes left – Lightning Round

Audience: so, who is the buyer?

Jeff:

- Security is champion, but the network ops guys is the one buyingSanjay:- Security guy signoff- app guy if app resource, or networking guy if network resourceSean:- network and security guysPaul:- samePapa Gino’s – audience, Chris Cahalin, Network Manager
Qn: $ spent towards unified standards is $ saved

-TPM already exists on laptops – march 2005 – have been using it
- Facilitates business
- Backs TCG
- Extends end-point analysis, can you trust the response you’re getting
- In deployment today
- Appreciates open standards

Jon: closing thoughts

Paul:

- too many NAC, tell vendors that want one open solution, can start today
- Built on things already deployed

Sean:- Can start today
- Things that you can do that don’t require TPM or OTP
- User names and passwords insufficient is not reason
- Diagnostics etc are more significantSanjay:- Enterprises with business problem today – they have solution
- Audience in IdM space – combination will get thereJeff:- Clear alternatives to CSCO
- Get to secure LAN today with them
- Give them opportunity and show value

Technorati Tags: 802.1X, identity, NAC

Yesterday Cisco announced its intent to purchase Meetinghouse, the only remaining 802.1X supplicant vendor in the market after Juniper’s recent acquisition of Funk. As Wi-fi Net News notes, this thins the RADIUS market even further (though it sounds like I should get my marketing department in touch with the author–Glenn Fleishman–for a product overview). Overall the acquisition seems like a significant positive for Cisco for a number of reasons. There are also some considerations for the industry as a whole. Let’s cover Cisco first.

First, Cisco now has a multi-OS supplicant they can provide to their customers to help remove objections to new wireless or wired infrastructure deployments. They achieved this goal for significantly less money that Juniper did with Funk (44 vs. 122 million) in part because Meetinghouse did not have a significant presence in the AAA server space the way Funk did with its SBR. Since Cisco has their own AAA server in ACS, this wasn’t a significant issue in Cisco’s eyes.

Second, it appears that Juniper is attempting to take control of the edge access methods within an organization through either their SSL VPN products or the 802.1X supplicant. Since they have neither Ethernet switches nor wireless APs to sell, they recognize revenue on the supplicant. Cisco on the other hand, has both switches and WLAN APs allowing them to use their new supplicant as an enabler potentially by giving the client away or offering it for substantially less. Assuming that Cisco continues to commit to standards, having a freely-available and well-supported supplicant in the marketplace would be a great thing.

Third, by being in control of the supplicant rather than using an OEM Cisco can have complete control over the roadmap ensuring that the supplicant does what is needed for both WLAN and Cisco NAC.

Moving onto the industry implications things get a bit more muddy. First, I think this will be a net positive for 802.1X deployment but I’m not certain which way Cisco will go with respect to keeping the Meetinghouse supplicant open. If they go the route of a free supplicant, what motivation do they have to make sure it supports the EAP-types and unique parameters of their competitor’s gear?

Speaking of standards, the TCG TNC could be adversely affected. The TNC has been around for a couple years now and hasn’t yet seen a ton of traction. Up until May’s Interop conference, Juniper was the only announced and shipping TNC server. At Interop, Meetinghouse announced an appliance which was set to be the second TNC server though it has no definite ship date to customers. Since Cisco seems to view the IETF as the only viable forum for standards in this space I would not at all be surprised to see Cisco end Meetinghouse’s engagement with the TNC and kill the announced appliance. This would leave the TCG TNC effort as primarily Juniper and friends. Looking at the announced and shipping products list on the TCG website it looks quite thin.

As stated several times on this blog, 802.1X is hardly the runaway success it hopes to be, at least on the wired side. Cisco themselves are pushing the NAC appliance more than the 802.1X approach anyway which diminishes the implications of much of this. Until the industry gets some agreement on a ubiquitous and standard tunneled-EAP type as well as some standardization in messages and frameworks many organizations will be left to put together ad-hoc solutions which may not hold out for the long haul.

Companies can recognize significant value from authenticated networks today using a mix of authentication methods including 802.1X. The benefits of centralized policy decision and network compartmentalization are real. The key is to avoid going into this thinking that it is a binary event to turn on 802.1X. As mentioned earlier, making good use of the default VLAN feature can give you a migration path which doesn’t seem quite so vertical.