Assurance

["Jones, Mark B" <>]

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
>