High Assurance OAuth/OIDC Profiles for Gov. use Cases
High Assurance OAuth/OIDC Profiles for Government Use Cases
Wednesday 10H
Convener(s): Mark Russell
Notes-taker(s): Mark Russell
Tags for the session - technology discussed/ideas considered:
- - OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens
- - OAuth Token Exchange
- - OAuth Assertion Flow
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
We discussed high-assurance requirements in certain types of government environments (e.g. intelligence, defense, etc.) and the current security architecture which is heavily dependent on direct client TLS authentication of users and systems. I described a current US Government effort to profile OAuth 2.0 and OpenID Connect 1.0 to create a suitable security profile for this environment. Government-specific concerns and considerations include:
- Existing robust and highly capable PKI, which should be taken advantage of
- Strong concerns over the use of bearer tokens - requirement for some form of proof-of-possession
- A requirement to provide assurance information in authentication assertions (e.g., via OIDC)
- Specifically, a requirement to convey the Identity Assurance Level (IAL) and Authentication Assurance Level (AAL) as defined in NIST SP 800-63-3
- A desire to tighten requirements around basic security parameters - cipher suites, assertion signing algorithms, key sizes, lifetimes of tokens and codes
- General distrust of the front-channel
- Aversion to dynamic registration
- Aversion to JWT-based authentication, primarily because clients will generally already have client TLS credentials
The US Government would ideally like to engage with existing OpenID or IETF working groups if possible to define a public standard that is not government-specific.
The group discussed these security requirements and there was agreement that many of these requirements are in line with general high-assurance requirements in other areas such as finance. Some of the differences between FAPI and the US government profiles were discussed, and also the fact that some aspects of FAPI may be revised based on changing requirements. It was broadly agreed that the US Government profiling project should engage with FAPI to identify common ground and potentially work towards a FAPI high assurance profile. Potential engagement at the IETF Security Working Group meeting in Trondheim was discussed.
We then discussed an additional government use case involving chained service calls, in which an OAuth PR needs to call another PR (which may in turn call another) where each node in the chain must be aware of both the end-user's identity and the identity of all systems in the chain of calls. In the simple case, these calls occur within a single security domain, all PRs trust the same AS, and token exchange can be used in a straightforward way. In the cross-domain use case, additional considerations come into play. The group generally agreed that both scenarios were solvable with various solutions that entail different trade-offs.
