Assurance

["Michael W. Brogan" <>]

From the InCommon IAP v1.1 section 4.2.3.4 Stored Authentication Secrets (Bronze and Silver) (p. 8)

 

From NIST 800-63-1 section 7.3 Token and Credential Management Assurance Levels:

- 7.3.1.1 Level 1 Credential Storage (p. 62)

- 7.3.1.2 Level 2 Credential Storage (p. 62)

 

--Michael

 

From: [mailto:] On Behalf Of Farmer, Jacob
Sent: Tuesday, November 13, 2012 10:32 AM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

Michael,

 

Just to be sure we’re all looking in the same place, which section are you referring to?

 

Jacob

 

From: [] On Behalf Of Michael W. Brogan
Sent: Tuesday, November 13, 2012 1:01 PM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

LOA 1 stipulates ACLs and no plain text passwords while LOA 2 stipulates ACLs plus NIST-approved hashing or NIST-approved encryption for Credential Storage. I can see how AD passwords could meet the bar for LOA 1 while 2-factor might be required for AD and LOA 2.

 

The corresponding InCommon IAP section is essentially the same as LOA 2, but it applies to both Bronze and Silver. It seems the bar for Bronze is higher than LOA 1 for Credential Storage and that 2-factor might therefore be required for AD even at the Bronze level. I hadn’t noticed this difference between Bronze and LOA 1 before. Now I’m curious why the IAP is written this way.

 

--Michael

 

From: [] On Behalf Of Ron Thielen
Sent: Tuesday, November 13, 2012 9:31 AM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

It doesn’t, however, mean that there isn’t a path forward that doesn’t involve two factor… just that we shouldn’t expect the government to have either magic bullets or sympathy when it comes to dealing with AD.

 

Ron

 

From: [] On Behalf Of Farmer, Jacob
Sent: Tuesday, November 13, 2012 11:23 AM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

And I think this is a reasonable response.  I think it’s very challenging to meet the spirit (and often times the letter) otherwise.

 

Jacob

 

From: [] On Behalf Of Ron Thielen
Sent: Tuesday, November 13, 2012 12:21 PM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

However, when I asked a good friend of mine who was a CIO at a large government organization with which many of us are engaged how they deal with the issues raised by Active Directory when they need LOA 2, his answer was “two factor.”

 

Ron

 

From: [] On Behalf Of Brian Arkills
Sent: Tuesday, November 13, 2012 10:56 AM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

Just a minor point, but I think it may be useful in your discussions with the FICAM folks--I don't see the Active Directory component of this challenge as unique to higher education. Active Directory has a very wide adoption rate regardless of the sector--with several reports indicating that it has in excess of 90% adoption. Given the ubiquitousness of AD, this is an almost assuredly an issue for FICAM (and Microsoft) whether they are dealing with InCommon or someone else.

 

 

From: [] On Behalf Of Michael W. Brogan
Sent: Monday, November 12, 2012 2:26 PM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

Ann,

 

Thanks for the news update re: “industry standard” and “approved” crypto for IAP v1.2. I’ll be anxious to hear how that turns out.

 

You mentioned AD and the Silver Cookbook. AD is one  of the products I had in mind when I originally posed my question. With AD we’re not quite sure how to talk our way around requirements such as IAP 4.2.3.4 Stored Authentication Secrets. It seems a stretch to say the use of unsalted MD4  hashes for passwords in AD is “industry standard” and we don’t have enough understanding about how the hashes are subsequently encrypted/decrypted to judge whether that would be “industry standard” or not.

 

The new definition for “approved” and further revisions to the Silver Cookbook would be helpful to many I’m sure.

 

--Michael

 

From: [] On Behalf Of Roy, Nicholas S
Sent: Monday, November 12, 2012 12:59 PM
To:
Subject: RE: [Assurance] Meaning of "industry standard" crypto

 

This is excellent news, thanks Ann,

 

Nick

 

From: [] On Behalf Of Michael R. Gettes
Sent: Monday, November 12, 2012 2:45 PM
To: <>
Subject: Re: [Assurance] Meaning of "industry standard" crypto

 

Aha!  Thanks - that really helps clarify your earlier remarks.

 

/mrg

 

On Nov 12, 2012, at 15:26, Ann West <>

 wrote:

 

Michael

 

It means that in 1.2, FICAM is asking us to replace the term industry standard with approved as defined in 800-63. 

 

We are responding, sure we can use  approved, but we'd like to provide our own definition that accommodates HE deployments.

 

Once we are finished with the negotiations, I can tell you what the spec will say. ;)

 

Ann

---

Hi Ann,

 

does this mean "industry standard" will be removed from the 1.2 IAP post FICAM negotiations?  I ask because you use the language of "approved" and "comparable means" and Mr. Brogan was inquiring about "Industry Standard".  They could be loosely interpreted as different or the same, depending on who is doing the interpreting.

 

/mrg

 

On Nov 12, 2012, at 11:57, Ann West <> wrote:

 

Hi Michael,

 

A very good question and one, it turns out, that will be answered  very soon.

 

As you know, we're in discussions with FICAM about the approval of our 1.2 Profile and Framework documents. One of their requests is to change this term to "approved"  and define it the same as in 800-63-1:

 

Federal Information Processing Standard (FIPS) approved or NIST recommended. An algorithm or technique that is either 1) specified in a 

FIPS or NIST Recommendation, or 2) adopted in a FIPS or NIST Recommendation.

 

This poses some issues for HE, most notably the lack of support of technologies used with MS Active Directory. As you know, per FICAM our program needs to be comparable to 800-63, but it doesn't have to follow it exactly. This is one place where HE would be at substantial disadvantage if we were to accept the wording as-is. As a result, we are recommending the following as the definition for "approved:" 

 

Any implementation of an algorithm or techniques specified in a FIPS standard or NIST recommendation, or any algorithm or technique that conforms to a practice identified by InCommon as approved for specified IAPs.

 

As you may remember, Nick Roy et al developed the AD Silver cookbook to help schools using AD comply with Silver. We're proposing to formalize this process  with the resulting documents deemed as approved alternatives (or comparable means).

 

Best regards,

Ann

 

---

There are several places in IAP v1.1 where “industry standard” crypto is specified. Having a reasonable understanding of the term seems important when making statements about compliance to the IAP.

 

In local discussions I’ve encountered a range of interpretations.

 

One interpretation states that any crypto used in a widely deployed product is “industry standard” because the broad installation base of the product makes it a de facto industry standard.

 

Another interpretation is that “industry standard” means the crypto meets some standard for resistance against current threats that is certified by a government agency (e.g. NIST) or is generally deemed of equivalent strength. Algorithms that have been deprecated for years would be excluded from the “industry standard” list. IAP v1.0 specified NIST-approved crypto but this was changed to “industry standard” in v1.1.  I’ve assumed the goal behind this change was to maintain cryptographic strength but to provide implementers more flexibility in choice of algorithms. Was that the case?

 

Anyone want to offer interpretations of “industry standard” crypto from their own campus assurance work?

 

Michael W. Brogan

University of Washington