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:
Q: 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?
R: 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.
Q: 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?
R: 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.