The IAAF uses IdP. I vote for consistency with that.
David
On Tue, 2013-09-24 at 00:04 +0000, Eric Goodman wrote:
And one more thing:
We should standardize on IDP vs. IdP. I definitely use both…
--- Eric
From: [mailto:] On Behalf Of Eric Goodman
Sent: Monday, September 23, 2013 5:02 PM
To:
Subject: [AD-Assurance] RE: Edits to AD Cookbook
Two other comments:
· I went back and forth, and ended up using “Authentication Credentials” in many cases where I could have said “Passwords”. My thinking in doing this is that to prevent man-in-the-middle attacks, it’s just as important to block access to one-time passwords as to block user-selected static passwords. As you read the doc, consider whether you like my choices here.
· If you read the “comparison” version, be mindful of the wiki-markup. In some cases I “added” sections that start with a dash “-“, those are areas where I actually changed the text to strikeout (probably combined with some previous minor edit).
Of course, any other corrections, comments, etc. are welcomed, the ones I list are just the ones I focused on during my editing.
--- Eric
From: [] On Behalf Of Eric Goodman
Sent: Monday, September 23, 2013 4:56 PM
To:
Subject: [AD-Assurance] Edits to AD Cookbook
Well, as per my usual, the edits ended up being a bit beefier than I expected.
· Scope
o Added a note about SSL/TLS and SHA1 in the scope section to say that we assume whatever SSL/TLS you are using is still an approved method.
· Interpretations
o 4.2.3.6.2
§ Explicitly state that this section covers use of authentication credentials (passwords) by any app (not just the IDP) against the IDP Verifier.
· Was implied in earlier drafts (“secrets that can be used to directly authenticate to the IDP…”), but was not as explicitly called out.
§ Updated the footnotes as per AAC request.
o 4.2.3.6.3
§ Added this section.
§ Please carefully review interpretations for this section and preceding (4.2.3.6.2). They are very explicit re: categorizing authentication traffic each addresses. I think the categorization is correct, but in getting explicit, I entered territory we hadn’t fully discussed in the past. As written, these interpretations are key for distinguishing when a Protected Channel is required, vs authentication methods that generally “minimize risk”.
o 4.2.5.1/2
§ Modified (clarified) the AAC’s suggested wording (my additions in bold):
· "This section refers specifically to traffic between the Subject and the IdP, the IdP's Verifier, and/or a relying party as part of an IDP authentication/assertion event. All other traffic between the subject and to the AD DS is beyond the scope of 4.2.5.2."
· AAC’s language still said it pertained to “traffic between the Subject and the IdP’s Verifier”, which other comments indicated was too broad of a scope.
§ Made a similar change to both 4.2.5.1 and .2. (This constituted an addition in .1).
§ Removed (strikeout for now) the “impractical” in this section, as with the rescoping from the AAC, the definition was irrelevant. Moved much of the language in this section to 4.2.3.6.2/3
· Configuration recommendations
o 4.2.3.6.2
§ I think I added language to make it clearer that we recommend prompting user directly for authentication credentials, and not SPNEGO-like methods (as well as the “why”)
§ Added the requirement that all non-IDP applications that handle authentication credentials directly must use protected channels as well (pre the clarification noted in “interpretation”, above); i.e., LDAPS or equivalent for talking to AD DS.
§ Clarified that while IDP and web apps that prompt for user passwords must use HTTPS or equivalent on “front end”, that’s not an AD DS requirement (it’s web app security) so isn’t covered here.
o 4.2.3.6.3
§ Moved language re LM and NTLMv1 disabling here.
§ Called out that NTLMv2 and Kerberos are fine given our other recommendations.
o 4.2.5.1/2
§ Moved most language from 4.2.5.1/2 to 4.2.3.6.2/3.
§ Stated that if IDP uses direct entry of user authn credentials, no extra requirements here beyond those for 4.2.3.6.2
o Renamed “Monitor and Mitigate” to be a “Compensating Controls Statement” (not an Alternative Means)
o Removed “Alternative Means for use of Kerberos” section [shows as strikeout]
o Removed “Time Skew” for Kerberos discussion [shows as strikeout]
o Removed discussion of 4.2.3.5 (Bronze) [shows as strikeout]
· Management Assertions
o Much of the same…
o Moved assertions from 4.2.5.1/2 to 4.2.3.6.2/3
o Removed much of the language in sections 4.2.5.1/2 (using strikeout), and referenced 4.2.3.6.2 instead.
o Added a note in 4.2.8.1 re the one configuration we specifically recommend (to enforce AES for DC replication)
I’m sure I made other edits that I’m not catching here. Version 68 is the version that was up previous to my edits, so if you want to see everything I did, look at this URL:
https://spaces.internet2.edu/pages/diffpagesbyversion.action?pageId=38668089&originalVersion=68&revisedVersion=76
--- Eric
|
