Hi Jim, Here is the challenge with the level of assurance concept: they are not just a matter of how the user was authenticated but the different levels are reflected in the overall system design.
As such, it is not sufficient to just communicate from the IdP to the RP that a specific transaction is, for example, LoA 4. The RP should "know" that since the entire system has to be designed in such a way and the IdP and the RP are likely to have an agreement (out of band) to ensure the RP that the IdP does actually what it is claiming to do. (You may call this "trust relationship".) Having said that NIST SP 800-63 (as it is available today; revision pending) has a serious shortcoming. It focuses with the LoA concept heavily on identity proofing and authentication but does not consider the attribute assurance and privacy concepts that are associated with the release of data. In a complete system, like we are working on in ABFAB, this is very relevant. So, while I like NIST SP 800-63 a lot I am eagerly waiting for an update of their document (which should have been out there already) to see whether we can reference something more complete for the purpose of our discussion. As far as the conveyance of the LoA in RADIUS / Diameter / SAML / etc. concerns I am less convinced about the value. Just yesterday I suggested to the OAuth working group that the different levels of assurance could serve as a good way to describe security properties of a system. See my mail here: http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html Ciao Hannes > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of ext Jim Schaad > Sent: Friday, December 09, 2011 9:28 AM > To: [email protected] > Subject: Re: [abfab] Levels of Assurence > > While reading my back log of messages, I discovered the following text: > > There is no mention in this section that there may be multiple IdPs for > a > single realm that could be used by the RP and the selection of which > IdP it > wants to use is going to be based on the set of attributes that the RP > needs > or a level of authentication that is required by the RP (see [sp800- > 63-1] > NIST SP 800-63-1 "Electronic Authentication Guideline", December 2008 > as > examples). > > Is this a real thing and is this something that needs to be handled by > having separate AAA proxy and IdP servers. If so does this mean that > we > need to look at that interface more closely? > > Jim > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of Jim Schaad > > Sent: Thursday, December 08, 2011 9:01 PM > > To: [email protected] > > Subject: [abfab] Levels of Assurence > > > > As part of the plasma work, one of the things that has been stated as > a > > requirement is that the RP can insist on a level of assurance for the > client to > > be authenticated with. At this point in process, I don't care about > the > > specifics of how the LOA is actually specified, but I am interested > in how > the > > data specifying this would be conveyed. > > > > At this point I can see two different methods to convey the > information: > > > > 1. The data is carried in a RADIUS attribute. Such an attribute may > already > > exist, I have not done any type of exhaustive search, and just needs > to be > > documented. I can see other access points wanting to require an LOA > in > just > > the straight RADIUS AAA world. > > > > 2. The data could be carried in a SAML request. As long as the IdP > and > > the AAA Radius server are co-existent this would not be a problem. > But it > > does mean that the SAML request now needs to be parsed for some > > information before the EAP processes are run in order to determine > which > > EAP methods are acceptable to the RP. > > > > Jim > > > > > > _______________________________________________ > > abfab mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/abfab _______________________________________________ abfab mailing list [email protected] https://www.ietf.org/mailman/listinfo/abfab
