Assurance

["Jones, Mark B" <>]

Tom,
Are you contradicting Tom and saying that identity proofing is in fact 
required?

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Tom Barton
Sent: Friday, November 30, 2012 9:47 AM
To: 

Subject: Re: [Assurance] silver, 2-factor, password requirements

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