1. Appropriate Access InCommon Identity Assurance Profiles
David L. Wasley
Campus Architecture and Middleware Planning workshop
February 2008

2. Outline Access and Identity Identity Assurance
InCommon Identity Assurance Profiles

3. Access and Identity
Modern distributed IT environments separate identity and access management
“single sign on” binds an identifier to a physical person
Necessary information about that person is given to resource access management systems that need it
autheNtication vs authoriZation
Why identity is important to security
Security is not just about building moats & walls
You’d like to locate the person who does a bad thing
Strong identity assurance also should help protect people against ID theft

4. Access and Identity
Modern distributed IT environments separate identity and access management
“single sign on” binds an identifier to a physical person
Necessary information about that person is given to resource access management systems that need it
autheNtication vs authoriZation
Why identity is important to security
Security is not just about building moats & walls
You’d like to locate the person who does a bad thing
Strong identity assurance also should help protect people against ID theft

5. Access Models Authorization determines access to resources
Policy + process + mechanism + enforcement ...
Access Control List of specific persons
Requires specific identifier for each user
Access rules, based on group attributes
E.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

6. Identity Model Identity 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 involved
Identity Subject is a person who wants to assert an ID
Relying Party, e.g. Service Provider, trusts identity information received from an Identity Provider
Identity Provider agrees to support identity Subjects by maintaining a database or directory of reliable ID data
Each party must trust the others

7. Identity Model (cont.)
Digital credential is bound to a physical person
May, but need not, contain some identity information
Different credential technologies for different purposes
Binding achieved through a registration process
RA process must find existing record or create a new one
Credential S/N is index to Identity Mgmt DB
Credential S/N need not be same as Subject identifier
Relying Party uses IdM DB information as part of decision about access to services or resources
How good is a Provider’s assertion of an identity?

8. Identity Assurance How reliable does an identity need to be?
Depends on what’s at stake, consequences & mitigations
Relying 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

9. Identity Assurance Projects
NIST
Federal eAuthentication
See also HSPD-12 and NIST FIPS 201
Liberty Alliance Identity Assurance Framework
RealID “Final Rule”
FBI National Biometrics Database
InCommon Verified Identity Profiles ‡
“Bronze”, “Silver”, … profiles
‡ Temporary name

10. InCommon Identity Assurance Profiles
Now in DRAFT and may change …
Structured sets of requirements intended to satisfy management of access to general classes of resources
Not necessarily hierarchical
Hopefully limited in number(!)
First two defined to be equivalent to eAuth
“Bronze” == eAuth levels 1
“Silver” == eAuth level 2

11. Identity Assurance Assessment Framework
Business, Policy and Operational Factors
Registration and Identity Proofing
Digital Electronic Credential Technology
Digital Electronic Credential Issuance and Management
Security and Management of Authentication Events
Identity Information Management
Identity Assertion and Content
Technical Environment

12. InCommon “Silver” Profile
Business, Policy and Operational Factors
Established legal entity •
Designated authority for IdMS & IdP •
General Disclosures to identity Subjects •
Documentation of policies & practices
Appropriate staffing
Subcontracts
Helpdesk
Audit of IdMS operations
Risk Management plan
Logging of operation events

13. InCommon “Silver” (cont.)
Registration and Identity Proofing
Identity Verification Process disclosure
Retain records of Id documents
And one or more of:
Confirmed relationship with the organization
In-person proofing
Remote proofing
Digital Electronic Credential Technology
Unique credential identifier •
Subject modifiable shared secret •
Strong resistance to guessing shared secret *

14. 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

15. 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 *

16. InCommon “Silver” (cont.)
Identity Information Management
Identity status management
Identity Assertion and Content
eduPerson attributes • (†)
Identity Assertion Qualifier • (†)
Cryptographic security •
Technical Environment
Configuration Management
Network Security
Physical Security
Continuity of Operations (†)

17. Implementation Notify InCommon of intention to qualify
Assessment by independent (internal) auditor
Auditor writes summary letter for InCommon
Execute Addendum to Participation Agreement
InCommon adds Identity Assurance Qualifier(s) to IdP metadata
IdP then may include IAQ(s) in assertions
Is responsible to ensure they are appropriate
Technical implementation yet to be determined

18. Use of InCommon IAQs IAQ represents a profile, not a level
A given IdP can support multiple profiles
IdP may assert InCommon IAQ(s) only if assigned to it by InCommon
Identity 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

19. Further Information David Wasley <dlwasley@earthlink.net>
InCommon Identity Assurance Profiles
David Wasley
NIST
Liberty Alliance Identity Assurance Framework
RealID
FBI biometrics database