Versions Compared

Old Version 5

changes.mady.by.user Former user

Saved on

compared with

New Version 6

changes.mady.by.user Former user

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Ken welcomed everyone to the meeting. He said that some questions were  were sent to NIST around two weeks ago, and a couple more last week. The idea is to go through those questions, and to see NIST’s opinion on those. 
  • Richard started making an introduction summary in order to contextualize NIST. 
  • NIST pointed out that one of the reasons why they brought this up in the email is that several of the questions have phrases like: “how is this different from the IdP and RP interacting without a Federation?”. Which to them indicated that there was no consideration of non-formal of agreements. When the RP and the IdP interact, they interact under a Federation. Under the guidance of 63C, that is how broadly they define it. NIST intentionally allowed 63C to be implied to internal application of Federation Protocols, so that if the same party is running both, the IdP and the RP, you still need to abide by these rules.
  • NIST also mentioned that probably (not as commonly) it would make sense for some RPs to pursue certification regardless of which IdP they are talking to. Richard commented that it would be a problem where there was not a clear Federation Agreement, which is a term invented to mean whatever rule the parties have decided to operate again. Consequently, different Federations may have different rules and therefore, an assessment can say “you are 63C compliant” and it only goes that far, but it cannot go to the level of saying this Federation wants you to do a, b, c, and accordingly you are assessed against the precise requirement of those Federations. This is the difficulty that Richard found.
  • NIST explained they always saw 63C as something that will be potentially part of a Federation Agreement, if that is how people wanted to set up their Federation. Otherwise, it is a set of requirements for anybody who is doing this type of interconnection between systems, within a Federal Government.
  • NIST commented on question 1, that they wanted to say that just because you can connect your systems together, it does not mean that you are allowed to pass all of the users’ information. There must be additional policies that say you are allowed to do that explicitly, you are also allowed to make a runtime decision, which is another section in 63C. NIST is not requiring that you interactively collect consent, but NIST is allowing that you interactively collect consent as a mean of fulfilling this policy. In addition, the fact that the parties have not federated is not an excuse to ignore the consent requirement. Getting a user’s PII is a separate consideration of being to plug one piece of software into another.
  • Richard noted the fact they used the phrase PII and he said it was an internal discussion. NIST asked Richard not to read much into the statement they made, it is just to get user’s information. NIST would consider a subject identifier for a correct user as personal information even-though it is not directly identifiable.
  • Ken explained he understood that you need consent to pass information, just because you are federated it does not mean you are allowed to pass it.
  • In question 1, it was added as response “Prevailing limitations must be observed, notwithstanding specific requests for consent to be gathered. Info post-authentication is excluded”.
  • NIST pointed out that this type of information and that type of information access are generally not going to be covered by 63C, because that is not information that would be passed in an Identity Assertion. It would be covered by 63C to the extent that it is passed as an attribute of property of an assertion. But, information about the user outside that transaction, is not covered by 63C.
  • About question 2, NIST explained that it is directed at whoever is managing the whitelist. Richard asked how they expect the RP to do that. NIST responded that if the IdP has paid for an assessment that the RP can read and accept, that is it. The RP needs to do some evaluation of the IdP in order to make sure that they are authenticating the user properly. Richard added that this clause is saying that an IdP shall only include in its whitelists those RPs which apply by the provisions… etc. NIST confirmed it. Richard also mentioned that it says “all IdPs and RPs whitelists shall abide by”, he asked if there is any particular reason for having those two clauses separated. NIST responded they have to be separated because any given RP or IdP may belong to different Federation Agreements, and some of those Agreements may be bilateral. Accordingly, it was added as response “Should be a discrete criterion for IdPs, separate from that for RPs”.
  • Richard stressed that Kantara has determined criteria in order to try to provide structure, within which an assessment can be meaningfully conducted. That is one of the challenges.
  • NIST commented that regardless of why you would do this, the function of a whitelist is for an IdP to say when it knows a user is login into this RP, is it needed to ask the user whether information can be given to it, or is there already something that tells me that this information can be given out? That is the definition and purpose of the whitelist.
  • NIST explained that blacklisting is important when it allows for a dynamic registration in a gray list. No matter what the user wants to say, it will not be allowed to log in with its identity there. This requirement does not make any sense without understanding what the function of a whitelist is. The consent has been granted by the nature of it being on the whitelist, not necessarily by the individual user making an individual decision. In relation to this, it was added as a response in question 2 “Whitelists allow IdP to make decisions on info release – Gray list requires run-time consent (therefore consent clauses are moot if the parties are whitelisted)”. In addition, “The IdP should have a duty to determine the status of the RP wrt-63r3- therefore do not make it dependent upon a FA (though it could be)”.
  • NIST clarified that most security frameworks are written with language either you are in or you are out, if you are in you get everything and if you are out you get nothing. NIST wants to allow for more flexibility, that is why there is a separation between the white, gray and black.
  • Richard mentioned that one of the things that has been done, is to write a requirement and a list of things which would be good to have in a Federation Agreement. One of them is to define the conditions under which information may or may not be shared or transferred. NIST responded that a Federation Agreement can help define at least what the different aspects of your lists will be, Richard affirmed it.
  • About question 3, NIST asked if there is another way to sign an assertion, either asymmetric or symmetric cryptography? If there is, and if it effectively covers it, then sure. NIST said that audience restrictions through the addressable field only works if the RP checks it, which is why RPs are required to check it. This is effectively making sure that an RP can seat in the middle and replace that audience field with somebody else’s and pass the assertion as if it is coming from the IdP, when it did not. The trick with the language here is that if you are using symmetric crypto, then an RP is capable of creating assertions, but only assertions that are directed to itself. It was added as a response “Unable to execute a MITM attack”, and “Allow for any other crypto sig that is approved. This is the fundamental requirement”. NIST said that if there is anything with approved cryptography, that is the requirement, the others are details for specific sub-clauses of those.
  • NIST clarified what they mean by Federation, any exchange between the RP and the IdP, this is not specific to a Federation Agreement or Federation Controller. Ken argued that even in those two situations that they described, there has to be an Agreement between the parties. Ken asked if Facebook allows people to do that without an RP agreeing with Facebook terms? NIST responded that Facebook does not allow to do that, other IdPs do. Ken asked if it is without any terms and conditions. NIST affirmed it and stressed that it is covered in section 5.1.2 Dynamic Registration flow (https://pages.nist.gov/800-63-3/sp800-63c.html).
  • NIST responded in relation to question 4, that the registration being talked about here, is back to the question of “I would do business with this other party at all”. This is the introduction of an RP to an IdP before any user’s information gets passed, before even any user’s information is asked for. If an IdP does support this dynamic model, it is needed to publish the configuration. The added response was “RPs are the registrants – no rights of info transfer are granted by registering”. The only thing that registration means, is the ability to ask for information about a user, it does not necessarily mean you will get any information about any particular user, it can be confusing. About if the source of this configuration should be reliable, NIST said yes, it is a good idea, but that is accomplished in some very different ways. Richard answered that it does not mean they have to find the solution, but to state a requirement. NIST added that dynamic registration is more about trusting the RP, because RPs can still use dynamic registration and only trust a single IdP.
  • For question number 5, said NIST, the purpose of putting a requirement on the IdP is because it is releasing the information. These requirements were about the IdP releasing this information and not the RP using that information. Richard then clarified that this is just a simple transfer of information. It was added as a response that “Information of concern is to do with proofing and authentication”.
  • In relation to question 6, NIST explained that the authentication event, is the event at the IdP, and not the event as represented by the assertion in process by the IdP. Therefore, you have to log into the IdP for the IdP to know who you are and the IdP has to tell the RP when that happens. It is up to the RP to ultimately figure out whether if the user has re-authenticated freshly enough. The added response was “Authn event is at the IdP – driven by successful authentication not ‘any’; single authen event, nothing more”.
  • In question 7 it was added as a response “Intent is not to oblige to implement SSOut”. NIST explained that if you do implement SSOut or share session management, you can but it is not required. Richard said he is content with the clarification.
  • NIST responded on question 8 that previous versions of 63 had a holder of key, as far as they are aware, nobody implemented this correctly. NIST tries to define in 63C holder of key assertions in a way that they would be at least implementable and to clarify all the language of the previous assertions. The assertion has to have some notion of a key in the assertion and therefore protected by the signature from the IdP.
  • NIST answered in question 9 that there are a number of things that are in 63C like the requirement for the authentication time and so forth. They are there in order to support requirements that come from 63B in this case. Ken asked that if someone had a 63A approval, does that automatically gives them a 63C approval for IdPs? NIST responded no. Ken clarified that it was the essence of the question. Richard pointed out that this question was raised because of the requirement in 63C#0110. It was added as a response “No-63C are essentially additional for Fedtg”.
  • Question 10 - NIST continued that this is an important question, because this thinking is what drove a lot of the development of version 3 here. Richard remarked that there is a requirement right up front in section 4, which says that any assertion and any use of an assertion shall be conducted at the lowest level of any of these elements. NIST argued that it does not mean that if it is IAL1, that does not mean that it is treated as IAL. It was added as a response “Earlier reqt address proxies specifically”. Richard asked would not you then be enforcing best practice? NIST answered no, for privacy reasons you may not want to disclose the level of proofing on an individual user. Even the fact that IAL3 proofing has been done on someone, without you releasing their attributes, gets you more information about the user than you might be willing to release. That is why it is a SHOULD, the other reason is that it is possible that you have got a case like they had mentioned before; where the Federation Agreement says this IdP only has users at IAL2 and AAL2 and that is all that it ever does, and so you will not be told what every assertion is doing all the time. The response was added as “Being not ‘SHALL’ removes the obligation to reveal the proofing / authn level D22”, also “May be a default AL, therefore not spcfd”.
  • Question 11. NIST explained it is driven by OpenID Connect practice intended to enforce specific notification that the user has been authenticated. What this requirement is saying is that just because someone can call the user information at point just because the token is still valid, that does not mean that the user is correctly logged in. To be logged in there has to be handed an assertion that specifically says this user is logged in.
  • NIST provided the link to the Spec on Open ID Dynamic Registration flow: https://openid.net/specs/openid-connect-registration-1_0.html
  • Richard thanked NIST for giving the time to answer the questions. Colin also thanked NIST.
  • Ken remarked that the clarifications were fantastic.

...