Participants:
IAWG Voting Members: Andrew Hughes, Denny Prvu, Jimmy Jung, Mark King, Michael Magrath, Richard Wilsher, Mark Hapner
IAWG Participants: Eric Thompson, Lorrayne Auld, Marc Aronson, Max Fathauer, Varan Lal, Chris Lee, Jason Addis
Guests: Ben Piccarreta, Scott Perry, Simone Alcorn, Tom Barton, Lewis Lott, Noreen Whysel
NIST Reps: David Temoshok, Ryan Galluzzo, Andy Regenscheid, Connie LaSalle, Jim Fenton, Justin Richter, Sarbari Gupta, Christine Abruzzi
Kantara: Lynzie Adams, Kay Chopard
Andrew Hughes, IAWG Chair, opened the meeting and allowed David Temoshok to introduce the NIST reps on the call. He then introduced IAWG leadership. Questions and responses from the call are outlined below. Please use the TOC below to jump to different topics and questions you’d like to review responses for.
Federation:
It is noted that Volume C has more material in this revision. What is the rationale for beefing it up? Is it related to the maturity of federation in federal government over time? Or in response to certain incidents that NIST has been dealing with the last several years?
When NIST was creating rev.3 there were already fairly clear paths for the content of what became Volume A and Volume B. But, the bits about federation and network connections were spread throughout rev.2. So, in creating rev.3 that was the first attempt at pulling that all together into a separate volume. With rev.4, NIST has been able to combine comments received over the last 5 years and their experience to realize they were implying several things that were required… but were not necessarily named (i.e. how connections were made, how trust was managed, how information was conveyed, etc). There was a lot left unsaid but now NIST is trying to be explicit.
Much of the new content are not new concepts. It was in rev.3 but under an assumption. Example: the trust agreement section was already implied by the previous registration section but in a round about way. Now it is explicit. Example: the identity APIs – specifically provisioning APIs – and how account provisioning happens. It was implied that it could happen but it was not explicitly said what the different expected models were and what to do under these models.
NIST also revised and defined how they laid out the different federation assurance levels. Some updates were for clarity in response to questions received around FAL2. This revision also better reflects some of the threats being seen against federation and SSO systems – particularly at the FAL2 level. FAL2 now requires injection protection – protection of the RPs from accepting injected assertions. The requirement now at FAL2 is that RPs need to be using controls so that they only accept assertions that are in response to a request that they made and are able to tie back. NIST recommends doing that through back-channel assertion presentation – though not required at FAL2. Additionally, in Rev. 3 FAL2 requirement was all about the encryption of the assertion. Was partially about protecting the data in transit but also about the stricter audience restriction. NIST received several questions about when to use FAL2 and how to use FAL2. NIST realized early on in the process that they were conflating the data protection requirements around the assertion contents with the overall trust of the transaction that FAL2 should be giving. The encryption requirement is still there if you are passing PII in the assertion through a 3rd party in rev.4, but now it’s been decoupled from FAL2 so you can apply that requirement where it makes sense and it is truly useful and needed.
Significant changes were made around FAL3 as well in order to accommodate for different types of proof of possession assertions. FAL1 is still pretty similar to rev. 3.
People conveyed concern because FEDRAMP said you must do everything in 800-63 for all three (A,B,C) at the same level. These are often organizations that are not federated except to themselves. Have any of those comments made it to NIST or into these updates?
There were comments about FEDRAMP doing that very early on in the rev. 3 lifecycle. Things were split up into volumes (A,B,C) so that they could stay split up! Stop tying them back together!
The scope of 63C is federation and assertions that includes use of federation protocols to support enterprise SSO. When talking about using federation and federation protocols that encompass both the inter-organization case of exchanging identity attributes and information as well as within an organization to protect the SSO systems.
Agencies have asked “I’m not federating externally but I am using SSO and using federation protocols to support that, what is the expectation to apply federation levels to that particular use case?” NIST is attempting to make clear within the text and through their presentations that it is still something covered within 63c. That said, if your use case requires IAL3 and AAL3 it may not necessarily require FAL3. They are intended to vary separately. That needs to be determined on the specifics of the use case. With that in mind, if you are using federation protocols and systems in an internal enterprise system you should have some FAL, but it is not necessarily going to be the same number as the other dimensions.
One issue is understanding how equity in federation applies. Do you have any brief comments on how you think the inclusion of equity has impacted federation?
It’s a little bit of a different context than 63a and 63b because it’s more of an underlying protocol. There are certain aspects, particularly as you start to look at your trust agreements and other agreement components and the level of assurance expected from providers. Some of that information & documentation is going to be expected to be captured there but certainly not the same as 63a and 63b. Aspects of equity definitely need to be built into federation agreements – and potentially how to explain some of these things. More of an accessibility issue rather than equity. Ensuring the end-user understands what’s happening when federation occurs and explaining it in a way that a user can actually understand what is happening.
Some of this is referenced in the new equity section of the 63c rev.4 draft. A bit of a different case than proofing where there is a lot of fairly specific examples of issues that are discussed. There are equity considerations that need to be taken into account while developing the trust agreements and policies so that the impact the system may have on the users is understood. This is a place where the distinction between equity, accessibility, and privacy all start to blend together. Do not consider equity, accessibility, and privacy issues to exist in a vacuum – they are very much intersectional. If there is a privacy issue that lends itself to an undue burden/impact for a particular group, that is considered an equity impact. It might be talking about it in the context of privacy or security, but the point is looking at the outcome (what is happening across demographic groups or socioeconomic strata? Is it creating an inadvertent barrier to entry or access?). It’s more complicated as the issues start to overlap when you think about where this comes up in federation – and across all of the volumes.
In 63c there now appears to be requirements on the RPs. Previously, it’s been mostly requirements on the IDPs/CSPs. Any observations on this? Internally, Kantara will need to adjust their assurance program model is fit these new requirements.
The requirements on RPs are not new. Another example where 63c requirements were there but they were not laid out – only implied. The text has been reorganized to make it more obvious in rev.4. RPs have always been required to do the validation of the assertions, manage any sign-in keys they had, process things in a particular context/way (i.e., expired assertions), etc. All of this was already there it was just woven in a way that was not as obvious. This is one of the document structural changes NIST made a point to correct in this revision.
The importance from NIST’s perspective is that the requirements on the RPs are explicit and clear because there is the supposition that the vast majority of the trust lays with the IDP/CSP and not as much on the RP. NIST wanted to emphasize that there is a very critical role that the RP is playing and it needs to be done to a well-defined approach. Making sure those were clear was essential. Very specific to federal RPs and other organizations that choose to use this guidance that there is an expectation to do certain things and maintain certain expectations within the federation process. This is not an unprecedented thing – in the PKI world it is very common within a certificate policy for the template to lay out the responsibilities of the RPs there.
In any conformity assessment program, you have to make decisions around what the scope is going to be for the different programs. In terms of performing an assessment, it doesn’t matter if it is a CSP or an RP. There is a set of requirements that are assessed and either they are being met – or not. The problem potentially with RPs is that if it’s a large community, how long will it take? How complex does that make it? How does one even manage the logistics? Do we end up with RPs entering into separate agreements? Or a blanket agreement? None of this is really NIST’s responsibility to answer but they will be the principal consideration when Kantara moves forward.