[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Notes from October 6 call
Minutes for the meeting of the Electronic Identity Credential Trust Elevation Methods (Trust Elevation) Technical Committee October 16, 2014. 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 Andrew Heath - y Anil Saldhana, Red Hat Bob Sunday Brendan Peter, CA Carl Mattocks, Bofa Cathy Tilton, Daon Charline Duccans, DHS Duane DeCouteau Calvin Colin Wallis, New Zealand Government - y Dale Rickards, Verizon Business David Brossard, Axiomatics Dazza Greenwood Debbie Bucci, NIH Deborah Steckroth, RouteOne LLC Detlef Huehnlein, Federal Office for Information Diana Proud-Madruga - y Diego Matute, Centrify Don Thibeau, Open Identity Exchange - y Doron Cohen, SafeNet Doron Grinstein, BiTKOO Gershon Janssen - y Ilene Bridges Ivonne Thomas, Hasso Plattner Institute Jaap Kuipers, Amsterdam James Clark – Oasis Jeff Broburg, CA Jim Macabe (Kaiser) John Bradley John "Mike" Davis, Veteran's Affairs John Walsh, Sypris Electronics Jonas Hogberg Julian Hamersley, Adv Micro Devices Kevin Mangold, NIST - y Lucy Lynch ISOC Marcus Streets, Thales e-Security Marty Schleiff, The Boeing Company Mary Ruddy, Identity Commons - y Massimiliano Masi, Tiani "Spirit" GmbH Mike Harrop Mohammad Jafari, ESC - Peter Alterman, SAFE-BioPharma Peter Jones - Rainer Hoerbe - Rebecca Nielsen, Booz Allen Hamilton Rich Furr Ronald Perez, Advanced Micro Devices Scott Fitch Lockeed Martin Shaheen Abdul Jabbar, JPMorgan Chase Bank, N.A. - y Shahrokh Shahidzadeh (Intel Corp) Suzanne Gonzales-Webb, VA - y Tony Rutkowski Tony Nadlin Thomas Hardjono, M.I.T. William Barnhill, Booz Allen Hamilton Adrianne James, VA Patrick, Axiomatics Steve Olshansky 62 percent of the voting members were present at the meeting. We did have quorum. 2. Agenda review and approval We used the following chat room for the call: http://webconf.soaphub.org/conf/room/trust-el The agenda was approved. 3. Approval of the Minutes Don made a motion to approve the minutes from September 4. Cathy seconded. There were no objections. The minutes were approved. 4. Presentation by Pieter van der Meulen Pieter is the Technical Product Manager at ServeNet. There is a link to slides in the chat room. Peter explained that they operate the network and do innovation. One of those services is Serve Connect. It uses software that they develop that is based on many OS components. It uses SAML protocols and OAuth for group information and AuthN. Higher education and research is the constituency. To connect the researchers to web service providers there are many SAML federations. They are one of the few that does not use a mesh structure. Each IDP connects to each RP. ServeNet uses hub and spoke. They have a centralized SAML gateway and all the IDPs connect to the gateway and it connects to all the service provides. Slide 4, there are 140 IDPs and 240 SPs connected. They also have a centralized group service using Internet2 grouper. They are also group providers of several institutions. So along with authN they can provide group information. Slide 5, is the high level architecture of Server Connect and the SAML gateway. Slide 6, the service delivery platform is created on top of that. It brings together the services for the constituencies. We have a sister agency to handle procurement and licensing. Slide 7, we have an app store. Slide 8, we are building a service for step-up Auth. Currently we have a deadlock between the institutions and the service providers over strong auth. Institutions don’t implement it because no services can use it. They have many institutions and if all of them had to implement strong Auth it would be very high cost and it is not their core business. And it is not the core business of service providers. They want a strong credential where strong is identification and Auth targeted at LOA 1, 2 and 3. Slide 10, how will they do that? Instead of adding strong Auth to all the IDPs, they are adding a gateway to the existing gateway. They wanted to offer this centrally as a service. This solution has no technical requirement to the IDP in order to start using the service. They just need to implement a process and train operators. The goal is it is useful even if you only have a few users who want to do step-up or only a few service providers that can work with it. Slide 11, what do we step-up to? We use the existing federated identity provided by the institution. We enrich this by adding a second factor. We support SMS, a home grown factor called Thicker (sp?) and Ubikey. Any form of strong Auth that works with a web browser is feasible. Slide 12, how does it work? On step 1 is a normal service request. Between the service provider and the step-up gateway steps 1-6 is a normal SAML Auth. Step-up is performed in steps 4 and 5. There are no standard protocols yet that are applicable. The Auth forms will be simple ones. One assertion signed by the step-up gateway. So the final element of trust is the step-up gateway. Shaheen asked do steps 2-5 all go through the gateway? Pieter responded yes. They all originate or are received by the step-up gateway. Auth is not something you do very often. Their services handle millions of logins a month. Not currently perceived as a problem that it is slow. We will be implementing SSO as well. Step 1 would then jump to step 6. Slide 13, requested Auth context communications. For each LOA there is a unique URI. There are other ways to determine the LOA by configuring it on the proxy. May hardcode the minimum LOA for each IDP and SP combination. That is possible, but then it would apply to all Auth. Slide 14, how do we get the users in the gateway? There is a registration process. We wanted to have as automatic service as possible. May start with existing IDP account and register a second factor. At the end of the process they get an OTP that represents successful completion of this first step. Then they present this code to a registration authority. There is a visual verification of a passport or driver’s license and they need to demonstrate that they are in control of the factor by performing an authentication on the spot. Slide 15, is a screen shot from the registration process. This is where the user selects the kind of token he wants to register. This user chose Ubikey. Slide 17, they should have received an email with a conformation link. When the user clicks the second link, they get a registration code to bring to the authority. Slide 20, this is the registration interface at the authority. The use inserts their Ubikey in the machine of the registration authority (RA). The attributes received from the IDP are shown to the RA and he needs to check this with a valid form of authentication. They don’t vet attributes provided by the IDP. Slide 23, registration authorities will be trained by ServeNet, the RAA in this picture. As soon as there is an RAA in an institution they can delegate their responsibility to other authorizers in the institution. At least at first, each organization will be responsible for vetting their users. They will create a policy framework. Slide 24, a few words on the SAML implementation. It is SAML 2N interoperable browser profile. SAML web SSO. It is a proxy, so they will publish metadata for all the IDPs that can be used for the proxy so that means interoperability with other systems. Will also publish in the metadata which levels the IDP will support. Pieter concluded so that is what we are doing with our step-up Auth services. Questions? Abbie asked any questions? Dianna said in looking at the process it seems like that bottle neck is still in convincing the SP that they need this service. Does it require them to set up a registration authority? Pieter replied no, it is the institution that needs to implement the registration process. The SPs have very little or nothing to do. Dianna asked so it is up to the institution to determine if they want this step-up authentication? Pieter responded a service provider could also request step-up and the institution would need to implement it. Most of the burden is on the institutions and ServeNet to run the service. Abbie said you did publish some spec on how you implemented this is SAML, a profile with the metadata. Where do you see this part of your work that needs to be standardize and would you be open for us to reuse this in our work? What is your plan? Which parts of your work would benefit from becoming a standard? Pieter replied publishing the lower levels of SAML metadata has worked well. It would be interesting if there was more standardizing of authentication with a second factor. There is also registration and de-registration. Is this in your scope? Abbie said it is in scope. Pieter said he doesn’t know of any standard for registration. He is interested to have more interoperability amongst secondary systems. Abbie said he was not looking at register as a separate protocol, but we could take that into consideration. We will keep knocking at your door and your experience. Also our banks can benefit from the process. Did you look into generalizing this for FIDO for example? I know Ubikey is working in FIDO. A second factor doesn’t need to be an external entity. You could have multiple levels of approaches within a phone. Is this part of your plan? Pieter replied we want to be as open as possible. We don’t want to have a vendor login. We want to support as many secondary ways as possible. TKIQR is a smart phone way of secondary auth. Colin said FIDO would complement TKIQRs quite well. Abbie said if we start talking about FIDO compliance it solves a lot of problems with the registration process. The FIDO will tell you what is available with the device. The institution needs to determine the binding with the FIDO entity. The range of possible Auth approaches becomes known up front. Pieter commented interesting. A related problem is the number of different secondary Auth factors. Being about to reuse and share them would be useful. We want to reduce the number of fobs and apps that are on people’s’ phones. Abbie said it is the level of trust that is available. This will vary. Even if you have an Ubikey, the trust changes depending on the location, Pieter asked you mean a form of context based auth? Abbie replied exactly. Colin asked do you have any comments on any privacy that was built in? Pieter responded that slide 12 has the step-up gateway. It uses a much of the functionality that is in Serve Connect, which has several privacy measures: consent for transferring attributes between IDP and SP. Also each provider gets a different userID for a particular user. The gateway also implements attribute release policies for a specific service provider, which are limited to a particular set. The step-up gateway only does step-up. The step-up gateway itself does need to uniquely identify the user, but it doesn’t expose that to the SP. Colin replied thank you. That is fine. Dianna asked are there times when the SP can be the same org as the IDP? Pieter responded definitely. That happens a lot. There are two kinds of federation contracts. Institutions can be an IDP. There are also SP contracts. There is also the EDUGains international federation. There are many service providers from many different sources. Diane said so an institution can be an SP, but an SP does not need to be an institution. Abbie asked for any additional questions. Pieter said feel free to contact me if you have further questions or remarks or feedback. I love to discuss this subject. Abbie said we will do that. If we decide to build on your work, we hope that you will at least review what we are doing and be tightly coupled. I think that what you are doing is at least a use case. You will hear from us again. Pieter said I will follow what you are doing. I’m sure that there will be something coming that is useful to use and if there is something that we can contribute, I’m happy to do that of course. A role of the work group is in the way the SP requests and receives the level of Auth. We use requestNcontext and authNcontet. That works for us. Any other mechanism would be fine. Abbie replied ok. Pieter said that would makes sense to standardize this. Abbie said we will have a call with the SAML TC to see if that could be done in this or the SAML TC. Abbie commented that this has been very great. Thank you. Many thanks. Abbie continued that he gave a presentation this week that was very well received and got a lot of interest. One of the entities in the room was a Spanish company 5th Layer EIDAS (??). They were very interested in using techniques we’re working on. We may ask them to present at the next call. They have a similar service. They also agreed to work with us to provide input to our work. So plan if ok is to ask them to present. Silence. Colin responded that sounds good. 5. Adjourn Andrew asked for a motion to adjourn. Don made the motion. Shaheen seconded the motion. The meeting was adjourned. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> anonymous morphed into Shaheen JPMC Shaheen JPMC: link? anonymous morphed into Pieter van der Meulen (SURFnet) Shaheen JPMC morphed into Shaheen (JPMC) Shaheen (JPMC): https://wiki.surfnet.nl/download/attachments/42697973/SURFnet%20Step-up%20Authentication%20as-a%20Service.pdf Shaheen (JPMC): this is the presentation link abbie : https://wiki.surfnet.nl/download/attachments/42697973/SURFnet%20Step-up%20Authentication%20as-a%20Service.pdf anonymous morphed into Suzanne Gonzales-Webb Diana Proud-Madruga: There is an echo. Folks, please mute your phones/computers. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]