Appropriate Access

InCommon Identity Assurance Profiles

David L. Wasley

Campus Architecture and Middleware Planning workshop

February 2008

Outline

Access and IdentityIdentity AssuranceInCommon Identity Assurance Profiles

Access and IdentityModern distributed IT environments separate identity and access management

“single sign on” binds an identifier to a physical personNecessary information about that person is given to resource access management systems that need itautheNtication vs authoriZation

Why identity is important to securitySecurity is not just about building moats & wallsYou’d like to locate the person who does a bad thing

Strong identity assurance also should help protect people against ID theft

Access and IdentityModern distributed IT environments separate identity and access management

“single sign on” binds an identifier to a physical personNecessary information about that person is given to resource access management systems that need itautheNtication vs authoriZation

Why identity is important to securitySecurity is not just about building moats & wallsYou’d like to locate the person who does a bad thing

Strong identity assurance also should help protect people against ID theft

Access ModelsAuthorization determines access to resources

Policy + process + mechanism + enforcement ...

Access Control List of specific personsRequires specific identifier for each user

Access rules, based on group attributesE.g., any “member of the campus community”

Access may also be based on parameters, e.g., resource availability, time of day, location of user, etc...Access decision is made by resource manager

Identity ModelIdentity is the set of information about a person

Unique attributes, e.g., biometric, U.S. President, ...Group attributes, e.g., student, male, Joe Smith, ...Pseudonymous attributes, e.g., the same person as before

Three parties involvedIdentity Subject is a person who wants to assert an IDRelying Party, e.g. Service Provider, trusts identity information received from an Identity ProviderIdentity Provider agrees to support identity Subjects by maintaining a database or directory of reliable ID data

Each party must trust the others

Identity Model (cont.)Digital credential is bound to a physical person

May, but need not, contain some identity information

Different credential technologies for different purposesBinding achieved through a registration processRA process must find existing record or create a new one

Credential S/N is index to Identity Mgmt DBCredential S/N need not be same as Subject identifier

Relying Party uses IdM DB information as part of decision about access to services or resourcesHow good is a Provider’s assertion of an identity?

Identity AssuranceHow reliable does an identity need to be?

Depends on what’s at stake, consequences & mitigationsRelying Party needs to do the risk analysis

How much can a RP trust an identity assertion?What identity?Does the RP trust the IdP as an organization?How well was identity established and maintained?How (and when) did the Subject authenticate to the IdP?If something goes wrong, can the Subject be found?

Nothing is absolute; it’s all degrees of certainty

Identity Assurance Projects

NIST 800-63Federal eAuthenticationSee also HSPD-12 and NIST FIPS 201

Liberty Alliance Identity Assurance FrameworkRealID “Final Rule”FBI National Biometrics DatabaseInCommon Verified Identity Profiles ‡

“Bronze”, “Silver”, … profiles

‡ Temporary name

InCommon Identity Assurance Profiles

Now in DRAFT and may change … Structured sets of requirements intended to satisfy management of access to general classes of resourcesNot necessarily hierarchicalHopefully limited in number(!)First two defined to be equivalent to eAuth

“Bronze” == eAuth levels 1 “Silver” == eAuth level 2

Identity Assurance Assessment FrameworkBusiness, Policy and Operational FactorsRegistration and Identity ProofingDigital Electronic Credential TechnologyDigital Electronic Credential Issuance and ManagementSecurity and Management of Authentication EventsIdentity Information ManagementIdentity Assertion and ContentTechnical Environment

InCommon “Silver” Profile

Business, Policy and Operational FactorsEstablished legal entity •Designated authority for IdMS & IdP •General Disclosures to identity Subjects •Documentation of policies & practices Appropriate staffing Subcontracts Helpdesk Audit of IdMS operationsRisk Management plan Logging of operation events

InCommon “Silver” (cont.) Registration and Identity Proofing

Identity Verification Process disclosureRetain records of Id documents

And one or more of: Confirmed relationship with the organizationIn-person proofing Remote proofing

Digital Electronic Credential Technology

Unique credential identifier •Subject modifiable shared secret •

Strong resistance to guessing shared secret *

InCommon “Silver” (cont.)Credential Issuance and Management

Unique Subject identifier •

Credential status •

Confirmation of delivery

Credential verification

Suspected credential compromise (†)

Credential revocation† indicates an InCommon variant from the NIST recommendations

InCommon “Silver” (cont.)Security and Management of Authentication Events

End-to-end secure communications *

Proof of control •

Session authentication •

Stored secrets •

Protected secrets

Mitigate risk of sharing credentials

Threat protection *

Authentication protocols *

InCommon “Silver” (cont.)Identity Information Management

Identity status management

Identity Assertion and ContenteduPerson attributes • (†)Identity Assertion Qualifier • (†)Cryptographic security •

Technical EnvironmentConfiguration ManagementNetwork SecurityPhysical SecurityContinuity of Operations (†)

ImplementationNotify InCommon of intention to qualifyAssessment by independent (internal) auditor

Auditor writes summary letter for InCommon

Execute Addendum to Participation AgreementInCommon adds Identity Assurance Qualifier(s) to IdP metadataIdP then may include IAQ(s) in assertions

Is responsible to ensure they are appropriateTechnical implementation yet to be determined

Use of InCommon IAQsIAQ represents a profile, not a levelA given IdP can support multiple profilesIdP may assert InCommon IAQ(s) only if assigned to it by InCommonIdentity assertion may contain multiple IAQs

E.g., “Bronze” or both “Silver” and “Bronze”Avoids implying hierarchy and allows for additions with minimal disruption

Relying Party looks for an IAQ it will accept

Further Information

InCommon Identity Assurance Profiles

David Wasley <dlwasley@earthlink.net>NIST 800-63

http://csrc.nist.gov/publications/PubsSPs.html

Liberty Alliance Identity Assurance Framework

http://www.projectliberty.org/liberty/strategic_initiatives/identity_assurance

RealID http://www.dhs.gov/xprevprot/programs/gc_1200062053842.sht

FBI biometrics databasehttp://www.washingtonpost.com/wp-dyn/content/article/2007/12/21/AR2007122102544.html