Assurance

[Tom Barton <>]

Recall that Level of Assurance is one way to mitigate the risk of an authentication failure. 
InCommon Bronze & Silver are profiles of how to do so when all elements underlying a given 
authentication instance are the responsibility of a single administration, the IdP Organization.

The federation manager use case differs in that the RP org - InCommon - issues authentication 
credentials and member/customer orgs bind them to actual persons. This does not mean that there 
is no concern over proofing of the identities of these persons, only that that's the concern of 
the member org and not InCommon. In fact InCommon's process requires the Executive Contact 
(usually a CIO) to provide InCommon with out of band contact info for each Site Administrator, 
which is a product of pretty good identity proofing - the CIO knows personally who they are.

So it's a misunderstanding to say that identity proofing is not important to mitigating risk 
with the federation manager, and in fact InCommon's process requires good identity proofing. But 
it does not specify how that is to be accomplished. That's left to the member org, and I guess 
there's a usually valid assumption that the member org's CIO will be careful in assigning the 
Site Administrator role to clearly identified, and trustworthy, people.

Tom

On 11/30/2012 8:20 AM, Farmer, Jacob wrote:
> I don't think they are veering away from the standard.
>
> The SP made a risk AND business assessment, I think (although I may be 
> putting words in Toms mouth).
>
>  From a business perspective, Silver is only deployed at one site.  My guess 
> is they can move much more quickly if they don't wait for broader silver 
> adoption.
>
>  From a technical perspective, they decided they need multifactor and don't 
> care about identity proofing, so Silver doesn't fit anyway.
>
> I think this is exactly what we want SPs to do.  It saves both parties time 
> -- it saves the IdP from vetting users for Silver who don't really need it, 
> and it provides the SP with the flexibility to target the things they think 
> are really important.
>
> If enough share Tom's use case, maybe InC needs a third profile?  I have 
> always assumed we don't stop at just the NIST levels.
>
> Jacob
>
> =========================
> Jacob Farmer
> Identity Management Systems
> (812) 856-0186
>
> On Nov 30, 2012, at 9:11 AM, "Jones, Mark B" 
> <>
>  wrote:
>
> > There is no level 3 InCommon LoA and bronze/silver are essentially the same as 
> > NIST 1 & 2.  Why veer away from the standard at level 3?
> >
> > Sent from my iPhone
> >
> > On Nov 30, 2012, at 7:47 AM, "Michael R. Gettes" 
> > <>
> >  wrote:
> >
> > > We are InCommon.  We should be embracing InCommon LoA.
> > >
> > > /mrg
> > >
> > > On Nov 29, 2012, at 23:00, "Jones, Mark B" 
> > > <>
> > > wrote:
> > >
> > > > So it sounds like you have determined that NIST LoA 2 / Silver is not 
> > > > sufficient, but you seem reluctant to fully embrace LoA 3.
> > > >
> > > > The risk assessment seems to closely follow NIST guidance.  Why not embrace 
> > > > LoA 3 as defined by 800-63?
> > > >
> > > > -----Original Message-----
> > > > From: 
> > > >
> > > >  
> > > > [mailto:]
> > > >  On Behalf Of Tom Scavo
> > > > Sent: Thursday, November 29, 2012 9:39 PM
> > > > To: 
> > > >
> > > > Subject: Re: [Assurance] silver, 2-factor, password requirements
> > > >
> > > >
> > > >
> > > > > The risk assessment concludes that the "Federation Manager is a
> > > > > moderate-impact system" and it references the "Potential Impact
> > > > > Categories for Authentication Errors" table from OMB M-04-04, but does
> > > > > not say which LoA was identified.  It looks to me that
> > > > > "moderate-impact" could land it in LoA 2 or LoA 3 depending on which
> > > > > risk categories earned the system as a whole the moderate-impact
> > > > > designation.  Did a "required LoA" result from this risk assessment?
> > > > Thanks for reading through this, Mark. There are probably as many interpretations of 
> > > > the risk assessment as there are readers. That said, focus for a moment on the first 
> > > > row in the table where the impact level is "equal to the impact level of the IdP's 
> > > > highest assurance profile." In other words, the entire trust fabric of the 
> > > > Federation depends on the integrity of the IdP signing certificates in metadata. 
> > > > Doesn't matter how much effort participants put into their IdP deployments, if a bad 
> > > > guy can impersonate one of your site admins, it's game over.
> > > >
> > > > I conclude from that simple analysis that we not only need two-factor 
> > > > authentication but we also need other compensating controls as well, at least 
> > > > for high-risk elements in metadata (such as IdP certificates and endpoints).
> > > >
> > > > Tom