RE: Posting plaintext minutes to mail-list --- RE: [trust-el] Minutes from last week's meeting

["Mary Ruddy" <mary@meristic.com>]

Resending the minutes for the October 20th call in text.

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Minutes for the fourth meeting of the Electronic Identity Credential Trust
Elevation Methods (Trust Elevation) Technical Committee
20  October, 2011

1. Call to Order and Welcome.

2. Roll Call
Attending (please notify me if you attended the meeting but are not on the
list below)
Abbie Barbir, Bank of America  - Y
Anil Saldhana, Red Hat 
Brendan Peter, CA Technologies - Y
Carl Mattocks, Bofa - Y
Charline Duccans, DHS
Duane DeCouteau
Colin Wallis, New Zealand Government 
Dale Rickards, Verizon Business  - Y
David Brossard, Axiomatics
Dazza Greenwood
Debbie Bucci, NIH  - Y
Deborah Steckroth, RouteOne LLC
Detlef Huehnlein, Federal Office for Information 
Don Thibeau, Open Identity Exchange - Y
Doron Cohen, SafeNet
Doron Grinstein, BiTKOO
Ed Coyne, Dept Veterans Affairs  - Y
Ivonne Thomas, Hasso Plattner Institute
Jaap Kuipers, Amsterdam  - Y
Jeff Breburg, CA
John Bradley - Y
John "Mike" Davis, Veteran's Affairs - Y
John Walsh, Sypris Electronics
Julian Hamersley, Adv Micro Devices
Kevin Mangold, NIST - Y
Marcus Streets, Thales e-Security 
Marty Schleiff, The Boeing Company - Y
Mary Ruddy, Identity Commons - Y
Massimiliano Masi, Tiani "Spirit" GmbH  - Y 
Nick Pope, Thales e-Security
Peter Alterman, NIST - Y
Rebecca Nielsen, Booz Allen Hamilton
Rich Furr, SAFE-BioPharma Assn
Ronald Perez, Advanced Micro Devices
Scott Fitch Lockeed Martin
Shaheen Abdul Jabbar, JPMorgan Chase Bank, N.A.  - Y
Shahrokh Shahidzadeh (Intel Corp)  - Y
Thomas Hardjono, M.I.T. 
William Barnhill, Booz Allen Hamilton

63 percent of the voting members were present.  We had quorum.

We used the following chat room for the call:
http://webconf.soaphub.org/conf/room/trust-el - chat room text is included
at the end of the minutes.

2. Agenda review and approval

Abbie asked for input on the agenda.  There was none.  The agenda stays as
published.

3. Approve Minutes
John motioned to approve the minutes and Don seconded.  There were no
objections.  The minutes were approved.

We discussed the use case template.

Abbie believes we managed to create a template based on reusing the content
of the OASIS ID in the Cloud use case temple. It is published under the link
in chat room.  We need to decide and have ballot in the next few days. There
are two versions.

Peter indicated he had looked at it. It is very detailed and comprehensive
and in some ways he thought it was highlighting analytical approaches in the
data phase.  Peter believes simpler is better and would simplify the initial
information gathering process and ask for simplified processes  and get some
basic data items, and then the contractor can fill in details after have
broad simplified data gathering tool.  Peter put together just a few
questions.  

Abbie indicated he likes Peter's proposal now. We can use the simplified
form to start the data collection. Then later if do deeper dive, can use the
more detailed form. This allows people to quickly submit use cases without
taking too much time.  

Abbie said it will post it to the chat room now so that we can get agreement
and use it as a starting template.

Abbie read the text of the template (listed below in chat audit trail.) We
can start with this as input to the first deliverable which is the survey.
He asked if there was any discussion from list on this.

Mike Davis said he has a little problem with the premise of this to start.
He thought the idea of The Trust-el TC is to elevate credential from lower
to higher trust. Just because I elevate a person to a higher level of trust
doesn't mean they automatically get authorized. Still need to know their
role, etc. The premise is that to get authorization you also need to
evaluate more than just identity.

Abbie agreed that is correct.  So you are proposing a correction to the text
in the template.

Peter didn't disagree with what Mike has said.  He was simplifying.  He
would be happy to have someone refine this as long as we don't get too
caught up in the weeds.  We are trying to distinguish between level 1 and
magic so that we can do a 3 level transaction for that particular
transaction.  

Abbie asked Mike to make a cut on the language and post it.
Mike took an action item to post it to the list.

Marty had a question.  The example doesn't exhaust all possibilities.  By
this he 
means if have one level and then need a higher level of trust.  For example,
what if you start at LOA-3 and raise it to LOA-4? What if it is not
dynamically elevated? Is that in scope?

Dale asked are we talking about more than step down?  What if a system does
not allow use of higher LOA credentials?  Are we interested in stepping
down?

Abbie said I think yes.  There are situations where need to step up and
down. I think we need to ask for requirements to step down.

If he logs into a portal for high value transactions with multi-factor, when
he is done, he wants to step down. This is a user desire, not imposed by the
resource.  It is a security practice to not have user at higher level [than
needed.]

Mike Davis asked suppose your upper level credential required you to receive
a pin with a token, but the app doesn't really require that (i.e. the app
can't provide that interface.)  It could be a hassle for the user to input
more levels. 

Peter has an issue.  The name of the group is trust elevation. To Mike's use
case, you could put the applications behind a gateway that passes info to
app in a way the app can digest.
 
Abbie replied that that makes the gateway the policeman. There are cases and
situations where you elevate or not. For funds transfer you elevate for a
micro second to do a $1M transaction.  Then for the rest of the session are
doing business at a lower level.  It is contextual.

There was agreement.

Abbie commented that one could have multiple authentications because of
separation of duties for different transactions.  There are situations where
the authorization component varies even if you have done higher level
transactions.  For example there may be different fiduciary credentials.

Dale commented that if you have a LOA-3 credential and want to operate at
LOA-1, in her mind you aren't stepping down, you are just providing the
right information for the application.

Another use case is if the workflow requires another authentication, and the
user applies credentials at that point.

Sometime there is auth for a particular transaction.  He is more concerned
with auth for a connection.  His use cases elevate trust for whole session,
but he is not a bank.  He is looking at scope. Are we worried about
transaction level or session level?

Abbie is not ruling out session level, but we need to start working on focus
in the first use case.  He is looking for general consensus.

Shaheen asked are we looking at a credential because the zone required it?

If you don't define the zone as first level, it is. 

Another example to clarify: The US uses 4 classification levels.  Need to
have increasingly high levels of auth. Each [higher] level is a burden on
the system and is more expensive. So the use of credentials at the top is
more expense. You wouldn't necessarily provide higher levels if not needed.
In trust elevation there is a similar situation. I can come in at PKI LOA-4
and use it for LAO-1. But it is nutty to require LOA-4 if only need LOA-1.
If have TOP secret classification, can't also have secret.  It is true that
top secret has read access at all lower levels, but it is very expensive.

If you were supporting step down, might need to support multiple levels.

Peter wants to get back on topic.  If have strong case for step down, put it
in. 

Abbie commented that this shows the importance of having submitted use cases
for the face-to-face meeting.  Can't discuss systematically unless have it
in writing. The issue is what to focus on that at the face-to-face.

Abbie stated that we agree to use the modified template and use it for the
face-to face. Mike has an action item to improve on the text. Once we have
that, we can approve/or not approve it by Tuesday of next week. 

Next item on the agenda is the SOW that we want to use to recruit someone to
help us with our deliverable.  As I understand we have 10K to help us with
our deliverable. We thank the Trust Member section for their generosity in
funding.  He has cut and pasted the language in the chat room and asked for
feedback.
 
The SOW is cut and paste from the charter with some additional details about
what we expect to do.  There are two aspects we need to agree on.
Contractor need to give updates.  Want to know are working in harmony and
making progress. 

Abbie asked for feedback.
It was commented that it may be a good idea to have an initial meeting with
the contractor on scope so they don't go off on a tangent.
Abbie agreed.

Abbie read some of the deliverable language from the chat room.

The TC will meet with contractor before work starts.

If have blessing, can start looking for a contractor and proceed.

Abbie asked how long, if put this before members section, before we would
get approval. He will check with Dee and Chet. Abbie needs to know if we
have trusted person, can we streamline the process or if we need to go out
for a competitive bid. He wants to speed this up.

Don said that he talked about this yesterday with Dee and Jane and they
assured him it could be expedited. He is willing to take this on.

Abbie thanked Don.

Peter said that the scope of work may exclude credential only auth
practices.  If only [factor is] credential strength, then we don't need to
know more about that.

Jaap asked is it also paying attention to the process for issuing or
revoking credentials? He referred to the STORK document.

Abbie responded yes, not every credential issuer is equal.

Peter said the issue he has with this is we are not focusing on how good the
credential is.  We are focusing on how to augment trust. 

John agreed.  Don't want to reinvent STORK or IAF. We want to focus on
things that change those levels based on risk based behavior.

Abbie stated that not all issuers are equal.  This affects the trust factor.
For example, the amount of trust is a factor of the relationship with that
bank. The way to use one LOA-3 credential may vary based on other risks and
other factors. This is part of the analysis.  The exact value of trust is a
business decision.  We shouldn't reinvent, but need to make it clear actual
trust is based on business value.

John asked are we mapping between LOA levels?  Is that part of the scope?
Mapping credentials between each other is an entirely different endeavor.  

Abbie stated that this must be clear for the face-to-face.

John commented he is concerned about having non entities in scope.  We
should start with individuals.  Non person entities are nice, but could take
years.

John made a motion to adjourn.  The meeting was adjourned at 11:01

Chat room text:

Jaap Kuipers Amsterdam morphed into Jaap Kuipers (Id Network Netherlands)
abbie: i am in OASIS BoD meeting Don will chair the call I will dial in if
get access to a landline
abbie: Passcode: 637 218 8139

US Toll Free: 1 866 222 6652

Int'l Toll: 1-980-939-6928
abbie: agenda
abbie: Agenda
abbie: 1. Roll Call

2. Agenda review and Approval

3. Approve Minutes

4. F2F details and update

5. Review of use case template see
http://www.oasis-open.org/apps/org/workgroup/trust-el/documents.php

5.  IDtrust Member Section funding upadate and scope of work discussion

6. Discuss potential contributions to comprehensive list of methods  from
each participant. Editors to propose a document first draft before the
November F2F

7. Attendance Update

8. Conclude meeting
abbie: --------------------------------------
proposed statement of work to be funded by IDTrust Member Section

a contract is thought that is capable of producing a report and presentation
of facts to the Trust Elevation TC that covers the following topics:


1.Produce a  comprehensive list of methods that are currenlty  used by the
industry  to authenticate online  identities. the list should include all
application Knoweldge based techniques, contextual techniques, behavior
based techniques including multifactor authentication methods.
2.A comprehensive analysis of the methods to determine the ability of an
identity or attribute provider to provide a service provider with assurance
of an entity identity sufficient for establishing trust at a given assurance
level.
3.The analysis should cover all kind of entities (users, devicers,
applications and software agents)
4.the duration of the SOW is three month with a montly update to the TC
anonymous1 morphed into Marty Schleiff1
anonymous morphed into Brendan Peter
Carl Mattocks: carl mattocks joined
Massimiliano Masi (Tiani Spirit): Abbie, there is a LOT of noise when you
speak
Massimiliano Masi (Tiani Spirit): I can hardly understand you
Deb Bucci: for some reason I cannot dial in - will monitor the list instead
anonymous morphed into Mike Davis
anonymous1 morphed into shahrokh-intel
Brendan Peter: Deb can you try dialing in again?  We can't count you for
purposes of a quorom on line.
Deb Bucci: will try it
Deb Bucci: could be gov phone     will try my personal cell instead
Deb Bucci: 6372188139?
Kevin Mangold (NIST): 1866-222-6652
Deb Bucci: ah!
Kevin Mangold (NIST): yea, that's the passcode
Kevin Mangold (NIST): 1866 is the dial #
Kevin Mangold (NIST): 1866...
Deb Bucci: duh I'm in!
Kevin Mangold (NIST):  
don thibeau oix: information on the f2f meeting can be found at
http://oixattributesummit.eventbrite.com/
abbie: An example of trust elevation is when you log on to a website with a
userID/password pair and the site challenges you with a series of personal
questions authorizing access to the application you want.
An example of transaction trust is when you log on to your banks website
with a userID/password pair and the site applies several techniques to
satisfy the bank examiners requirement for two-factor authentication behind
the scenes, so to speak, that you never see.  These can include pattern
analysis, IP checking, etc.
So please tell us about what methods or services your organizations web
services use.
1.Trust elevation or transaction trust or both or something else?
2.Brief description of services/apps being protected and is risk deemed low,
medium or high?
3.Brief description of methods, techniques, services used to ensure adequate
assurance of user identity.  Feel free to be as specific or as vague as you
are comfortable with.  If youre too vague, well discuss.
4.Regulatory requirement(s) for authentication approach or internal IT
security risk mitigation?
5.How well does (do) it (they) work?  How well do the techniques work to
keep the right users in and the wrong users out?
Shaheen Abdul Jabbar: I like this version to gather information
Shaheen Abdul Jabbar: and then use Abbie's template to put together final
artifacts
anonymous morphed into deb bucci
shahrokh-intel: It would be great if we spell out that there are five
pieces to trust elevation in the overall system
a)credential of system SW-hardware and firmware (root of trust)
b)Credentials of the user, 
c)Credentials of  applications  
d)Credentials of the cloud 
e)Credential of the pipe (network be it wifi, 3G etc)
Jaap Kuipers (Id Network Netherlands): Stepdown, once you entered a system a
service could ask for a lower LoA for an extra transaction for say giving an
OK. First enter a system LoA3 than LoA for a signing application.
Jaap Kuipers (Id Network Netherlands): Step up: Netherlands Ing bank, enter
with uid/pw than use SMS OPT for transaction.
Jaap Kuipers (Id Network Netherlands): OTP
Brendan Peter: isn't this whole discussion out of scope given our charter?
deb bucci: not sure ...
Kevin Mangold (NIST): Yes, I think it is.
deb bucci: many LOA1 will ask give me all the info you have
deb bucci: what info at LOA3 for authentication that is worrisome
deb bucci: not sure ...
shahrokh-intel: so adding sixt item which is content clearance
Mike Davis: Chanage example statement ot trust elevation to read:  " An
example of trust elevation is when you log on to a website with a
userID/password pair and the site challenges you with a series of personal
questions so that your identity can be verified at the higher level of trust
required to authorize access to the application you want."
Marty Schleiff1: Whoever suggested that we exclude from scope "credential
only" found a succinct way of expressing what I was trying to ask about (and
which sadly led to the talk about reducing LoA).
abbie: marty no problem
shahrokh-intel: I need to log out for next meeting
abbie: ok
shahrokh-intel: bye
don thibeau oix: part of my action item WRT to the SOW is to find a
practical and expedited path forward with a contractor
Marty Schleiff1: In a prior call, there seemed to be interest in considering
the security of the back-end management and verification systems. Today it
sounds like people might exclude that from scope.
Kevin Mangold (NIST): It might be a good idea to start with just the
security of human users, then include system-system authentication later
once a lot of the base work has been done -- but to keep that in mind while
moving forward.