Some collective feedback from UW-Madison on the SirTfi
draft:
We responded to this positioning ourselves primarily in the
role of IdP. Some of the terminology was not easy to translate
to our world, for example DITI was a challengingly abstract
term and the glossary did not include a definition of claims
processor which came up in a couple sections of the draft.
We looked over each of the six operational areas:
- Operational Security
The draft suggested a four-level self-rating for how well
an organization meets each specific requirement within the six
operational areas. In our IdP and its supporting environment,
we have different segments of users that fall under different
procedures. Each segment might get a different rating for
requirements OS1 to OS4. More loosely affiliated users might
rate a 0 on OS1, the general NetID population might be at 1;
but only identified sub-populations might reach level 2,
depending on the ID proofing and single (or multiple)
credentials issued. Basically it would not be possible for us
to give a meaningful single rating to the operational security
requirements. It seems it will be necessary to specify for a
given user and given session a level of assurance that would
imply one of the four levels.
On requirement OS2, around patching, it seems that
'verified, recorded and communicated to the appropriate
contacts' sets a high bar.
- Incident Response
Our roadmap includes support for authentication via
external providers (Google, Twitter, etc.) through a
campus-level gateway. If such externally authenticated users
access federated services, there are any number of challenges
around security incident responses. Again, it seems that
minimally SPs will need authentication context information
that will allow them to determine whether they want to accept
a given provider's assertion or not.
One approach under consideration at UW-Madison is to carry
stub identity records for federated (including external AuthN
providers') users. If we become aware of a compromised
credential of this kind, we can't 'turn it off' at the source,
but we can break the link to the internal user record, giving
us a means to head off access by those users to SPs.
- Traceability
TR1: Who is in a position to release what? We can't get
logs from Google & FB; language is fairly general in this
draft, seems like it will eventually at least need to spell
out minimum retention period; Locale at which user
registration took place could also be an important item of
information.
TR3: Re identifying users: The bare logs won't suffice: AD
GUIDs won't do the log recipient any good; To go beyond that
imposes a significant work load on the IdP side.
- Participant Responsibilities
PRU1: we have AUP for NetID holders; but with social
credentials, how do we catch & deliver AUP;
PRC3: Legal staff come down firmly against implications
that we're liable for behavior of individual users. SPs, of
course, retain rights to discontinue access to an individual
or group to protect integrity of service for others.
- Legal/Management Issues
The statement leading into the individual requirements sets
a high bar with the language '...policies and procedures
appropriately communicated to all participants, that address
legal issues including but not limited to...'
LI2: The focus on making participants aware of their
obligations is a sound one (compare with our comments on PRC3
above).
- Protection and processing of Personal Data/Personally
Identifiable Information
Lots of jurisdictional sticky wickets in this area.
In general we recognize the significant challenge of
establishing a trust framework that can function in an
international context. But we found ourselves wondering
whether there were ways to leverage well-defined existing
frameworks, PCI, FISMA and others. Granted that this would
likely mean different reference points for the US, EU, etc.
The reference to the Traffic Light Protocol in the Incident
Response section of this draft is one example of this kind of
approach.
-- Tom Jordan(IAM), Jeff Savoy (security), Keith
Hazelton (architecture)
