IGTF Generalised Assurance comments by federation operators with a SAML background September 19-21, 2016 CERN, Geneva, CH

37 th EUGridPMA Abingdon – May David Groep – Assurance development Increased assurance interest  definition of a minimal ‘baseline’ across R&E  interest in re-using BIRCH for selected IdPs in R&E  ensure IGTF Assurance Profiles are really technology-agnostic

37 th EUGridPMA Abingdon – May David Groep – Baseline assurance: AARC result 1.The accounts in the Home Organisations must each belong to a known individual 2.Persistent user identifiers (i.e., no reassign of user identifiers) 3.Documented identity vetting procedures (not necessarily face-to-face) 4.Password authentication (with some good practices) 5.Departing user’s eduPersonAffiliation must change promptly 6.Self-assessment (supported with specific guidelines) AARC TNA3.1 “Baseline Assurance” by Mikael Linden et al.

37 th EUGridPMA Abingdon – May David Groep – IGTF BIRCH  Higher then base line assurance  Still feasible for a largish number of IdPs, for (a subset of) their users  Is different from ‘Kantara LoA2’ in terms of assessment, and independence of auditing  Proposed for InCommon by Jim

37 th EUGridPMA Abingdon – May David Groep – Discussing it with ‘SAML’ FedOps  whether it is to be applied per-Subject, per-IA, or what  Per-Subject is probably more successful (cf. David’s mail on the GEANT TCS success in Europe).  how trust is established, compliance attested  The standard SAML approach would be an Entity category attribute in SAML metadata + eduPersonAssurance attribute released for the qualifying users in the Authentication response.  role(s) of various actors in achieving and registering compliance, process in case a concern arises, etc  I think the IGTF experience on peer-audits could be useful, supported by the self-assessment tool the SIRTFI and LoA people are developing [1].  adapting to non-PKI credential types  That is something I’m wondering as well. The BIRCH definition[2] for sections 4.5 and 4.6 Credential strength and validity tastes like a certificate, and in the SAML-based federations I would expect 2-factor authentication to be carried out somehow else (e.g. a smartphone app).

37 th EUGridPMA Abingdon – May David Groep – Trying to explain intent of BIRCH in 4.5 and 4.6’ (at least in my understanding … ) The issued credential must be protected …  would translate into protecting the passwords your database with a good cryptographic hash (the 8-character crypt(3) DES hash would not suffice ;-) Credentials and [] transport channels [.] must be appropriately protected with [] 112 bits (symmetric).  you should send passwords only over encrypted channels (not in plain text), and they are hashed in the password database in a salted way. Credential life time should be no more than 400 days if the credential is stored in a file and is further protected with a single authentication factor [strange indeed]  interpret as the requirement for password aging (expiry) with the user having to choose a new strong password at least every 400 days. the single factor here is obviously knowledge

37 th EUGridPMA Abingdon – May David Groep – More statements that appear PKIish to SAML federations 3.2 Identifier Assignment The name elements contained in the issued credential must be sufficient to uniquely identify an individual entity. The identifier for human entities should contain an appropriate presentation of the actual name of the entity. 4.6 Credential validity The IA should provide for mechanisms to determine validity of an issued credential at the applicable point in time. 4.7 Identification of credentialing policies The credentialing policies used must be identifiable by relying parties. I can imagine how these might be adapted, just noting that they appear to be statements that pertain to a PKI context.

37 th EUGridPMA Abingdon – May David Groep – Judgement calls are apparently hard  Unrelated to adapting to non-PKI credentials, statements such as they following caused many problems in with Silver and Bronze because of their vagueness. I agree that good practice arises by using good judgment guided by such statements, but it seems that is not the only perspective held by IT professionals, many of whom are uncomfortable using judgment in this manner. Here's an example: 4.4 IT systems security Systems used by the IA must be located in a secure environment where access is controlled and limited to specific trained personnel. IA service systems must be dedicated machines[.] Any virtualization techniques employed (including the hosting environment) must not degrade the context as compared to any secured physical setup.  For example, is "secure environment" defined by the phrase "access is controlled and limited to specific trained personnel", or is something else being asked for? does "dedicated virtual environment" mean that a completely separate VMware (say) instance is required, ie, separate ESX boxes, control instance, etc. And what does "degrade the context" refer to? If not specified, it might lead to people rejecting virtual because of minor performance lost to hypervisor overhead.

37 th EUGridPMA Abingdon – May David Groep – Evolving the document …