Enter Duo Security: this company offers a cell phone based solution for multi-factor. Not overly exciting in itself, since this is something that has been around for quite a while. However, their solution is pretty flexible, since they support the usual callback and text-based flows, but also a smartphone app that leverages the device’s HSM for protection. The neat thing about this (semi-)soft token is that it does provide a OTP PIN solution based on hardware crypto providers, but without the hassle of keyfob distribution management.

In addition to the phone-based authentication flows (which obviously also works with landlines since they support voice callbacks), they also support hardware tokens, including Yubikey. It is ultimately up to the administrator to determine which devices are sufficient, but Duo supports the option to allow multiple devices and let the user choose.

Now, the really nice part about all this is that their Personal Edition for up to 10 users is free. This means that I can finally start to take a look at my personal stuff and determine if and where to enable multi-factor. The first step is this blog, since Duo provides all necessary components (cell phone app, service, WordPress plugin) out of the box. Setting this up took me about 15 minutes. VPN into my home network will be next on my list. 

At this point I would like to note that my time at MITRE was an outstanding experience: I was lucky to be able to work with some extremely talented and motivated people on both the Air Operation Center Modernization as well as on hData. During my tenure I learned a lot about the federal government and how it works (or sometimes not), but also had the opportunity to expand my own responsibilities and knowledge significantly.

Looking forward I am very excited about the opportunities and the high operational tempo at Demandware.

In this context, I would like to expand a little on Anil thoughts on how we can evaluate our confidence in authorization.

In the end – the service providers (or their delegates) are really interested a metric for the confidence of an authorization decision. As a SP, I am only mildly interested in the confidence in attributes: what I really care about is if the authorization decision that needs to be made is ok, or not. This is driven by a number of different factors (non exhaustive list)::

• Identification and authentication – as a service provider, I need to know who want to access my resources.
• Roles, attributes, and other authorization factors – determine what users are allowed to do, based on their characteristics. This process includes a very complex exercise of translating natural language policy into a conceptual access control model, and then into a machine interppretable set of policies and facts. These policies can be evaluated, using the facts as inputs, to compute the binary decision “grant access” or “don’t grant access”.
• Overall trustworthiness of the system components – this extends from the reliability of the authentication decision (reasonably well captured by the LOA) to the trust the service provider has in the authorization decision.

The need to address the authorization trustworthiness is reflected in the discussion presented in Peter’s and Anil’s article. Looking at the problem of attribute confidence, it makes sense to dig a little into literature on data quality metrics: at the end of the day, attribute confidence is essentially a data quality problem. There are a number of articles that have been published on this topic, including a number of articles from Rich Wang et al.

I think that it would be a good exercise for the IdAM community to revisit the data quality work, annd start looking into profiling this work for computing a quantitive value for confidence into a auuthorization decision. In a sense, any *BAC model incorporates a number of data source (including the LOA of the authentication) into the authorization process, and computes a binary result from them.

Applying the data quality metrics would allow to calculate a confidence score from the component data sources, that can be calcualted at runtime, to reflect both

• Existing service level agreements of the attributes that Anil mentions, as well a
• The current operational status of the data sources, i.e. some consideration as to whether the source can be trust right now.

This would ultimately result in a system that expresses the trustworthiness of a authorization decission in quantitative terms, which in turn may be used to make truly risk-adaptive access  conntrol decisions.

In the bigger picture “assigning” a LoA for attributes is pretty pretentious, especially when there is no clearly defined relationship between the certifier and the attribute consumer. The ultimate decision to release information lies with the logical custodian of that information (in OAuth: the resource owner, in XACML: the service provider). This decision authority may be delegated to PEPs, PDPs, or be exercised within a workflow.

As the decision authority now pulls in additional information from attribute providers, the environment, and other pertinent data sources, it (the decision authority) must make a determination whether to utilize and trust these sources or not.This determination will depend on a number of factors which ultimately result in the need to perform a risk assessment answering the question:

“If data source A is used for an access control decision, is the risk of making type 1 and/or type 2 mistakes acceptable for my use case?”

Obviously, this question can only ultimately by the logical data custodian, or its delegate. So instead of having an external entity assign a “Level of Assurance” to a particular attribute provider (or more general: a data source), attribute provider should make a set of metric available to potential consumers, so that they can make an informed risk decision. Among these metrics, I would think that the following list would be useful for access control decisions:

• Freshness – is the data up to date?
• Comprehensiveness – is the offered data sufficient to make a decision?
• Completeness – is the data available for all identities?
• Correctness – is the data accurate?
• Availability – will the attribute provider be available at all times, on all relevant networks?
• Operational soundness – are the business processes for the attribute provider sufficiently trustworthy to protect confidentiality, integrity, and availability of the data?
• Privacy/secrecy – is access to the data performed in a way that protects the data or the data consumer from unwanted disclosures?
• Accountability – is the data provider willing to accept responsibility for mistakes on their part?
• Arbitration – if something goes wrong, is there a binding arbitration process to determine responsibility?

There are probably many more, but this would be my shortlist.

2012 Mar 1 02:25:53 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=115.168.71.84 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060
2012 Feb 27 16:40:39 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=184.107.243.114 DST=192.168.1.248 PROTO=UDP SPT=5064 DPT=5060
2012 Feb 27 05:28:55 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=208.106.250.39 DST=192.168.1.248 PROTO=UDP SPT=5063 DPT=5060
2012 Feb 26 18:51:36 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=184.107.243.114 DST=192.168.1.248 PROTO=UDP SPT=5061 DPT=5060
2012 Feb 25 21:52:15 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=184.107.243.114 DST=192.168.1.248 PROTO=UDP SPT=5063 DPT=5060
2012 Feb 25 11:29:03 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=115.168.71.84 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060
2012 Feb 24 05:08:00 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=65.111.170.208 DST=192.168.1.248 PROTO=UDP SPT=5062 DPT=5060
2012 Feb 23 23:43:28 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=65.111.170.208 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060
2012 Feb 23 18:57:40 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=184.172.12.115 DST=192.168.1.248 PROTO=UDP SPT=5062 DPT=5060
2012 Feb 23 10:20:53 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=208.106.250.39 DST=192.168.1.248 PROTO=UDP SPT=5062 DPT=5060
2012 Feb 21 21:19:59 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=173.242.123.157 DST=192.168.1.248 PROTO=UDP SPT=5062 DPT=5060
2012 Feb 21 02:31:03 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=216.14.120.85 DST=192.168.1.248 PROTO=UDP SPT=5062 DPT=5060
2012 Feb 20 00:09:06 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=174.137.168.61 DST=192.168.1.248 PROTO=UDP SPT=5076 DPT=5060
2012 Feb 18 21:44:33 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=115.168.71.84 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060
2012 Feb 18 09:20:40 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=78.129.240.147 DST=192.168.1.248 PROTO=UDP SPT=5062 DPT=5060
2012 Feb 18 08:16:42 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=209.238.103.193 DST=192.168.1.248 PROTO=UDP SPT=5067 DPT=5060
2012 Feb 18 05:30:49 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=109.169.37.62 DST=192.168.1.248 PROTO=UDP SPT=5066 DPT=5060
2012 Feb 17 10:47:06 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=115.168.71.84 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060
2012 Feb 16 01:26:18 [Gateway] [kernel] WAN2DMZ[DROP] IN=WAN OUT=WAN SRC=85.25.100.44 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060
2012 Feb 15 23:40:58 [Gateway] [kernel] WAN2DMZ[ACCEPT] IN=WAN OUT=WAN SRC=123.238.137.150 DST=192.168.1.248 PROTO=UDP SPT=5060 DPT=5060

Let’s see: China Telecom, Beijing; iWeb, Montreal; ChrystalTech, Phoenix, AZ; China Telecom, Bejing; etc.

Most of the internet and web protocols are really built around the idea of interoperability (as defined above): vendors, academia, others, get together, define how the network facing interfaces and protocols are supposed to look like (syntax) and – for the more succesful ones – also what they mean (semantics). This works exceptionally well, especially in environements where the semantics are simple (well defined, not too many elements and/or variations, etc.).

For the “intraoperability” I have really a hard time finding useful examples. To some extent, the SPARC consortium would come to mind, or one might view some of the JEE and other APIs standards as attempts to narrow how a system should be built. However, for most vendors the temptation to add a few “value-add” extensions (a.k.a. vendor lock-in functions) is just too enticing. Note that this has also been seen with “interoperability”, where too many important fields where left for the implementer to define (NT-PAC data in the authorization field, anyone?).

As such I think that – while certainly problematic for high complex data models – “interoperability” seems to be the only realistic approach to get systems somehow to talk to each other.

In a number of ways, game designers and developers would make excellent developers for a number application domains, including C2. In fact, having a Command &Conquer or MechCommander 2 inspired interface with a truly capturing user engagement model could help improve operator experience for both situational awareness and decision support.

His new article discusses how America’s values have influenced the world order since WWII, and how the current international system is a direct mirror of these values. He argues that traditionally the international order was a reflection of the needs and desires of the dominant powers and warns that a growing dominance of autocratic regimes such as Russia and China will recreate and preserve many lesser evils, as we can see in Syria in this very moment.

One thing I found missing or only tangentially treated in the excerpt: The perennial believe in historicism, especially by the Western “elite” (or better: those that claim to be such an elite, social, intellectual, or otherwise). While in the past many have believed the historicist gospel of inevitable social development from feudal over democratic to communist, today’s intelligencia posits that a world without America will be just fine and preserve the free international order.

For myself, I really do not like OIDs at all (here comes the opinionated self back to the surface): OIDs and many similar identifiers carry information, but are not resolvable without a lot of pain. For example, each of the numbers in the OID is assigned to some sort of entity, like an organization (like the ITU-T), a country (like the USA), or a thing (the Internet). The dot notation is organized hierarchically, implying that you can “walk” that tree. Great. But you cannot, since each node owner (e.g. the owner of 1.3 = ISO Identified Org) can setup a registry for this branch and make it accessible to the wold, but the owner of e.g. 1.3.24 = DEC will probably not make their entire subtree resolvable to everyone. As such, if you encounter (hypothetically) an OID of value 1.3.24.0.1000, good luck figuring out what that may ever have meant. Even if HP wanted to make this available, it would take some heroic effort to find a public registry for 1.3.24 and then resolve this to some HP property.

On the other side, there are identifiers like IPv4 addresses which are – thanks to the wisdom of CIDR – essentially free of any special semantics: they are simply numbers. IPv6 does even a better job in making sure that the components of an IP address are not overloaded with meaning.

Finally, there are URLs that point to resources – and they have the wonderful feature that they can be fully resolved. If you are presented with a URL, you can immediately figure out where to go on the network to get to that resource. The path to the resource may not be clear (there could be firewalls or even air gaps in the way), but – in principle – your URL tells you exactly what to do if you want to get to the resource. Now, given that a URL points to exactly one resource, they make ideal identifier: they are unique (thanks to DNS and HTTP), they may carry some reasonable meaning (e.g. http://example.com/customers/1234/?invoice=9876 is pretty suggestive), and they can be resolvable into a representation of the resource.

Pick you own favorite.

To address the problem, NIST has provided the SP 800-30 risk management process for some time now. And while high-level threats are very application specific, the National Vulnerability Database provides a low-level overview for what vulnerabilities a threat actor could attempt to exploit.