Questions for IdPs

Suggest for each area that ask IdPs to rate themselves:

• Already implemented.
• Could implement with small amount of manpower.
• Could implement with significant manpower.
• Could implement with low-cost system changes.
• Could implement with high-cost system changes.
• Would not get approval to make this change (please explain why).

Online survey: http://goo.gl/forms/vprx6EpNSO

1.Identity/account concept

• Account for an individual person (i.e. there are no shared accounts)?
• If shared: possible to distinguish between individual and shared accounts?
• If individual account: traceable? Are identifiers persistent?
• Which unique identifier?

2.Registration and proof of identity

• What identity vetting process? Face-to-face or different?
• Documented?
• Different validation between student, staff or faculty members? How?

3.Online authentication

• Passwords?
• Passwords with quality guarantees? What kind of guarantees?
• Two factor authentication?
• If yes, which second factor? Is the eID used?
• If no two factor authentication: How big would be the cost to provide two factor authentication?

4.Freshness of user data

• Are accounts closed as an individual departs? How promptly?
• Is the eduPersonAffiliation value updated as an individual departs? How promptly?

5.Step-up authentication

Step-up authentication means that the user first authenticates with a password, and subsequently with a second factor (such as by an one-time password delivered to his/her cellphone)

• Would you like to have GÉANT/your NREN to run such a service (if it costs/if it doesn't cost)?
• How many users would need such a service?

6. Provenance and level of assurance

• Do you use a level of assurance? Which one?
• Is the LoA self-asserted?
• Is everything documented?
• If not documented: which costs would that be?
• Internal audits?
• External audits?
• If no audits: costs for that?
• How many users need a (higher) level of assurance?
• Identity Management Practise Statement?

Results

Survey

IdPs

Excel

Participants:

• 3x DFN-AAI
• 1x RENATER
• 1x фEDUrus, Kalmar, SIR, UKfederation, InCommon, IDEM, Tuakiri, AAF, Surfconext, edugain, SAFIRE
• 1x - (GEANT IdP)
• 5x Small amount of manpower
• 1x Small to medium amount of manpower
• 4x < 50 000 user
• 1x < 10 000
• 1x < 100

1.Identity/account concept

• Account for an individual person (i.e. there are no shared accounts)?
  • 5x Already implemented
  • 1x Could implement with significant manpower.
• If individual account: traceable? Are identifiers persistent?
  • 4x Already implemented
  • 1x Could implement with significant manpower.
• Which unique identifier?

  • uid for CASsified applications, eppn for shib applications

  • ePPN, ePTID
  • CN
  • persistentID

2.Registration and proof of identity

• Identity vetting process?
  
  • 3x Already implemented
  • 1x Could implement with significant manpower.
  • 1x Would not get approval to make this change: significant manpower needed
• What identity vetting process?

  • by student department for student, by human resources department for staff

  • Implementation for students (Student Administration) and regular employees (Personal Administration). Not for short- or longterm guests, external doctorstudents, etc.

  • with use of the identity card of the person
• Documented?
  • 3x Already implemented
  • 2x Could implement with small amount of manpower.
  • 1x Could implement with significant manpower.
• Different validation between student, staff or faculty members? How?
  • All besides of one IdP

  • students: Student Administration, regular employees: Personal Administration

  • Students are vetted on enrollment, Staff is introduced in person.
  • We have guest lectures from all over the world. For them it's not possible to identify personally with their identity card. Here we accept other forms of identification.
  • 1x no ID check at all

3.Online authentication

• Passwords with quality guarantees?
  
  • 4x Already implemented
  • 2x Could implement with significant manpower.
• What kind of guarantees?

  • [password_quality]  policies = builtin:minimum-length builtin:character-class builtin:external-check   min_length = 8   min_classes = 2    external_program = /usr/bin/heimdal-strength

  • Minimum length 14 characters.
  • Special production rules on password reset. Passwort resetting mandatory.
  • Passwords must be 8-14 chars, containing at least chars from three of the following four groups: uppercase, lowercase, numeral, punctuation. A dictionary check must be passed (cracklib). Introduction of password expiration date, password history and two-factor-authentication is planned.

  • minimum length, use of minimum number of 2 special characters forced

• Two factor authentication?
  • 3x Could implement with high-cost system changes.
  • 2x Could implement with significant manpower.
  • 1x Could implement with low-cost system changes.

4.Freshness of user data

• Are accounts closed as an individual departs?
  
  • 4x Already implemented
  • 2x Could implement with small amount of manpower.
• How promptly?
  • 2x >= 6 months
  • 2x < 6 months (1x DFN-AAI, 1x GEANT IdP)
  • 1x < 2 months (DFN-AAI)
  • 1x < 4 weeks (DFN-AAI)
• Is the eduPersonAffiliation value updated as an individual departs?
  
  • 4x Already implemented
  • 2x Could implement with small amount of manpower.
• How promptly?
  • 2x >= 6 months
  • 2x < 6 months (1x DFN-AAI, 1x GEANT IdP)
  • 2x < 2 weeks (DFN-AAI)

5.Step-up authentication

Step-up authentication means that the user first authenticates with a password, and subsequently with a second factor (such as by an one-time password delivered to his/her cellphone)

• Would you like to have GÉANT/your NREN to run such a service (if it costs/if it doesn't cost)?
  • 2x Yes, but only if it costs no money at all
  • 1x Yes, but only if costs little money
  • 1x Yes, even if it costs
  • 2x No, because we have no use case for it
• How many users would need such a service?
  • 5x >500
  • 1x <= 100 (1x Yes, even if it costs)

6. Provenance and level of assurance

• Do you use a level of assurance?
  
  • 5x Could implement with significant manpower.
  • 1x Could implement with high-cost system changes.
• Is everything documented?
  • 2x Already implemented (thank you DFN-AAI)
  • 1x Could implement with small amount of manpower. (also DFN-AAI)
  • 3x Could implement with significant manpower.
• Identity Management Practise Statement?
  • 1x Already implemented
  • 2x Could implement with small amount of manpower.
  • 3x Could implement with significant manpower.
• Incident Response Process?
  • 1x Already implemented
  • 3x Could implement with small amount of manpower.
  • 2x Could implement with significant manpower.
• Audits?
  • 1x Already implemented - internal audits
  • 1x Could implement with small amount of manpower.
  • 4x Could implement with significant manpower.

IGTF

1. Identity/account concept

   • Account for an individual person (i.e. there are no shared accounts)? - There are no shared credentials or accounts by policy - although the policies allow for specific "machine-to-machine" authentication credentials ("Robots"). For these Robot certificates, they are either uniquely tied to a named individual person (effectively giving that person a secondary credential); linked to a named networked entity (by FQDN); or assigned to group of people with compensatory controls: one named person must act as the applicant and responsible person, but the credential may be used by an identified group in possession of a shared email contact address, but any messages to this address must be responded to within one business day.
   • If shared: possible to distinguish between individual and shared accounts? - The machine-to-machine credentials are identified by the substring "Robot " in their subject name, and a specific policy OID (attribute) in the credential
   • If individual account: traceable? Are identifiers persistent? - one entity may have more than one ID but an ID cannot be reassigned to a different entity (this also holds throughout the IGTF federation globally, using scoped identifiers)
   • Which unique identifier? - the subject name of the credential is used (for PKI). Depending on the assurance level, it will contain also the real name of the person involved.
2. Registration and proof of identity
   
   • What identity vetting process? Face-to-face or different? - The IGTF supports differentiated assurance. For the 'conventional' assurance levels (designated ASPEN, BIRCH and CEDAR), a face-to-face identity vetting or equivalent is required. F2F is supported in-person with official photo-ID; supported by notary public attestations and video conference; or by exceeding Kantara LoA-2. For the identifier-only ('lower') assurance level ("DOGWOOD"), only enough information needs to be collected to ensure uniqueness - there is no F2F requirement there.
   • Documented? - All vetting processes and possibilities are document at each IdP, and meet or exceed central federation requirements.
   • Different validation between student, staff or faculty members? How? - All members are validated equally
3. Online authentication
   
   • Passwords? - in the PKI infrastructure certificates have to be issued, so these do qualify as 2-factor authentication. This statement has to be qualified slightly: since the key pair is controlled by the user, a pass phrase on the credential cannot be fully technically enforced. Policy requirements, user induction, and software support strive towards having strong pass phrases, making it a two-factor secured system. In some cases, especially for identified based on other (federated) IdM systems ("MICS, SLCS, IOTA"), the second factor/certificate is obtained based on a username-password authentication (GEANT TCS, DFN SLCS, CILogon, HPCI)
   • Passwords with quality guarantees? What kind of guarantees? - By policy, end-user pass phrases must be at least 12 characters - this  is not technical enforceable, but is technically stimulated (it is hard to not have a pass phrase). Key pair is usually a software token (file-based)
   • Two factor authentication? -  Yes, by default 2 factor. It is to note that the 2-factor authentication is partially there for convenience in (non-web-sso) authentication scenarios and to anchor attribute certificates to it. When in use, a (kerberos-ticket-like) proxy credential with short (~12hr) validity is created based on the credential. The other advantage because of which 2FA certs were chosen is that these are self-contained and thus resilient to any (network) failures -- there is no single point of failure in the PKI - esp. since also the revocation data (CRLs) are cached by the relying parties and services. The relying parties (SPs) do not now have an opinion yet as to whether this 2-factor auth would be a hard requirement for most of their use cases.
   • If yes, which second factor? Is the eID used? - a PKI certified asymmetric key pair, usually held in software (file). eID is not used
   • If no two factor authentication: How big would be the cost to provide two factor authentication? - There is no incremental cost to provide the second factor (cert), although there is some cost to generate the certificates (people time needed for issuance). Cost would increase if the second factor would be on a hardware security token. Given software limitations, the cost of NOT providing two-factor has been high until now.
   • how widely Home Orgs use government IDs i.e. strong authentication the governments use for authenticating citizens - For the conventional assurance levels (with F2F vetting) validation is based on official govt. photo ID checking at application time. No other Govt (database) authentication is used.
4. Freshness of user data
   • Are accounts closed as an individual departs? How promptly? - If data changes credentials must be revoked, but this relies on the users taking an action. But in all cases, at most after 400 days the credential expires. The credential contains only authentication/identity data, and does not in itself contain other attributes that may become invalid. It is very unlikely that the user will ever depart from the user (and the passprase should be lost when the user dies, rendering the credential unusable). Ability to obtain new credentials is based on ability to be vetted or on verified ongoing relationship with the issuing authority.
   • Is the eduPersonAffiliation value updated as an individual departs? How promptly? - ePersonAffilition is out of scope. No data beyond identity data is necessarily collected. Organisations may not even be named in the credential (real name and unique identifier only)
     
     
5. Step-up authentication

• • Step-up authentication means that the user first authenticates with a password, and subsequently with a second factor (such as by an one-time password delivered to his/her cellphone) - No immediate use case for 3-factor authentication has yet been identified  although sensitive biomedical applications could require it. Upgrading 2FA to 3FA is not being considered now.

1. Provenance and level of assurance

• • Do you use a level of assurance? Which one? - The IGTF supports differentiated assurance levels. These levels have been co-defined by the relying parties (e-Infrastructures, active user communities) and the identity providers for feasibility and needed trust. Levels are (still) defined in the authentication profiles, but more easily read at <https://www.igtf.net/ap/loa/>
  • Is the LoA self-asserted?-  No, LoA is based on accreditation with peer review of public documentation and a compliance investigation based on discussion with assigned reviewers.
  • Is everything documented? - Yes, a compliant policy and a practice statement are required for all IdPs.
  • Internal audits? - Periodic self-assessment are required one per year, but no requirements on the independence of this assessment exist. To prevent confusion, we would label this "peer-reviewed assessments".
  • External audits? -  Every 2-3 years, the result of the self-assessment must be presented publicly to the accrediting IGTF body and must be reviewed by external peer reviewers.
  • How many users need a (higher) level of assurance? - The question on how many user need higher LoA should be more for the services than for the IdP. How many rely parties would accept username-and- password is hard to answer yes, as relying parties (SPs) have not made such a risk assessment explicit. However, it "should be consistent in requiring two factors".
  • Identity Management Practise Statement? - all IdPs must present and disclose to the accrediting IGTF the practice statements (in sufficient retail to permit assessment of security and identity vetting practice).

Insights

• Nick Roy: At Iowa, at one point, I had estimated about USD 2 million and 2,000 hours of staff time across pretty much all of IT to get rid of NTLMv2, and at the time, it would have broken things like printers and network-connected storage with no good replacement solution.  Warren Curry got pretty far down the authentication remediation road and I think had to back out due to some of the issues above.  I think U. Chicago is still working on achieving Silver, but with a second factor.  To date, only Virginia Tech (Mary Dunker) has achieved Silver, and only because they already had multi-factor hardware cryptographic tokens deployed.
• Tom Barton: 1 year to get an auditor knowing about identity management
• InCommon Survey
  • Is your institution interested in implemneting either Bronze or Silver? - half yes, half no
  • Are you aware of any SPs that requrire Bronze or Silver? - only 1 yes
  • Does your institution have any users that need access to SPs requirering Bronze or Silver? - only 2 yes
  • Are their services your institution would like to use, but cannot because your IdP lacks a required assurance profile? - no
  • In what circumstances would it be valuable to your organization to be able to self-assert that your operation meets either of these specifications? - looking towards future needs (mostly), ease of obtaining the assurance level, chicken and egg problem, general security audit reporting, with external SPs
  • What specific components do you value the most? - identity vetting: almost all; credential process: half, authentication technology/strength: almost all, attribute assurance: half
  • Are you aware of federated authentication contexts that require or that you think should require multi-factor authentication? - half yes, half no
  • Interested into an InCommon Multi-Factor Authentication Assurance Profile? - mostly yes, others I don't know, 1 no
  • Other assurance profiles? - mostly no, for R&S, trustmarks, NIST, research collaborations
  • Thoughts? - difficulties to get decision makers on board, multi-factor is excellent start, very few auditors understand or are qualified to verify the requirements for InCommon Assurance, big trust issues to overcome, interoperability and intercomparisons with international federations