> -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:[email protected]] > Sent: Friday, December 09, 2011 12:14 AM > To: ext Jim Schaad; [email protected] > Subject: RE: [abfab] Levels of Assurence > > 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".)
I think that this may be required in both directions. That is the RP may need to tell the IdP what it wants as well. I completely agree that there is going to need to be an OOB agreement about what the values mean. But I still potentially want to do the selection process. > > 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
